Инструменты управления
Когда мы говорим о системе управления сайтом, мы подразумеваем, что в дальнейшем на нем планируется добавление или изменение информации. И когда мы подходим к выбору CMS, нужно четко понимать, как и что мы будем изменять или публиковать.
Любая CMS подразумевает, в первую очередь, работу с шаблонами – наборами уже оформленных определенным образом HTML-файлов, информация в тех или иных блоках которых будет изменяться динамически. Соответственно, нужно заранее понимать, что в дальнейшем должно изменяться, а что нет.
Даже, когда мы говорим про “уникальный дизайн” – это тоже шаблон, но реализованный индивидуально для конкретного заказчика, и к такому “уникальному дизайну” нужно относиться тоже как к шаблону.
Любой шаблон разрабатывается под требования (читай “философию”) конкретной системы управления сайтом и должен учитывать её особенности. Так уж исторически сложилось, что 1С-Битрис – это всё же система, заточенная в первую очередь под интернет-магазины. Битрикс имеет множество настроек, связанных с представлением товарного каталога, огромное количество плагинов и расширений для интеграции эквайринга, онлайн-касс, служб доставок и т.д., но совершенно не “заточен” под другие направления. WordPress же (как и Тильда) – в первую очередь, блоговая CMS, никогда на Битриксе ваши статьи не будут выглядеть на столько приятно, как на WordPress.
К техническим особенностям мы еще вернемся, а пока я хочу выделить основную мысль – каждая система управления имеет свой (относительно не очень большой) набор инструментов для организации работы контент-менеджера. Набор этих инструментов, как правило, предназначен для конкретной узкой категории веб-сайтов: блоги, интернет-магазины, корпоративные сайты и т.д. И очень важно понимать, что функционал таких инструментов крайне ограничен.
Шаблоны
Абсолютно любой сайт, работающий под управлением CMS имеет шаблон. Обычно, под “шаблонами” понимают готовые решения, которые можно купить, скачать, установить и настроить под себя. Но это не совсем так, когда происходит разработка дизайна на заказ, по итогу формируется точно такой же шаблон, который в дальнейшем будет установлен в CMS.
И вот здесь кроется опасность. Зачастую, заказчики, получив опыт работы с общедоступными шаблонами (платными или бесплатными) ошибочно думают, что разработанные дизайн (шаблон) на заказ будет обладать схожим функционалом и также хорошо раскрывать потенциал CMS. Но наделе оказывается, что подобное решение позволит самостоятельно разве что новости публиковать.
И это логично, так как
- на начальных этапах работ требования к функционалу разрабатываемого шаблона практически не выдвигаются
- на разработку индивидуального дизайна (шаблона) закладывается значительно меньше времени, нежели в случае с общедоступными шаблонами
На втором пункте стоит остановиться подробнее. Популярные платные шаблоны разрабатываются большими командами на протяжении довольно длительного промежутка времени. Более того, после того как шаблон был разработан и появился в маркетплейсах, разработчик продолжает поддержку и развитие этого шаблона, получает обратную связь от пользователей, внедряет новые решения, пытается конкурировать с другими шаблонами. Расходы, при этом, покрываются будущей прибылью от продаж этого шаблона. Тут и стоит обратить внимание, что разработанное индивидуальное решение для одного заказчика никогда не будет столь же удобным и функциональным, как решение, которое было одновременно разработано для десятков, а то и тысяч заказчиков (покупателей общедоступного шаблона).
Целесообразность НЕ использования CMS
Как и зачем вообще появились системы управления сайтами? Вообще стоит определиться как исторически шло развитие рынка веб-разработки.
Первым делом, на свет начали появляться библиотеке (Wikipedia: сборник подпрограмм или объектов, используемых для разработки программного обеспечения). Библиотеки были призваны решать отдельные распространенные задачи и ускорить процесс реализации таких задач. Например, реализовать человеко-понятные URL на сайте, определить город по ip, защититься от СПАМа с помощью каптчи, объединить изображения или добавить текст на картинку и т.д.
Далее, стали появляться фреймворки (Wikipedia: программная платформа, определяющая структуру программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта). Фреймворки также призваны упростить какие-то рутинные задачи, ускорить процесс разработки, а также ввести некие стандартны в разработку, чтобы проектом одновременно могли заниматься несколько разработчиков, программный код был для каждого из разработчиков понятен, а также для того чтобы передать проект от одного разработчика другому.
Ну и следующим логичным этапом стало появление на свет CMS (систем управления сайтами), они также призваны упростить и увеличить скорость разработки, сделать программный код понятным всем разработчикам, которые участвуют в проекте, а также получить стандартный набор функций (визуальный редактор, публикацию новостей, каталог товаров) “из коробки” не затрачивая время на разработку такого функционала с нуля.
Многие веб-разработчики начали “упаковывать” свои наработки типовых решений, которые “кочуют” из проекта в проект в виде CMS, поэтому систем управления сайтами на сегодняшний день несметное количество.
Также, стоит понимать, что у каждого разработчика, который делает CMS своё представление о том, как должен работать веб-сайт. Отсюда вытекает масса проблем, когда при использовании той или иной CMS заказчик от разработчика ответ на свою задачу “это невозможно реализовать”, т.к. желаемый функционал вступает в противоречие с принципами используемой CMS. И тут либо приходится отказаться от такого функционала, либо “колхозить” (что зачастую приводит к ошибкам на сайте, проблемам безопасности, удорожанию обслуживания, невозможности реализовать другой функционал).
Еще одной проблемой является желание всех участников рынка сэкономить. Заказчики не хотят платить за непонятные для них задачи технического характера, разработчики хотят сдать проект побыстрее, игнорируя при этом принципы используемой CMS и рекомендации сообщества.
В итоге при внедрении дизайн-макета в CMS (шаблонизации), в 90% случаев мы получаем совершенно не функциональный продукт, который сложно поддерживать и развивать, а возможности CMS используются на 5-10%.
Довольно часто мы встречаемся с проектами, где требования к функционалу действительно покрываются лишь на 5-10-15 процентов возможностями CMS, а остальные необходимо реализовать самостоятельно, либо воспользоваться сторонними решениями.
Нужно понимать, что “шаблонизация” с целью использования той или иной CMS – это усложнение, поиск компромиссов и целый ряд ограничений со стороны CMS. Поэтому, в каждом конкретно проекте, в первую очередь необходимо ответить на вопрос, а дадут ли эти усложнения и дополнительные расходы соизмеримые преимущества? И нужен ли в данном проекте весь тот функционал, который предлагает CMS?
Как-то раз я решил спросить клиентов для которых мы делали сайты на Битриксе используют ли они функционал массовых рассылок в админке Битрикса? Проводят ли они опросы на сайте с помощью конструктора опросов Битрикса? Не планируют ли они открыть доступ к соц. сети или форму, которые доступны на сайте, работающим под управлением 1С-Битрикс? Не хотят ли они перевести обучение сотрудников или организацию технической поддержки на свой сайт, который имеет такой функционал из коробки? Возможно стоит предложить посетителям сайта заводить на нём свои блоги, ведь такая возможность есть? На все эти вопросы я получил удивленные взгляды и ответ “НЕТ”. Подобное обилие функциональных возможностей выигрышно смотрится в маркетинговых материалах, но, к сожалению, не имеет абсолютно ничего общего с реальностью.
Не знаю как у других, но среди мох заказчиков, подавляющее большинство боятся использовать “самописные” решения, отдавая предпочтение CMS. Это относится даже к тем случаям, где CMS покрывает не более 10% от требуемого функционала, а 90% функционала так или иначе будет “самописным”. В таких случаях, использование CMS лишь удорожает разработку и создает ограничения. И, к сожалению, заказчики готовы с этим мириться.
Целесообразность использования CMS
Есть и обратные примеры, когда использование подходящей CMS оправдано.
1С-Битрикс
Как я уже говорил ранее, использование 1С-Битрикс для разработки бюджетного интернет-магазина – очень даже правильное решение. Из коробки мы получаем практически весь необходимый функционал, в маркетплейсе представлено огромное количество самых разнообразных решений для ecommerce, но вот в остальных случаях я не вижу смысла использовать 1С-Битрикс.
WordPress
Это, пожалуй, самая универсальная для нас CMS и вот почему – в 2011 году появляется плагин Visual Composer, который позволяет собирать объекты на сайте как конструктор. К 2017 году появляются довольно качественные премиальные шаблоны, интегрированные с Visual Composer. Это стало революцией. Если раньше в шаблонах можно было лишь поменять основные цвета, заменить текст и картинки, скрыть какие-то блоки, то теперь появилась полная свобода действий.
В 2016 году появляется плагин Elementor, к 2020 году в нем наконец-то исправили все критичные ошибки. Elementor стал второй революцией для WordPress. Теперь это не просто огромная библиотека компонентов и элементов интерфейса – теперь это инструмент вёрстки. Если раньше у нас уходило 2 недели на вёрстку HTML-файлов из PSD-макетов, а потом еще не меньше месяца на шаблонизацию, теперь это делается за 1-2 недели.
А самое важное, это то, что даже на веб-сайтах с уникальным дизайном, работающих с помощью Elementor, заказчик может самостоятельно править АБСОЛЮТНО любой контент на любой странице, в любом блоке, менять структуру страниц, добавлять новые объекты, а не менять лишь те настройки, которые требовалось сделать редактируемыми в техническом задании. Заказчик наконец получил полный контроль над своим ресурсом!
Лендинги, корпоративные веб-сайты и онлайн-каталоги теперь мы делаем именно на базе WordPress, потому что ни одна CMS еще не получила хоть на толику близкого по функционалу визуального редактора.
Tilda
Всё же, чтобы быть объективным, стоит отметить, что по уровню удобства визуального редактора на втором месте находится именно Тильда. Я настоятельно рекомендую этот инструмент для начала изучения веб-разработки, а также если нужно сделать сайт “для себя”. За последние пару лет функционал Тильды стал по-настоящему широким. Но при сравнении с WordPress преимущества Тильды всё-таки меркнут:
- Функционал и набор компонентов значительно более скудный
- Платная подписка – каждый месяц придется башлять по 500 руб. за сайт (в случае с WordPress ты можешь купить себе сервер за $2/мес. и держать на нём хоть сотню сайтов)
- Отсутствие доступа к исходникам – PHP-логику на таком сайте не реализовать, а это огромный удар по функциональности, какие-либо интеграции, собственные решения, калькуляторы, кабинеты разработать не получится
Фреймворки
Для сложных решений, функционал которых CMS не способны покрыть мы используем Yii2 framwork, Laravel, NodeJS и другие, но это уже совсем другая история.
