Поддержка сайтов на Drupal: что важно знать

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

Обновления безопасности: почему среда — важный день

Drupal Security Team публикует исправления по средам. Такой предсказуемый график сделан осознанно: команды сопровождения могут заранее выделить окно под обновление, а не реагировать на уязвимость в произвольный момент.

Обновления делятся на две категории, и путать их не стоит:

• Обновления ядра. Выходят реже, но затрагивают всё. Патч-релизы — те, где меняется только последняя цифра версии, — обычно безопасны и накатываются штатно. Минорные, где меняется вторая цифра, могут менять поведение API и требуют проверки.
• Обновления модулей. Основной источник уязвимостей на практике. Контрибным модулем занимается мейнтейнер-энтузиаст, и качество кода здесь разнится сильнее, чем в ядре.

Отдельная категория риска — модули, у которых нет активного мейнтейнера. Если проект помечен как unsupported, уязвимость в нём никто не закроет. Такой модуль нужно либо заменять, либо брать поддержку на себя.

Кэширование: где на самом деле теряется скорость

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

В Drupal многоуровневая система кэширования, и понимать её стоит целиком:

• Render cache — кэш отрендеренных фрагментов страницы. Работает на уровне блоков, узлов, полей.
• Dynamic Page Cache — кэширует страницу для авторизованных пользователей, вырезая персонализированные части.
• Internal Page Cache — полностью готовые страницы для анонимных посетителей.
• Cache tags — механизм инвалидации. Именно он отвечает за то, чтобы изменённый материал исчез из кэша везде, где он показывался.

Чаще всего проблемы возникают не с самим кэшем, а с тегами. Если у блока не проставлены нужные cache tags, посетители будут видеть устаревшие данные. Если тегов, наоборот, слишком много — кэш сбрасывается при любом чихе и перестаёт приносить пользу.

Модули: меньше — почти всегда лучше

На Drupal.org больше 50 тысяч модулей, и соблазн решить каждую задачу установкой готового решения велик. Через пару лет такой подход оборачивается сайтом со ста включёнными модулями, половина из которых используется одной страницей.

Разумный подход к выбору модуля:

• Посмотрите дату последнего коммита и число открытых критичных issue.
• Проверьте, есть ли стабильный релиз под вашу версию ядра, а не только dev-ветка.
• Оцените, не проще ли решить задачу конфигурацией Views или небольшим кастомным модулем на 50 строк.

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

Контроль регрессий

Главный страх при обновлении — сломать то, что работало. Снять его помогает не героизм, а простая инфраструктура:

• Отдельный стенд. Копия боевого сайта, где обновление проверяется до выката.
• Configuration Management. Конфигурация Drupal хранится в YAML и версионируется в Git — состояние сайта перестаёт быть тайной, живущей только в базе.
• Проверка ключевых сценариев. Даже ручной чек-лист из десяти пунктов («форма заявки отправляется», «поиск находит», «личный кабинет открывается») ловит большинство регрессий.

Что в итоге

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