Drupal редко ломается на контенте — чаще его ломают архитектурой

Drupal редко ломается на контенте — чаще его ломают архитектурой

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

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

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

Главная ошибка при старте — пытаться собрать Drupal как набор модулей «на всякий случай». Нормальная схема другая: сначала карта контента, потом роли, потом кэширование и только после этого выбор модулей. Так платформа не превращается в набор случайных костылей.

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