Drupal и WordPress — сравнение, аналогии, сходства, различия

Целью данной публикации является сравнение возможностей двух популярных CMS — Drupal 7 и WordPress (последней на данный момент версии 4.6). Ставилась цель рассмотреть CMS с точки зрения программиста и сравнить основные API обеих систем, провести аналогии, сделать выводы о том, какая система лучше подходит для каких задач. Публикация не претендует на полноту изложения всех возможностей CMS, а автор будет благодарен за коррективы и дополнения.

Архитектура


Оба фреймворка построены по сходной архитектуре: ядро + тема + дополнения. Ядро (движок) обеспечивает базовую функциональность. Дополнения в Drupal называются модулями, в WP — плагинами. И модули и плагины для своего создания требуют минимальных усилий (пары файлов с определённой структурой) и по своей сути не отличаются, это некоторый именованный кусок php кода с возможными сопутствующими стилями и JS скриптами, который можно независимо распространять и устанавливать в систему. Темы призваны обеспечить Look & Feel сайта, состоят из шаблонов страниц и вспомогательного кода и так же распространяются и устанавливаются отдельно. Подробности рассмотрим позже.

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

Особенности эксплуатации


WordPress давно вырос из своего первоначального назначения быть движком блогов. На данный момент декларируется, что его применение практически ничем не ограничено. Drupal, определяемый иногда, как CMF (content management framework), изначально задумывался универсальным и подходящим для всех типов сайтов. Установка обеих систем занимает небольшое время (5-10 мин), не требует каких-либо специальных компьютерных мощностей и бесплатна. После установки в обоих случаях получается готовый к настройке и использованию сайт с темой по умолчанию.

В качестве БД WP использует только MySQL, Drupal предоставляет набор вариантов популярных баз данных (MS-SQL, Oracle, SQLite, PostgreSQL). После базовой установки WP создаёт 11 таблиц БД, Drupal — более сотни (на первый взгляд это пугает, на второй тоже).

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

Плагины WP удобно ищутся и устанавливаются прямо в админке, обычно имеют понятное описание и всякие хинты для пользователя (типа “привет, я установился, нажми сюда”). В Drupal встроенной системы поиска модулей нет, модуль ищется руками на drupal.org и устанавливается по его URL, либо прямым копированием в директорию модулей (что для WP тоже возможно), либо с помощью консольного приложения drush (в WP тоже есть консольное приложение WP-CLI, но, думаю, гораздо менее популярное).

Обновления обеих систем вполне аналогичны, проверка на обновления автоматизирована, сами обновления скачиваются и устанавливаются нажатием одной кнопки. Принципиальную разницу представляет система мажорных версий, где WP придерживается политики единой линейки при полной обратной совместимости (и ваш сайт апдейтится на самую последнюю версию), в то время как, например, Drupal 7 и Drupal 8 — совсем разные и несовместимые друг с другом линейки продуктов. Для переноса сайта с Drupal 7 на Drupal 8 могут потребоваться значительные усилия программиста.

Ввиду того, что апдейты для обеих систем приходят систематически, ни там ни там крайне не рекомендуется “взламывать ядро”, т.е. модифицировать ядерные файлы. Делать это скорее всего и не придётся, а если кажется, что это единственный путь, то скорее всего либо CMS была выбрана неадекватно задаче (что реже), либо (и скорее всего) не все возможности настройки системы еще изучены.

Подробнее о модулях и плагинах


Модуль Drupal создаётся определением файлов module_name.module и module_name.info, где первый может быть совсем пустым, а последний должен содержать лишь минимальную информацию определённой структуры. После появления этих файлов в папке с модулями (обычно в отдельной папке, но не обязательно), Drupal распознаёт модуль и отображает его в панели административного меню. Для начала работы модуль необходимо активировать. Кастомные (т.е. созданные программистом для данного проекта) модули ничем не отличаются от контрибьюторских (стандартных, находящихся в базе Drupal), последние на практике порой подвергаются доработке для нужд конкретного проекта.

Считается, что модуль должен содержать некий логически изолированный кусок функциональности, т.е. приветствуется разбивка более сложных частей функциональности на отдельные модули («видишь что-то отдельное/отделимое — напиши модуль»). Профессиональный сайт на Drupal, особенно использующий большие подсистемы типа Drupal Commerce (состоящие из многих взаимосвязанных модулей), может содержать несколько сотен контрибьюторских и кастомных модулей.

Для определения плагина WP также требуются минимальные усилия, а именно всего один PHP файл с комментарием в шапке (обязательна лишь одна строчка с именем плагина). Как и модуль, плагин требуется активировать в админке для начала работы. Поскольку по сути дела писать код больше некуда (файл темы functions.php явно не предназначен вместить всю функциональность, а шаблоны не принято набивать кодом бизнес-логики), то организация приложения также осуществляется с помощью разбивки на плагины.

WordPress довольно часто критикуют за то, что плагинов очень много, но никто не гарантирует, что с подключением конкретного плагина в вашем сайте не образуется секьюрная дыра. В Drupal наблюдение общественности за состоянием модулей кажется более внимательным, хотя не очень понятно, способно ли это реально предупредить проблемы с секьюрити или лишь оперативно отреагировать на уже случившуюся беду. В целом рынок плагинов WP производит впечатление более “свободного” и разностороннего (и небезопасного), а набор модулей Drupal — впечатление более профессионально проверенного. Хотя может быть это только впечатление.

Хуки


Краеугольной фичей работы тем, модулей и плагинов является возможность (и необходимость) использовать хуки. Хук (зацепка) — это место в ядре или другом модуле/плагине, когда предоставляется возможность изменить дефолтовую работу кода. Хуков много в обеих системах (базовых в Drupal — около 350, в WP — около 250).

В Drupal для подключения хуков используется интересная и самобытная система именования, не требующая отдельного явного подключения. Например, находящаяся в модуле my_module функция my_module_menu будет автоматически служить хуком для определения роутов (шаблон имени “hook_menu”). В WP для определения хука (точнее экшен хука/экшена или фильтра, что по сути то же самое) требуется явно вызвать функцию add_action или add_filter. Соображения по этому поводу могут быть разные. С одной стороны определение функции и последующий вызов add_action() может показаться немного избыточной синтаксической конструкцией. С другой стороны имеют место следующие нюансы:

  • add_action() несколько уменьшает количество “магии” в коде, которая не способствует читаемости кода;
  • add_action() позволяет одному плагину добавить сколько угодно обработчиков, в то время как функция my_module_menu() может быть в данном модуле только одна;
  • есть функция remove_action(), с помощью которой можно отменить хук другого модуля, а в Drupal такого механизма нет.

Создание темы


Тема Drupal появляется после создания файла themename.info в папке sites/all/themes. Info файл — это простой текстовый файл, определяющий общую информацию о теме: название, автор, регионы на странице, подключаемые файлы JS и CSS и т.д. После создания или установки (установка темы аналогична установке модуля), тема должна быть активирована в админке и выбрана основной.

Тема WP определяется двумя файлами: основным является style.css, который задаёт название темы (и конечно обычно стили) и дополнительным — базовым шаблоном index.php. Структура определения темы WP восходит к временам, когда WP был простым движком для блогов, единственным шаблоном был index.php, а style.css собственно содержал стили. С тех пор шаблонов стало больше, а определение темы осталось тем же. Назначение style.css обязательным и главным файлом темы может показаться не изящным, но зато есть обратная совместимость.

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

