Обзор CMS WordPress и Drupal

827
13 мин.

Вступление

При обсуждении новых проектов часто возникает вопрос о выборе наиболее подходящей CMS. Чтобы сделать правильный выбор, нужно учесть ряд важных факторов, относящихся к проекту: исходные требования, размеры проекта, быстродействие, возможности настроек, уровень навыков администраторов CMS, дружественный интерфейс, а также факторы, относящиеся к направленности проекта и его администрированию.

Существует достаточно большое количество статей о преимущества и недостатках популярных CMS. С их помощью можно быстро понять, какую CMS выбрать, но все они больше касаются пользовательского интерфейса, изначально доступных возможностей, а также доступности специалистов на рынке и затрат на поддержку сайта. В данной статье хочется сместить акцент в сторону устройства и удобства, а также сложностей при работе с CMS со стороны разработчика.

Давайте расскажу более предметно о Wordpress и Drupal CMS, так как в этом вопросе я экспертен.

Предлагаю рассмотреть выбранные CMS по следующим критериям

  • Сообщество разработчиков
  • Обратная совместимость
  • Порог вхождения
  • Стандарты кодирования
  • Удобство интерфейса
  • CMS/CMF
  • Обновление и поддержание кода в актуальном состоянии
  • Устойчивость к атакам
  • Модульность и расширяемость
  • Работа с базой данных
  • Имплементация верстки

Сообщество разработчиков

Wordpress-сообщество обширно. Можно даже выделять отдельные сегменты, которые работают параллельно друг с другом. Каждый из этих сегментов самодостаточен, и зачастую можно найти ответ на один и тот же вопрос на разных языках. Помимо официального сайта с бесплатной CMS и большим количеством расширений (плагинов), есть много сайтов с модулями и темами. Существуют даже сайты, где можно скачать бесплатно версии платных плагинов и тем. Большая часть “крутых” плагинов платная. Это не удивительно, так как над созданием действительно пришлось потрудиться. Цены чаще всего доступные, и купленный функционал многократно превосходит то, что можно получить, если нанять стороннего разработчика.

Drupal-сообщество достаточно велико и по большей части централизовано. На официальном сайте собраны все расширения, модули и ядро CMS, которые можно скачать бесплатно. Количество платных расширений и тем меньше в сравнении с Wordpress, и в целом цены тоже меньше.

Порог вхождения

Wordpress — простая система шаблонов, изначально 12 таблиц в БД, отсутствие специфических указаний по архитектуре кода и жесткой привязки в MVC концепции. Все это делает Wordpress проще, и разобраться в нем легче, чем в Drupal. А с учетом обратной совместимости, знания CMS остаются актуальными очень долго. Но существует и другая сторона низкого порога вхождения. Изучить Wordpress несложно, и многие люди начинают знакомство с миром web именно с Wordpress. Как следствие, страдает качество кода. На выходе имеем огромное количество проектов с кодом низкого качества. На Wordpress действительно можно писать крутые проекты, в сети есть множество примеров.

Drupal имеет развитую систему шаблонов разных уровней, будь то страниц, полей, блоков и пр. Изначально 69 таблиц в БД, наличие указаний как по наименованию функций и классов, так и по форматированию кода. Поддержка стандартов PSR-4, что дает возможность использовать расширения от Symfony и Zend Framework, а также встроенный шаблонизатор twig. Чтобы начать работать с Drupal, нужно знать значительно больше. Такой подход открывает новые возможности по скорости разработки, гибкости настроек и масштабируемости проекта. Вместе с тем, это не защищает от некачественного кода, хотя его процент в общем количестве проектов значительно ниже. Возможно, это также связано с тем, что для человека, не занимающегося web-разработкой, сделать что-либо в коде Drupal сложно.

Модульность и расширяемость

Wordpress-плагины зачастую добавляют на сайт завершенную часть функционала и являются самодостаточными. Конечно, это не касается больших плагинов, которые также могут расширяться и даже имеют свои hooks и плагины, например, WooCommerce. Но в целом, ситуация такова, что плагины содержат и логику, и административный интерфейс, и вывод всего этого пользователю.

