<b>Drupal не «тяжёлый», если не тащить в него хаос: 5 правил для живого проекта</b>

<b>Drupal не «тяжёлый», если не тащить в него хаос: 5 правил для живого проекта</b>

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

За неделю в репах обычно всплывают одни и те же ошибки:
— слишком много типов сущностей без понятной модели;
— поля и view-слои смешаны с бизнес-логикой;
— права доступа настраиваются «по месту», а не по матрице ролей;
— кастомный код дублирует то, что уже умеют модули.

Если проект контентный, держите правило простым: одна сущность — одна ответственность. Не превращайте ноду в свалку из 40 полей, если половина из них нужна только для одного шаблона.

Для mid-стека Drupal особенно хорош там, где есть:
— много ролей и уровней доступа;
— сложные формы и редакторские workflow;
— несколько витрин, языков или каналов публикации;
— интеграции с CRM, DAM, поиском, PIM.

Есть наблюдение которое стоит проверить: Drupal начинает выигрывать не на «простых сайтах», а там, где цена ошибки в структуре контента выше цены внедрения. Если нужен лендинг без логики — это перебор. Если нужен управляемый контент-слой на годы — уже кандидат.

Главный совет: сначала рисуйте модель данных и права, и только потом интерфейс. В Drupal это экономит больше, чем любая «оптимизация» после запуска.