Теме в Drupal сопутствует файл template.php, где производятся настройки темы, и определяется функционал, специфичный для всей темы целиком. В WP есть аналогичный файл functions.php. При создании собственной темы WP в functions.php обычно помещается код для подключения и отключения типовых возможностей темы (функции add_theme_support и remove_theme_support), регистрируются JS скрипты, стили и сайдбары. В Drupal такие вещи обычно делаются мышкой в админке, а в template.php помещаются функции типа template_process/template_preprocess, переопределяющие поведение шаблонов.

Готовые темы и их настройка


В аспекте готовых тем и их настройки WP значительно опередил Drupal. В свободном (и в несвободном) доступе имеется очень широкий круг тем на любой вкус и с классическим и с современным дизайном, обычных, responsive и вообще каких угодно. Кроме того, WP предоставляет отдельный API (customizer) для определения настроек темы, и создатели тем стараются сделать их максимально настраиваемыми. Тема WP — это порой отдельный продукт с регулярными обновлениями и премиум-функционалом. Отдельной фишкой при настройке темы WP является функция предпросмотра.

Drupal на настройке тем так не акцентируется. Для обычной темы в админке можно лишь поменять цветовую гамму и основные параметры сайта — название, иконку и т.д. Типовым путём создающего свой сайт программиста будет взять какую-то стандартную минималистическую тему (например, Stark), и на её базе построить свою вёрстку. Другим подходом будет использование более продвинутых продуктов, например темы Zen, использующей responsive design, Sass и Gulp.

Процессинг HTTP Запроса


В веб-приложениях всё начинается со строки запроса. Используя строку запроса, обе системы определяют, как дальше действовать. В Drupal создается роутер путей, включающий как стандартные пути (типа “node/1234”, “user/123” или “taxonomy/term/123”), так и кастомные (определённые с помощью hook_menu). После анализа строки запроса находится нужный путь в роутере и из прикреплённой к пути дополнительной информации достаётся delivery_callback — функция отрисовки страницы. Есть два стандартных delivery callback — дефолтовый drupal_deliver_html_page и аяксовый ajax_deliver, плюс при определении пути можно задать свой собственный.

В WP на основе строки запроса производится парсинг параметров запроса, и создаётся глобальный объект $wp_query класса WP_Query. Далее устанавливаются условные таги (conditional tags — is_page, is_single, is_category, is_archive, etc), которые описывают, что из себя представляет запрос, и что собственно запрашивается (конкретный тип постов, посты из архива или из категории и т.д.). Глобальный объект $wp_query и условные таги далее используются в шаблонах и пользовательском коде. На основе условных тагов происходит также дальнейший выбор файла-шаблона для отрисовки.

В целом подход в Drupal более системный и солидный (роутер — единое хранилище путей и обработчиков), подход в WP проще, и, видимо, развивался эволюционно (например, добавлением новых условных тагов), но тем не менее достаточно гибок и кастомизируем. Класс WP_Query представляется очень удобным механизмом простой работы с дополнительными запросами, а хук pre_get_posts позволяет модифицировать основной запрос.

Шаблоны


Иерархия шаблонов Drupal имеет следующую структуру. Шаблоном самого нижнего уровня является html.tpl.php, содержащий основной маркап страницы с тегом doctype. Настройка его производится в относительно редких случаях, потому что для добавления CSS/JS есть более высокоуровневые механизмы (даже код Google Analytics внедряется отдельным модулем). Далее идёт page.tpl.php, вставляющийся в html.tpl.php в виде переменной $page и определяющий общую структуру страницы. В page.tpl.php определяются регионы, указанные в info-файле темы. Явных понятий header и footer в Drupal нет, логически они “размазаны” между html и page шаблонами.

Система регионов в теме очень удобно и гибка, для регионов можно определить свои шаблоны (шаблон region.tpl.php), регионов может быть сколь угодно много, а по умолчанию предоставляется хороший базовый набор. В шаблоне page есть переменная $content, через которую в шаблон попадает собственно контент. Для вывода контента, который в Drupal представлен сущностями типа node (нода), имеется шаблон node.tpl.php.

Для всех указанных базовых шаблонов существуют дефолтовые версии, т.е. тема в состоянии жить совсем без шаблонов у себя в папке, в этом случае будут подхватываться одноимённые шаблоны из ядра и ядерных модулей (например, из модуля system). Для переопределения достаточно найти и скопировать шаблон в папку своей темы. Помимо типовых шаблонов модули могут определять собственные, как, например, сделано в модуле Views. Каждый шаблон снабжается рядом предустановленных переменных (подробно расписанных в комментариях в шаблоне), которые можно менять и дополнять в функциях типа process_page/preprocess_page.

В целом иерархичность шаблонов темы Drupal имеет характер “вложенности”, field вкладывается в node, node вкладывается в page, page — в html. Также подмена одного шаблона другим происходит при специализации (когда, например, node-15.tpl.php используется вместо node.tpl.php).

Иерархия шаблонов WP имеет другой характер. Все базовые шаблоны тут являются “полноразмерными”, т.е. содержат doctype. Какой шаблон применяется, зависит от текущего запроса и условных тагов. По тагам определяется, какой шаблон использовать. Если, например, запрашивается страница (is_page() == true), то система использует page.php, если в запросе категория (is_category), то category.php, если отдельная запись в блоге, то используется single.php и т.д. Центральное место занимает шаблон index.php, который используется для обработки запросов, для которых не нашлось более специфичного шаблона. Когда-то этот шаблон был в WP единственным, и это центральное место так за ним и осталось.

Дефолтовых шаблонов в WP нет, но index.php (как “всеядный” шаблон) чаще всего имеет типовой вид с WP циклом (loop). В WordPress обычно явно определяются шаблоны header.php и footer.php. Это “сырые” части html (в header.php открывающие теги , , в footer.php — закрывающие). Для их вставки предусмотрены функции get_header() и get_footer() (поэтому файлы должны называться именно так). Вроде как примитивно, но зато просто и понятно. Drupal регионам в WP соответствуют Sidebars, для них есть свои шаблоны sidebar-name.php и функции их использования dynamic_sidebar() (про сайдбары и виджеты чуть позже).

Кроме типовых шаблонов в WP можно создавать именованные кастомные шаблоны, которые потом можно применять к отдельным страницам (при создании страниц появляется опция использовать шаблоны, если хоть один существует).

Для отображения главной страницы есть не совсем (как мне показалось) очевидная логика, основанная на нескольких вариантах отображения: статической страницей, стандартным блоговым видом или кастомным шаблоном. С деталями можно ознакомиться в кодексе WP в разделе разработки тем.

Как видно, шаблоны в Drupal более системны и просты в изучении, а в WP вероятно более гибки и практичны. И там и там иерархию шаблонов приходится поизучать, чтобы применять эффективно. И там и там есть выбор и необходимая гибкость для достижения необходимого результата.

Регионы и сайдбары