Drupal-модули зачастую имеют несколько другую архитектуру. Часто один модуль содержит в себе несколько модулей, например, сам функционал, и UI к нему. И если UI-функционал не нужен, то и UI-модуль можно не включать. Также модуль может опираться на функционал другого модуля, расширяя или используя его возможности. В целом, зависимость одного модуля от других в Drupal встречается гораздо чаще, чем в Wordpress. Получается своеобразное “лего”, из которого можно собирать то, что нужно.

Стандарты кодирования

Wordpress имеет стандарты кодирования, но они не накладывают каких-либо серьезных ограничений на архитектуру расширений, которая остается на усмотрение разработчика. Это дает возможность быстрого написания простого функционала, а также оставляет полную свободу при написании сложного функционала. Обратная сторона медали заключается в том, что на одном проекте может быть использован код, написанный с применением разных подходов. Это вызывает сложности при работе с сайтом, так как разные разработчики решают одни и те же задачи по-разному, и каждый раз нужно разбираться в том, как устроен написанный код.

Drupal имеет свои стандарты кодирования, хоть они и не являются обязательными, но при желании поделиться своими наработками с сообществом, нужно соблюсти все стандарты. И даже больше: придется пройти несколько проверок своего кода членами сообщества, прежде чем его увидит мир. С другой стороны, Drupal имеет свою архитектуру приложения для работы с которой нужно ее понимание. Архитектура приложения тоже меняется от версии к версии, пусть и остается узнаваемой. Это требует времени на изучение изменений и написания расширений по новым стандартам.

Удобство интерфейса

Wordpress имеет базовый одинаковый интерфейс для всех сайтов. Его можно расширять написанием кода или устанавливая плагины и темы. Но по стилистике, как правило, это очень узнаваемая админка. И если у вас когда-либо был сайт под управлением Wordpress, вам не составит труда разобраться в административной части другого сайта под управлением Wordpress. Административная тема хорошо адаптирована под мобильные устройства. К примеру, текстовый редактор для desktop-версии отображается сверху над редактируемым текстом, а для mobile-версии текстовый редактор отображается внизу, что удобно.

Drupal имеет возможность выбора административной темы для сайта. Одна тема может использоваться как для администрирования сайта, так и для отображения содержимого. Для администрирования сайта годится не любая тема: чтобы она могла считаться административной, она должна обеспечивать стилями почти все элементы на сайте, а это довольно объемная задача. Поэтому таких тем мало. Как правило, большинство проектов останавливаются на одной из двух базовых тем для административной панели или минимально стилизуют тему, которая и используется для самого сайта. На первый взгляд меню Drupal тоже изначально одинаково для всех сайтов. Только пунктов меню больше, чем в Wordpress, но ситуация меняется, когда устанавливается дополнительный функционал сайта. Меню управления сайта становится избыточным для администратора сайта и больше подходит для разработчика. Нужно отметить, что есть возможность разграничения доступа к меню как для разработчика, так и для менеджера. И сделать это можно прямо из административной панели, но на это нужно потратить некоторое время, так как система доступов (permissions) довольна развита. Что же касается мобильной версии, то административные темы тоже адаптированы под mobile. Но все же админка не так продумана и удобна, как у Wordpress.

Обновления, поддержание кода в актуальном состоянии

Wordpress имеет встроенный функционал по обновлению модулей и ядра. Но нужно постоянно делать резервное копирование, так как часто бывает, что после обновления пропадает часть функционала, а при использовании плагинов низкого качества иногда ломается даже сам сайт.

Drupal имеет встроенный функционал обновления модулей, а вот ядро обновить из админки не получится. Часто с Drupal используются вспомогательные утилиты, такие как drush и composer, позволяющие не только обновлять модули и ядро, а полностью управлять их версиями. При обновлении Drupal-модулей тоже может ломаться часть функционала, особенно если модули давно не обновлялись или изменилась подверсия модуля.

Устойчивость к атакам

Ядро Wordpress довольно хорошо защищено от атак. Но Wordpress часто ломают через установленные на него плагины и темы. Ситуацию усугубляет то, что один и тот же модуль можно скачать из разных мест и нет гарантии в подлинности модуля. Плюс большинство модулей не проходят проверки на безопасность кода. Также в доступе есть бесплатные версии платных модулей, которые часто содержат вирусы. Если устанавливать плагины из официальных источников и покупать модули у продавцов и своевременно обновлять их, это в 99% случаев спасет от взлома.