Итак, в info-файле Drupal темы определяются регионы, в файле page.tpl.php определяется размещение регионов на странице, в шаблонах region--name.tpl.php определяется маркап конкретных регионов. Это даёт ясную структуру и большую гибкость в построении темы. После определения регионов они доступны в админке для размещения блоков (block). Блоки — это визуально-изолированные кусочки вывода на страницы, которые могут легко перемещаться между регионами (например, мышкой в админке). По сути регионы создаются для размещения блоков и главного контента. Блок может быть типовой (например, “сделано на Drupal”), может быть определён в любом модуле с помощью хуков (hook_block_info), а может быть создан прямо в админке как произвольный html-код. Для блоков существует свой шаблон block--name.tpl.php.

Виджеты в WP — это ровно то же самое, что блоки в Drupal. WordPress виджеты также бывают типовые (например, “сайт работает на WP”), могут создаваться плагинами и темами (с помощью наследования класса WP_Widget и функции register_widget), а могут быть определены прямо в админке с помощью html-кода (точнее есть стандартный виджет, позволяющий разместить произвольный HTML код). Роль регионов в WP играют сайдбары (sidebars). Сайдбары нужно регистрировать в теме в файле functions.php с помощью функции register_sidebar. После регистрации сайдбары становятся доступны в админке в разделе Виджеты и позволяют размещать виджеты разных видов. Для сайдбара по умолчанию есть шаблон sidebar.php, для дополнительных “именованных” сайдбаров можно определять шаблоны sidebar-name.php.

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

Подключение CSS/JS


Для подключения JS в WP используется функция wp_enqueue_script, и хук wp_enqueue_scripts. Путь собственно единственный. Если хочется контролировать подключение, то используется логика, благо хуки в WP требуют явного вызова add_action(). В Drupal для подключения JS существует несколько путей:

  • подключение в файле info темы
  • подключение функцией drupal_add_js (аналогична wp_enqueue_script)
  • подключение через libraries API
  • подключение через параметр attach в формах
  • подключение прямо в шаблон html.tpl.php (не рекомендуется);

Первый путь наиболее удобен и логичен, второй позволяет добавить логику при подключении. Libraries API — довольно удобная штука, позволяющая подключать целые библиотеки (JS/CSS/PHP), с несколькими версиями и отслеживанием, какую версию когда загружать. Библиотеки при этом могут использоваться несколькими темами.

Для подключения CSS механизмы подключения аналогичны (с заменой script на style и js на css).

Контент


По историческим причинам контент в WP называется постами (post), контент в Drupal называется нодами (node). В целом они особых отличий не имеют, за исключением нюансов. Например, двумя стандартными типами контента в WP являются собственно посты и страницы. Страницы не являются подтипом постов, а представляют собой некий обособленный тип контента со своими свойствами. Например, для страниц нельзя определить таксономию. Страницы часто используются для статического контента, но могут быть определены согласно пользовательскому шаблону, т.е. по сути содержать что угодно.

Ноды в Drupal представляют собой все виды контента, включая страницы (pages). Весь контент изначально доступен по ссылкам типа “node/node_id”, например “/node/12345”, таким образом весь контент унифицирован.

Типы контента и поля


Типы контента — это подтипы нод и постов соответственно. Для WP тип постов определяет просто некий маркер-название и ничего больше не определяет. Можно создавать посты с таким “типом”, можно их по типу вытаскивать из базы. Для Drupal тип нод (бандл) — это не только название, но и, например, кастомные поля, которые по умолчанию прикрепляются к данному бандлу. В WP вместо полей в базовом функционале есть мета-информация — любого сорта key-value пара, которая может прикрепляться к посту (конкретному посту, а не всему типу).

Популярным решением является использование модуля Advanced Custom Fields (ACF), с помощью которого можно определять наборы полей и прикреплять их к типам контента, аналогично Drupal подходу. В Drupal это сделано более гибко, потому что разделяются понятия field и field instance — абстрактно определённое поле и поле, прикреплённое к какому-то бандлу. Но в целом практические возможности в итоге аналогичны.

Мета-информация в WP может прикрепляться не только к постам, но и к пользователям, терминам таксономии и комментариям (функции add_post_meta, add_user_meta, add_term_meta, add_comment_meta). В Drupal есть обобщающее понятие сущности (Entity и Entity API), и поля прикрепляются к сущностям, имеющим свойство fieldable.

Таксономия


Таксономия — это категоризация контента с помощью иерархии терминов. Обе системы имеют полнофункциональные возможности для определения сколь угодно сложной таксономии, благо сама идея не слишком сложна. Обе системы предоставляют развитый API для операций со словарями и терминами таксономии. Появление в WP кастомных типов постов и иерархической таксономии объявляется коренным изменением, благодаря которому WP перестал быть просто движком для блогов и превратился в полноценную CMS. Наверно можно с этим согласиться, хотя рудиментов былой “блого-ориентированности” WP довольно много (например, функция bloginfo, WP_Post, sidebars, сам по себе Loop и т.д).

Настройка вывода контента


Один из самых значимых контриб-модулей Drupal — Views — позволяет формировать страницы для отображения имеющихся видов контента почти в любом виде. Настраивать это всё удобно из админки, но при желании можно и из кода. По сути при создании конкретных страниц сайта на Drupal решается задача вывода контента в форме статических страниц, ноды целиком (через шаблон node.tpl.php) или вьюшки (т.е. блока или страницы, сформированной модулем Views). Сама вьюшка определяет как выводимый контент формируется, а соответствующие шаблоны модуля Views определяют конкретный маркап вывода. Для переопределения таких шаблонов их также следует скопировать из модуля себе в тему.

Аналогом Views в WP вероятно можно считать главный механизм вывода контента — цикл (loop). Цикл использует глобальную переменную $wp_query для получения результатов запроса. Большинство стандартных шаблонов использует цикл и таги шаблонов (Template Tags), для вывода конкретных частей содержимого (заголовка, даты, собственно содержимого поста, ссылки на пост и т.д.). По сути Drupal объект view является обёрткой такого рода цикла, настраивающейся с помощью структурированного массива (которые столь в Drupal любимы).

Трудно сказать, какой механизм удобнее и гибче. Вьюшки можно создавать совсем без программирования, сразу же получая предпросмотр того, как всё будет выводиться на реальном контенте. С другой стороны более тонкая настройка вьюшек (из кода через объект view и функции типа views_embed_view) явно сложнее настройки вывода цикла WP. Но зато уже настроенный объект вьюшки можно переиспользовать в любом месте кода, не надо повторять код цикла.

Говоря про вывод контента с помощью набора шаблонов, важно отметить одно значительное отличие — до самого последнего момента (вызов функций render() или drupal_render()) формат вывода контента в Drupal остаётся в виде так называемых renderable arrays — структурированных массивов, менять которые проще, чем готовую HTML строку. Структурированные массивы — механизм интересный и удобный, правда массивы эти со временем разрастаются до неимоверных размеров (иногда сотни тысяч элементов), становятся рекурсивными, включают и пере-включают в себя одно и то же содержание и вообще порой наводят ужас.

APIs


И Drupal и WP постоянно развиваются и добавляют новые возможности для программистов. В обеих системах эти возможности структурированы, как отдельные API. Рассмотрим некоторые из них.

AJAX API