Ядро и модули Drupal хорошо защищены от атак. Они проходят проверку сообществом на соответствие стандартам кодирования, а также код просматривается несколькими участниками сообщества прежде, чем будет опубликован. Почти все доступные модули скачиваются из единственного репозитория и являются бесплатными. Поэтому шансов скачать вредоносный код мало. Тем не менее, идеального кода не существует, и дыры в коде иногда находят. Своевременное обновление кода ядра и модулей также необходимо.

Работа с базой данных

Wordpress поставляется с настроенной для работы с mysql базой данных. Существует возможность переключиться на SQLite при установке дополнительных плагинов. Использование других типов БД возможно, но реализация прослойки целиком ложится на плечи разработчика. Для работы с БД Wordpress использует класс WP_Query и несколько функций, позволяющих выбрать те или иные записи из БД с применением фильтров сортировки, пагинаций и прочим.

Drupal поставляется сразу с возможностью использовать несколько типов БД, а именно: MySQL, MariaDB, PostgreSQL, SQLite а также Microsoft SQL Server and MongoDB при установке соответствующих модулей. Drupal реализовывает PDO, то есть прослойку для работы с БД. Таким образом, все запросы со стороны Drupal выглядят одинаково, а потом преобразуются в запросы выбранной БД.

Имплементация верстки

Wordpress не использует шаблонизатор и не выставляет почти никаких ограничений на структуру шаблонов, но реализует иерархию шаблонов, которые могут быть использованы для страниц. Можно выводить записи блока и страницы при помощи разных шаблонов. Также можно использовать свои шаблоны или же реализовать логику по их подключению. Остается также возможность прикрутить и шаблонизатор, но это тоже ложится на плечи разработчика. Но поскольку wordpress не реализовывает MVC-концепцию, то может давать и негативные аспекты. Сложность масштабирования и отладки, запутанность разметки шаблона. В итоге это повысит затраты на поддержку сайта. Если же коснуться аспекта непосредственной имплементации сторонней верстки в шаблоне, то, как правило, имплементация, за исключением пары-тройки нюансов, происходит нормально. Конечно, иногда бывают трудности, но, как правило, они решаемы либо незначительным изменением верстки, либо реализацией нескольких filters. Подключение стилей и скриптов можно выстроить в очередь, а также указать зависимости друг от друга.

Drupal сменил шаблонизатор c template php на twig, чем еще больше подтвердил свою приверженность MVC-концепции. Drupal также реализует расширяемую систему шаблонов с возможностью переопределения. Такие шаблоны существуют для страниц, блоков, полей, пользователей и других типов сущностей. И это часто создает много лишней работы, если нужно переопределить шаблоны для большинства элементов. Существуют альтернативы и компромиссы, но использование родной системы будет скорее трудозатратным. Особенно остро это ощущается, когда нужно реализовать стороннюю верстку, не меняя ее. Вопрос, что нужно — верстать под Drupal или же Drupal должен имплементировать любую верстку — причина многих холиваров, поскольку Drupal по умолчанию добавляет свои классы и обертки почти для каждого элемента на странице и делает это по своей логике со своим именованием классов. По сути, верстать по готовым классам удобно и быстро, это дает возможность покрыть стилями еще не существующие страницы. Но это нужно верстать под Drupal, то есть верстальщик должен обладать некими специфическими данными про структуру Drupal сайта. В случае сторонней верстки или же в случае, когда верстка делается до того, как была выбрана CMS, это не будет реализовано. Переопределять множество шаблонов тоже трудозатратно. И приходится искать компромисс, за что в сторону Drupal часто слышны нелестные отзывы. Что касается подключения стилей и скриптов, то Drupal тяготеет к SMACSS-концепции, то есть для каждого блока необходимые стили и скрипты подключаются отдельно. После они собираются в группы и могут объединяться в один файл при соответствующих настройках в админке.

CMS/CMF

Тут следует рассказать о Drupal, так как он позиционируется не только как CMS, но и как CMF. В Drupal можно не только наполнять сайт содержимым, но также создавать новые виды содержимого, добавлять поля к существующим, управлять отображением этих полей, и все это из административной части сайта, не написав ни строчки кода.

07 сентября 2020
4 / 5 (4 голоса)