Drupal предоставляет весьма интересный интерфейс для работы с Ajax. Основная идея — организовать Ajax функциональность по возможности вообще без написания какого-либо JavaScript кода. Это достигается введением CSS классов типа “use-ajax” (достаточно приписать такой класс к кнопке или ссылке), а также механизма стандартной обработки ajax запросов (для всех ajax-запросов один типовой путь system/ajax). На серверной стороне с помощью функций ряда ajax_command_* (например, ajax_command_invoke) можно полностью определить, что будет происходить в браузере, вплоть до вызова конкретных функций jQuery. Механизм требует некоторого времени на освоение, но позже позволяет эффективно перерисовывать нужные куски DOM прямо из PHP.

Отдельного рассмотрения заслуживает механизм Drupal behaviors. По замыслу этот механизм призван трактовать JS код, как некоторое поведение, которое включается в нужный момент времени, не только при первичной загрузке страницы, а, например, после перерисовки части DOM при ajax запросе. Behavior получает контекст (по сути корневой элемент DOM, в котором произошли изменения) и может отреагировать соответственно. Механизм behaviors — полезный и интересный, если освоен и правильно применяется.

Механизм Ajax в WP значительно проще и слабо отличается от базового ajax в принципе в PHP. По сути WP определяет стандартный путь, куда посылаются запросы из JS (глобальная переменная ajaxurl в JS) и механизм определения обработчиков через хуки. Ajax response при этом формируется с помощью класса WP_Ajax_Response, который просто создаёт нужный XML код. Можно также просто использовать функцию wp_send_json.

Forms API


Drupal предоставляет довольно мощный API для работы с формами, используя структурированные массивы. Фактически любая форма в Drupal должна определяться описанием всех своих компонентов, как элементов в структурированном массиве и выводиться уже в шаблоне с помощью drupal_render. При определении элементов массива, можно указывать многие интересные вещи, например использовать Ajax API, упомянутый выше, включать требуемые специально для формы JS/CSS, можно создавать многостраничные формы. Forms API (FAPI) поддерживает валидацию ввода, несколько обработчиков при submit, возможности переопределения форм с помощью хуков.

В WP подобного механизма работы с формами нет, есть много плагинов, которые помогают в админке рисовать формы обратной связи для сайтов и вставлять их на странички. Известны попытки создать что-то похожее на Drupal FAPI. В целом несколько обидно, что для настолько базового функционала нет даже простых хелперов типа Form::open().

Еще про пути


Как уже отмечалось, пути (routes) в Drupal определяются с помощью хука hook_menu. Таким образом можно задать любые возможные пути (обычные, в админке, Ajax, API и т.д.) — способ удобный и единообразный. В WP такого единообразного способа нет, зато есть два интересных API: Rewrite, с помощью которого можно самостоятельно определять правила преобразования пути в красивую ссылку, и WP REST API. Последний предоставляет реальный готовый REST интерфейс, позволяющий получать данные из БД, а также позволяет определять любые свои кастомные пути. В Drupal аналогов этим API нет.

Entity API


Не так давно в Drupal появился Entity API — новый уровень абстракции над нодами, позволяющий определять сущности, не относящиеся непосредственно к контенту. Ноды, пользователи, комментарии и термины таксономии стали частными случаями сущностей (entity). При подключении контриб-модуля Entity API (который почему-то не входит в набор по умолчанию) с сущностями можно эффективно работать.

Основным вопросом является — когда и зачем это делать. Рекомендуют всё, что похоже на контент и имеет внешний вид оформлять как типы нод, а что-то более абстрактное и “невидимое” на экране — как сущности. Можно сказать, что это инструмент для организации более сложного приложения на Drupal. Например, сущности активно используются в Drupal Commerce для оформления отдельных характеристик заказа.

В WP такой абстракции нет, поэтому если нужно будет писать что-то более замысловатое, то придётся либо использовать custom post types либо просто получать удовольствие и писать на PHP.

Модели данных и БД


Модель данных в CMS построена вокруг типов контента. Если бизнес-логика приложения может быть удобно описана с помощью типов контента, то CMS — удачный инструмент для использования. Тип контента — это независимая сущность с фиксированным набором атрибутов (среди которых есть что-то типа title и description). Желательно, чтобы разные типы контента были между собой не связаны.
С типами постов WP удобнее всего работать через объект WP_Query, а также функции get_posts() и query_posts(). Если возможностей WP_Query недостаточно, то есть функция dbDelta(), которая призвана запускать любые SQL запросы, а также класс wpdb, возможности которого используют через глобальный объект $wpdb. Класс wpdb несколько упрощает работу с БД, но всё равно часто приходится писать “сырой” SQL, никаких возможностей query builder он не предоставляет.

В Drupal для работы с БД есть несколько API:

1. Для работы со структурой (схемой) БД есть hook_schema и функции типа db_create_table/db_add_field.
2. Функция drupal_write_record, как простой способ записи в БД.
3. Основной API — набор функций db_select/db_insert/db_update/db_delete/db_query, с динамическим построением запросов (примеры).
4. Для более удобной работы с сущностями и полями существует класс EntityFieldQuery, который также позволяет делать динамические запросы.

Существуют также попытки приладить к CMS более серьёзные инструменты типа Doctrine. И для WordPress и для Drupal есть соответствующие модули/плагины, но, судя по всему, не в активной разработке. Видимо острой надобности в таких инструментах нет, ввиду опять же несколько другой модели данных.

Заключение и выводы


Рассмотрение конкретных возможностей для программиста приводит нас к выводу, что Drupal представляет из себя значительно более сложную и оснащённую систему разработки, вместе с тем требующую большого времени для изучения (которое не всегда и не у всех есть). Опыт показывает, что Drupal-мощь на практике компенсируется его сложностью. Сайт на Drupal, попавший «не в те руки», быстро становится огромной кучей несопровождаемого кода.

С другой стороны WordPress — это значительно более лёгкая платформа, позволяющая очень быстро получить заметный результат. Инструментов для длительной командной разработки у WordPress конечно маловато, но система активно развивается, прирастает интересными возможностями. Обе CMS, таким образом, заслуживают серьёзного рассмотрения для своего круга задач.
Аркадия 38,91
Заказная разработка, IT-консалтинг
Поделиться публикацией
Комментарии 68
  • +1
    Drupal это скорее CMF, звено между фреймворком и CMS.
    Делать что-то более сложное на Wordpress-е чем бложик, это из разряда троллейбуса из буханки.
    • 0
      Я с Вами не соглашусь. Как на drupal так и на wordpress можно построить достаточно не плохие сайты. Все зависит от знаний той или иной системы.
      Я видел сайты по инвестиционно-банковским, брокерским услуги, услуги по управлению активами, и на drupal так и на wordpress. Делали сайт 2 разные команды. Результат не плох.

      • 0
        Ваше право.
        Просто раньше работал с друпалом (до 7ой версии).
        И как-то пришлось выполнить небольшой заказ на wordpress-е.

        От вордпресса потом долго плевался и не за какие деньги не возьмусь с ним работать.
        • 0
          Все зависит от знаний той или иной системы
          .
          Чем больше знаний, тем больше мотивации избегать Wordpress для нестандартных для него проектов (не блогов), чтобы не увязнуть в нём?
          • 0
            Такого количества говнокода в одном месте (вордпресс) я больше нигде невидел
    • 0
      Dupal 7 сейчас не самая удачная точка входа в мир веб-разработки, учитывая что он потихоньку переходит в режим security-updates only и перестаёт активно развиваться, Drupal 8 построенный на Symfony компонентах с одной стороны даёт CMS на которой можно развернуть блог мышкой, с другой — возможность плавно переползти на Symfony если это потребуется в дальнейшем.
      • +1
        После базовой установки WP создаёт 11 таблиц БД, Drupal — более сотни (на первый взгляд это пугает, на второй тоже)


        При установке стандартного профиля друпал создаст 74 таблицы, а при установке минимального — 49, что явно меньше сотни.

        есть функция remove_action(), с помощью которой можно отменить хук другого модуля, а в Drupal такого механизма нет.


        в друпале такой механизм есть — hook_module_implements_alter

        В Drupal аналогов этим API нет.


        Аналог WP REST API в друпале это модуль Serives и похожие. В восьмой версии функционал доступен из коробки.

        Не так давно в Drupal появился Entity API


        «Не так давно» это более 5 лет назад например =)
        • +1
          Спасибо за комменты (и за блог конечно).

          При установке стандартного профиля друпал создаст 74 таблицы, а при установке минимального — 49, что явно меньше сотни.


          Я имел ввиду просто drush dl drupal7 и enable самые обычные модули для разработки, которые обычно применяются почти всегда. Без попыток что-то специально оптимизировать. Вроде как будет около 100 или даже больше. Поупражняюсь еще.

          в друпале такой механизм есть — hook_module_implements_alter


          Я думал он очерёдность вызова хуков регулирует.

          Аналог WP REST API в друпале это модуль Serives и похожие.


          Ок. Просто в WP это в ядре.

          «Не так давно» это более 5 лет назад например =)


          Да, согласен, быстро время идёт...=)
        • 0
          Хуков много в обеих системах (базовых в Drupal — около 350, в WP — около 250).

          Про Drupal — не знаю, про WordPress — очень сильно занижено указанное количество.
          800+ do_action() и 1650+ apply_filters() — и то, и другое является хуком, с разным предназначением.

          • +1
            Какой смысл обозревать старый Drupal 7, когда во всю уже 8 версия? А это «Две большие разницы».
            • 0
              Потому что очень много кто всё еще работает с Drupal 7 и не собирается переходить на Drupal 8.
              • 0
                На старых версиях Вордпресс тоже много сайтов осталось. Такое сравнение на мой взгляд не корректно. Если уж сравнивать, то последние актуальные версии обеих CMS.
                • +1
                  Не согласен, потому что D-7 и D-8 — это совсем разные продукты, и развиваются, как две независимые линейки. Поэтому можно сравнивать «последний D-7» и «последний WP».
                  • 0
                    Поэтому можно сравнивать «последний D-7» и «последний WP».
                    Последний D7 почти не отличается от первого. Drupal 7 разрабатывался в 2008 — 2011 годах. С тех пор в него в основном коммитили только багфиксы и небольшие улучшения в производительности. Для того, чтобы сохранить обратную совместимость всё новое добавлялось в следующую мажорную ветку (Drupal 8).
              • 0
                Ага есть даже 9-я версия. А толку. Это только для ознакомления, для работы — 7-я версия. Да и 6-я вполне приемлемый вариант. Сам работаю с Друпалом с 2007 года, волею судеб изначально удачно выбрал именно его. На Вордпрессе тоже приходилось. Но, увы, для того, чтобы на Вордпрессе сделать простой магазин приходится изощряться нереально. На Друпале подобная задача решается за пару-тройку вечеров. И так далее…
                Статья, посвященная сравнению таких продуктов — дело тяжкое и не благодарное, это всегда повод спровоцировать срач между сторонниками той или иной системы управления
                • 0
                  «Восьмёрка» ещё очень и очень сырая. Пока не видно возможностей, чтобы она могла заменить D7 в реальной работе. Отсутствует или неработоспособна куча важных модулей, в частности.
                • 0
                  Интересный у вас вариант сравнения. Вы по распространенности выбирали, или по тому, что на обоих с равными усилиями могли сделать одинаковые сложные веб-сайты/приложения?

                  По мне так вы заголовком предложили семерку BMW и Ладу сравнить.
                  • 0
                    BMW семёрка вероятно не последнего года выпуска, ей лет этак 15 =)
                    Да, технологии не равновелики, но это вполне реальный выбор при разработке сайта, не так ли? А недостатки у друпала есть, в первую очередь сложность. Чтобы сайт был сделан «Drupal way», нужно в основных API разобраться, а это не всегда на практике возможно тому, кто будет его саппортить и развивать.
                    • 0
                      У BMW тоже есть такой «недостаток», она сложнее чем Запорожец ))) Исходя из вашей логики, проще всего пешком ходить.
                      • 0
                        нужно в основных API разобраться, а это не всегда на практике возможно тому, кто будет его саппортить и развивать.

                        Это не проблема Drupal а проблема разработчика, который не знает API той системы с которой взялся работать. Для администратора и контентщика достаточно инструментов в админке, кодить ничего ненужно.
                        • 0
                          Разумеется сложность — это не проблема Drupal, скорее особенность. Именно поэтому много сайтов делают на WP, потому что проще, легче найти человека написать и поддерживать, и этот человек дешевле стоит. Только в этом моя логика)

                          • 0
                            Вордпресс дешевле и легче не всегда. Если стандартный сайт из готовых модулей то возможно. А вот когда нужно будет кодить, тогда могут начаться проблемы.
                        • 0
                          Ну так сравнивать запорожец и танк, наверное, тоже можно, только задачи для них исходно разные. Если Drupal на мелких сайтах «не по калибру» использовать будет, то WP на крупных редко кто без напильника будет использовать. Ну, разве что из-за админки, если кому такое нравится.

                          Вылепить же веб-приложение в WP я бы не взялся. Сделать можно, но зачем?
                      • 0
                        А по моему отличная статья. Ещё бы в качестве третьего объекта сравнения была б Joomla, цены б статье не было.
                        • 0
                          Тогда уж и MODx ещё.
                          • 0
                            Та же мысль пришла в голову. Как минимум, напрашивается сиквел. =) Недавно стал экспериментировать с WordPress, так как дизайн многих сайтов на этой CMS странным образом притягивал взгляд. До этого вообще только Joomla и использовал, чтобы не распыляться. Когда увидел заголовок статьи, удивлен был, что в сравнении её нет… Тем не менее — общее положительное впечатление.
                          • 0
                            Отличный обзор!
                            По большему счету соглашусь практически со всем, что рассматривал ТС.
                            И соглашусь, что однозначно вп давно вырос из простого «движка для блогов» и догнал друпал, а возможно и перегнал. Все дело, по моему мнению в «привычке», но если в равной степени строить на друпале и на вп, то оба вполне устраивают и практически под любые задачи.
                            • 0
                              Я вот никак не пойму чем так хорошо друпал7? какая-то фигня на функциональном программировании. В плане юзабилити вообще какая-то жуть.
                              • +1
                                Гибкостью своей архитектуры естественно — очень немного решений предоставляют механизмы для переопределения не только функциональности ядра но и других модулей — причем на всех уровнях от ajax ответов и клиентских скриптов (включая переопределение отдельных функций в рамках Drupal API) до темизации на всех уровнях — полей, страниц, форм, элементов с удобным механизмом зависимости темизации от контекста (который тоже можно переопределять). Ну и функциональщина в целом лучше других парадигм — ее проще отлаживать, хотя Drupal это не совсем функциональщина — слишком много магии
                              • +1

                                Спасибо за статью.
                                Возражу комментаторам, которые считают, что сравнение не актуально, или сравнивается несравнимое. Я Вас уверяю, некоторые из "не вас" действительно интересуются, как сделать выбор, и на основании чего. Таки да, профессионалы вырастают из тех, кто ищет ответы на то, чего — о, ужас — не знают! Рад за вас, что вы уже всё для себя решили, а я прочитал статью с удовольствием от начала до конца.
                                И не надо приводить в пример БМВ и Ладу. Для меня, например, БМВ не настолько лучше Лады, насколько он её дороже: его преимущества находятся за рамками моих актуальных потребностей. И именно это в статье есть: первичная обобщённая информация для того, чтобы преобразовать потребность (свою, не Вашу) в решение. Так что с Новым годом всех, и пусть каждый выберет себе по ЦМСке и по машине (а то и не по одной).

                                • 0
                                  Интересно бы почитать сравнение вп с джумлой, друпал это все-таки нечто более толстого калибра.
                                  • 0
                                    Я бы ещё добавил про друпал что писать JavaScript там отдельное удовольствие всю функциональность приходится оборачивать специальными костыликами чтобы они второй раз не вызывались, и так далее всякие там new Drupal.ajax(… в итоге приходится искать Drupal frontend разработчиков, мне то в этом не сложно разобраться, но это даже не автобус из буханки а самолёт, потому что зачем.

                                    Плюс опять же друпал старый и дряхлый как продукты жизнедеятельности тираннозавра, но не смотря на это пользоваться им неудобно объективно админка хуже разрабатывать на нем дольше на (практике проверялось не раз) модули менее готовы из коробки по сравнению с WordPress и их меньше, Drupal 8 призванный решить эти проблемы когда вышел то сохранил все наследие плохой админки и поломал совместимость с всем что сделало сообщество в направлении хоть какого то улучшения интерфейса, так же views который теперь включён в ядро лишился части своего админ интерфейса, что как то не укрепляет надежду на скорому улучшение ситуации.

                                    Про модули, ну во первых тут либо много старых у Drupal 7 либо мало новых у Drupal 8, да еще ко всему все жесткие подходы к модерации модулей в репозитории Drupal не к чему не привели, достаточно посмотреть на Panels, Page Manager, Display Suite они все нормально не работают, поэтому среди разработчиков немногие делают новые проекты на восьмерке.

                                    В итоге друпал дает ровно три вещи:

                                    — много возни с админкой;
                                    — структура html, не способствует быстрой верстке (не буду объяснять просто, всегда так было, легко убедиться);
                                    — куча модулей который не подходят или не работают;
                                    — нет надежды.

                                    так что я не понимаю радости на счет друпала, наоборот в пору начать волноваться насчет него.
                                    У этого BMW кузов повело.
                                    • 0
                                      У Drupal есть определённая идеология (в том числе по вёрстке и JS). Если вы её не понимаете — это не проблема Drupal.
                                      Если выбрасывать весь «дряхлый» (проверенный временем) код — выбросьте вашу операционную систему. Она написана с использованием принципов, заложенных почти 50 лет назад.
                                      Неудобство админки — вещь субъективная. Мне «норм», особенно если настроить shortcuts.
                                      Восьмая версия пока в разработке, нападки на неё мне кажутся обвинением пятилетнего младенца в неспособности решать дифуры.
                                      Модули работают. Они многократно протестированы. Если что-то не работает — создавайте issue на багтрекере.
                                      Так что насчёт Drupal волноваться нечего. Годика через полтора «восьмёрка» догонит.
                                      И это не пижонский BMW — это Hummer с возможностью апгрейда до тяжёлого танка или самоходной артиллерии.
                                      • 0

                                        Восьмая версия пока в разработке, нападки на неё мне кажутся обвинением пятилетнего младенца в неспособности решать дифуры.


                                        Чувак Drupal 8 уже где то года два как в стабильно релизнулся, я на вечеринке по этому поводу был, мне то не рассказывай про собственный путь друпала и про то что он так и задумывался

                                        • 0

                                          А да, забыл добавить. Если ваш вариант "не пробовал, но одобряю" то никаких проблем не у друпала не WordPress, и там и там все хорошо

                                          • 0
                                            То, что «официально релизнулось» ядро, не делает весь продукт готовым к использованию.
                                            Вы были на вечеринке, а я каждый день с Drupal работаю. И «Дзен Друпала», считаю, постиг. Мне нравится эта идеология, и она работает.
                                            WordPress я тоже использовал в двух проектах. До сих пор передёргивает при воспоминании, зарёкся даже близко к этой платформе подходить. Спагетти-код и костыль на костыле. И дыры как следствие, разумеется.
                                            • 0

                                              Да ладно вордпресс, как вы определяете когда, когда Drupal 8 можно будет считать готовым? Три года разрабатывался, дождались релиза, Drupal 9 начался, все ещё не готов продует, а шестеркой уже можно пользоваться не рано?

                                              • 0
                                                Вы приводите цифры которые не соответствуют действительности.

                                                Три года разрабатывался, дождались релиза

                                                Не три а почти пять.

                                                Чувак Drupal 8 уже где то года два как в стабильно релизнулся

                                                Чуть больше года.

                                                Даты релизов:


                                                • 0

                                                  Ну так до релиза где то три года и разрабатывался, на счёт трёх лет лет стабильного релиза это я отпечатался и там и там на 2 как будто это что то сильно меняет.

                                                • 0
                                                  когда Drupal 8 можно будет считать готовым?
                                                  Ответ всегда будет собъективным. Зависит от вас и ваших проектов. Правильнее спрашивать, когда вы будете готовы перейти на Drupal 8?

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

                                                    Я то все продукты привык считать готовыми с релиза, но тут в комментах другие мнения почему то. Мои вопросы были только к недоделаности и неудобности и архаичности

                                                    • 0
                                                      Наверно зависит от того, что называть продуктом. Если вам нужнен только сам Друпал, то его можно считать готовым с момента релиза. Если в «продукт» входят контриб модули, темы, документация, ответы на StackExchange и т.д., то придется подождать довольно долго.
                                                      • 0

                                                        Вот именно ждать придётся слишком долго, а нормальной админки и вовсе не дождутся и внуки, либо

                                                        • 0
                                                          • нам расскажут что это же друпал очень гибкий и мольный, поэтому админка и не нужна была изначально
                                                          • 0
                                                            А что не так с админкой?
                                                            • 0
                                                              1. не самая понятная;
                                                              2. если я отправил форму сабмит вполне может меня на пред предыдущий страницу, и назад уже никак не вернуться не пройдя всю цепочку по меню ;
                                                              3. в мобильном или планшете, видно максимум левый верхний угол, если повезет, обычно же просто сразу приходится компьютер искать ибо с мобильного в админку заходить ничего хорошего не сулит;
                                                              4. Если допустим мне нужно восстановить состояние ноды после ее неудачного редактирования, то неплохо бы мне перед тем как я редактировать неудачно собрался чекбокс активировать и ей еще название написать, в нормальных ситуациях это должно работать примерно как в гугл докс, то что сейчас в друпале есть разве что для отмазки на если в тз туманные формулировки годится, в некоторых других смс известных для работы с редакциями даже инструмент есть которые диф показывают, и он наверное во всех 100% случаев нужен;
                                                              5. Если допустим я хочу ноду по редактировать и мой друг вася тоже захочет, то друпал даже не дернеца предотвратить такую оказию, не важно даже как бы хорошо это получилось, нет даже попыток в этом направлении
                                                              6. вот допустим создаю я в друпале меню, добавление каждого пункта меню требует какого как минимум два раза страницу рефрешить, плюс все эти указания веса, выбор родительского пункта и прочее что там есть не самый удобный экспириенс каждый раз приходится контент менеджеру целый талмуд писать со скриншотами и вопросы все равно остаются, а документация и how to всякие как уже выше говорилось на stack exchange туда особенно клиента не оправишь посмотреть
                                                              7. С блоками это просто содомия, сначала ты выбираешь в какой регион по всплывает монстроподобный popup ты там свой блок находишь, возможно даже через поиск, потом второй попап всплывает, там еще куча настроек, потом зачем то у каждого блока по умолчанию заголовок, как правило его нужно выключить, потом сохраняешь, потом страничка рефрешится (хотя казалось бы зачем если попап аяксовый был), потом выясняется что ты в неправильную позицию блок поставил потому что, идешь перетягиваешь потом листаешь портянку блоков вниз, сохраняешь, если кто-то хочет сказать что это удобно, то это он преувеличивает. А вот если у тебя друпал 8 и скажем firefox то может и popup не всплыть, потому что баг не всегда работает, ну вовсяком случае больше одного человека с этим сталкивались, ну это ладно допустим так надо с мобильных же не подредактируешь и с фаерфокса не надо заходить.
                                                              8. Так же простой активацией двух взаимоисключающих Фитч можно сайт полностью запороть и потом долго искать причину, конечно друпалисты так не делаю, но люди попроще часто с таким встречаются, с плагинами тоже самое пару галочек не там и приплыли, долго возвращаешь как было, хну это допустим из за большой гибкости, можно не считать за большой косяк
                                                              9. Или вот, сидишь такой в cck поле какое то хитрое долго настраиваешь уже на предпоследнем шаге, там миллион инпутов, и оп такой ширину 99 пикселей написал например, а максимальная 100 и сохранить нахал, все данный пропали, 99 красным посветило потому что налет у валидация в этом конкретном месте нет.
                                                                Экран редактирования ноды та же песня, вот хочешь дату поста отредактировать сразу идешь в пункт меню — Информация об авторе он еще в аккордеон свернут, что бы по полю вода даты никто не догадался сразу что она именно там вводится


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

                                                                Для drupal 7 конечно все было, но все это модули, сказанное и для него актуально.
                                                                Ещё в других альтернативных CMS обычно интерфейс от версии к версии все же в лучшую сторону меняется, а вот друпалл стабилен, остается прмерно на уровне 2008 года.

                                                                Так что с админкой у Drupal 7 все в порядке, я просто не совсем уверен с выбором цвета получается.
                                                              • 0
                                                                Половину этих проблем я никогда не встречал почему то, а вторая половина это вкусовщина. Имхо. Мне админка нравиться, особенно в Drupal 8. Конечно, может просто привык к ней.
                                                                Единственная проблема это интерфейс для управления медиа файлами. В ядре его вообще нету, а тот который в модуле Media тормозной и не удобный.
                                                  • 0

                                                    Я конечно все понимаю, но это как то больше смахивает на религию нежеле на какой то осмысленный выбор, хороший код да, круто я рад, недоделанный но зато написано красиво и управлять невозможно, если вы хотите сказать что там уязвимостей не было так, тоже нет были и это нестрашно потому что их фиксят, но хотелось бы чтоб релизы по мимо исправлений безопасности ещё что то содержали, а то в 2017 имеем модули которые либо не работают либо отсутсвует и админку в которой черт ногу сломит, и релизына которые никто не переходит потому что они не готовы, а больше и фитч от Cms и не требуется. Можно конечно долго друпал нахваливать но удовольствия с ним работать все меньше

                                                    • 0
                                                      В моём случае это именно осмысленный выбор. Я перепробовал множество CMF/CMS (могу назвать как минимум WordPress, Joomla, MODx), а также разработал несколько своих, но в итоге остановился именно на Drupal. И использую пока что именно Drupal 7 (под который таки есть огромное количество модулей и полностью нерабочих я среди них не встречал). Восьмёрку изучаю, ковыряю, но в продакшн она ещё не годится, о чём я неоднократно упоминал. Вот у восьмёрки неработающих и отсутствующих модулей полно, да. Годика полтора понадобится для допиливания — мой прогноз, я уже об этом говорил. Я и сам по мере сил способствую — создаю тикеты, пишу патчи и т.п. Подход мне нравится, с Symfony я раньше работал и имею хорошие воспоминания об этом.
                                                      Если в друпаловской админке «чёрт ногу сломит», то я и мои знакомые/коллеги гораздо круче всяких чертей. Просто надо понимать, что в друпале к чему относится и не искать, скажем, таксономию в настройках сайта — потому что её надо искать в разделе «структура».
                                                      И ещё раз: вы упорно путаете релизы ядра с готовностью экосистемы. Экосистема восьмёрки не готова, этого никто не скрывает и не отрицает. Экосистема — это как раз и есть модули, темы, документация, локализация и т.п. Её готовность не выразишь одним номером версии, разве что приблизительно в процентах.
                                                      Готовность экосистемы семёрки можно оценить минимум в 95%, я бы сказал — 99%. Чисто из-за того, что есть ещё фичи, которые можно было бы дописать — например, я тут как раз одну штуку для упрощения регистрации пользователей попиливаю, скоро выкачу в сообщество.
                                                      Шестёрка давно полностью готова к использованию, другое дело, что у неё уже есть проблемы с совместимостью со свежими версиями PHP, производительностью, ограничениями архитектуры и т.п. Поэтому оптимальна для использования именно 7 версия.
                                                      Я не говорю, что Drupal идеален — ничего идеального не бывает. Но это хороший, качественный инструмент и он соответствует моим задачам и вкусам. Я его не нахваливаю, но вы рассказываете про него какие-то ужасы, которых я лично не вижу как его постоянный пользователь и разработчик.
                                                      • 0
                                                        Шестёрка давно полностью готова к использованию, я понял, готовность к использованию примерно совпадает со сроком окончания поддержки пруф, благо хоть определились когда хорошо станет.
                                                        • 0
                                                          Она была готова задолго до окончания поддержки. И семёрка сейчас готова, хотя об окончании поддержки ещё и речи не идёт. Прогнозы по готовности восьмёрки я озвучивал уже два раза.
                                                          • 0

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

                                                            • 0
                                                              Друпал любят потому, что это современный законченный продукт, по крайней мере это относится к седьмой ветке.
                                                              Использовать восьмую вас никто не заставляет.
                                                              • 0

                                                                Ну ок, такое свеженькое легаси, придётся дальше юзать

                                                                • 0
                                                                  Ну если это легаси, то и атомные электростанции тоже легаси. Они кипятят водичку, чтобы турбины паром крутить, аки в девятнадцатом веке.
                                                                  А что там со стеллараторами и токамаками мутят — хз, взлетит-не-взлетит, но пока не работает. Но тащемта не повод выкидывать на помойку.
                                              • 0
                                                Я бы ещё добавил про друпал что писать JavaScript там отдельное удовольствие всю функциональность приходится оборачивать специальными костыликами чтобы они второй раз не вызывались

                                                Оборачивать надо как раз чтобы второй раз вызывалось, например когда придёт новый кусок dom.

                                                всякие там new Drupal.ajax(…

                                                Если вы пишите в своём js коде «new Drupal.ajax», то вы уже что-то делаете не так.
                                                • 0
                                                  А вы вордпресс смотрели? Особенно плагины, которые с каждым обновлением ломает сайт. А код? Спагетти из php-html-js в одном файле это нормально? Я работаю и с Drupal7, Drupal8 и wordpress.
                                                  А от Drupal.ajax их attachBehaviories я наоборот кайфую.)
                                                  • 0
                                                    в WordPress я волен писать скрипты удобным мне способом, если конкретно я будучи в добром здравии напишу плагин он будет скорее работать даже на старый дряхлых версиях 2.x и в будущем не сломает ничего, и мне для этого не нужно будет писать WordPress специфичный код если кто то даже этого не умеет сделать, это не значит что такому человеку будет attachBehaviories в радость, такие ребята обычно в друпале верстают внутри wysiwyg блоков, css там вставляют подключают скрипты с абсолютными путями.
                                                    От криворукости attachBehaviories не лечит и ядро WordPress еще реже деприкейтит что либо чем Drupal который между версиями несовместим.
                                                    Я таких универсальных разработчиков много раз по рукам бил и знаю как это происходит, те ребята что спагети пишут для WordPress Drupal просто уничтожают.

                                                    Так что не аргумент.
                                                    • 0
                                                      Забыл главное сказать.
                                                      WordPress почти нет официального способа смешать код и стили или скрипты

                                                      wp_enqueue_style — через это подключают css

                                                      wp_enqueue_script — через это подключают js

                                                      wp_localize_script — пробрасывают переменную из php в javascript

                                                      Лапшу можно сделать через это

                                                      wp_add_inline_script
                                                      или
                                                      wp_add_inline_style

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

                                                      На деле это так происходит:

                                                       print '<style type="text/css">
                                                        @font-face{font-family: '.$name.';
                                                      </style>';
                                                      


                                                      так чего тогда от людей такого пишущих такое ожидать в Drupal он тоже самое в html.tpl.php вставляют еще бывает в блоки добавляют через админку дабы в таком случае даже поиск по файлам не даст результатов что еще хуже, в итоге так же плохо получается или еще хуже если 'повезет'.

                                                      Это все никак не зависит от используемого фремворка.

                                                      Другое дело что WordPress минимум в 6 раз более распространен чем Drupal и по статистике чтобы такое с последним сделать, его еще нужно где то найти, редкость использования это опять же одно из сомнительный достижений Drupal.
                                                      • 0
                                                        WordPress почти нет официального способа смешать код и стили или скрипты


                                                        Ядро — https://github.com/WordPress/WordPress/blob/master/wp-login.php
                                                        Присутствует всё в одном месте — html, php, css, script. Особенно приятно смотрится конец файла.
                                                        • 0
                                                          ну и? как это меня касается как разработчика? Обычный же Legacy может когда нибудь поправят, факт в том что при всем этом форма входа у WordPress нормальная и красиво смотрится на мобильном а в Drupal убогая и страшная не смотря на все это, как с этим всем разработчикам ядра трудно жить мне как консьюмеру не очень интересно, у них еще и подежка php 5.2 в ядре и им это чем то нормальным кажется.

                                                          Я когда соберусь модуль или тему писать, это редактировать не буду.
                                                          Как это разработчиков коснется.

                                                          Тем более это не значит что при обновлении, что то сломается потому что именно эта часть вообще не обновляется (кеп) вопрос был именно в этом, то что не красиво никто не спорит.

                                                          Будет неудобно когда начну хакать ядро что ли?

                                                  • 0
                                                    Несколько поверхностно.
                                                    Например, ничего не сказано о Field API в Drupal, а этот механизм позволяет создавать произвольные поля у любой сущности. К примеру, можно прикрепить изображение к термину таксономии для каталога товаров. И это базовый функционал. Таким в WP не пахнет до сих пор, насколько мне известно.
                                                    Ничего не сказано и о качестве кода. Drupal имеет чёткие Coding Standards и автоматизированные средства для проверки кода на соответствие им. Спагетти-код WP — притча во языцех.
                                                    Ещё стОило бы указать, что обзор относится к 7-й версии Drupal. Сейчас в раработке версия 8, которая построена на несколько иных принципах.
                                                    Но в целом многие вещи описаны близко к реальности.
                                                    • 0
                                                      Таким в WP не пахнет до сих пор, насколько мне известно.
                                                      Насколько мне известно для WP есть куча CCK плагинов. Так что как минимум пахнет.
                                                      • 0
                                                        Ну так и в D6 поля реализовывались через CCK плагины. А в D7 это попало в ядро и обзавелось официальным API.
                                                      • 0
                                                        ничего не сказано о Field API в Drupal

                                                        Сказано — см. раздел «Типы контента и поля». Там же про то, как это «пахнет» в WP.

                                                        Ничего не сказано и о качестве кода

                                                        Качество кода — вещь субъективная. А «чёткие Coding Standards» есть у большинства систем, что у WP, что у Joomla.

                                                        Ещё стОило бы указать, что обзор относится к 7-й версии Drupal.

                                                        Это сказано в первом же абзаце.
                                                      • 0

                                                        Не скажу за WordPress, с Drupal уже лет 6 работаю. Главное го преимущество — возможность кастомизации. Практически каждый модуль написан так, чтобы его можно было легко поменять под себя. Например, не нравится какие действия происходят при сабмите формы — можно поменять или добавить свои действия. И так почти во всем. Обратная сторона этого — многие сайты содержат сотню модулей, функционал которых не используется на половину.

                                                        • 0

                                                          Сила WP в гигантском количестве плагинов и тем — то есть по сути готовых решений.
                                                          Еще можно добавить, что есть куча готовых рецептов, которые до сих пор актуальны из-за хорошей совместимости.
                                                          Плюс дружелюбие редактора надо не забыть.


                                                          На этом я бы сказал все плюсы WP заканчиваются, так, как:


                                                          • Расширения в большинстве своем ужасны. То есть если взять популярные CMS и посчитать толковые расширения для них, их число будет примерное одинаковое для каждой из них.
                                                          • WP реальный тормоз, да его можно закостылить, но в целом, он тормоз из коробки, мне даже сложно это объяснить, так как по сути из коробки там же ничего нет.
                                                          • Чтоб довести его до вменяемого состояния, надо поставить десяток плагинов. Собственно наблюдая за разговорами WP по сути получается, что надо постоянно держать в голове пачку плагинов необходимых.
                                                          • Ужасный код… наверное самый ужасный из популярных CMS. Я понимаю, что совместимость, все дела… но правда смотришь и слезы наворачиваются, особенно на плагины.

                                                          Лично мое мнение WordPress можно называть универсальной CMS, но если реально взглянуть на него, то он все тот же блоговый движок, из которого решили сделать комбайн.

                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                          Самое читаемое