Модули Drupal: что говорят цифры и чего они не говорят

В каталоге Drupal.org — тысячи проектов, но эта цифра не отвечает на главный вопрос владельца сайта: безопасно ли ставить конкретный модуль и кто будет его поддерживать. Для Drupal 10 и 11 полезнее считать не размер каталога, а число сторонних зависимостей в вашем проекте, их совместимость и стоимость обновлений.

Почему число модулей — слабый показатель

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

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

Главная цифра — не сколько модулей есть в каталоге, а сколько внешних компонентов вашей команде предстоит обновлять, проверять и поддерживать.

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

Какие цифры считать у себя

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

• Внешние зависимости. Сколько сторонних проектов требуется сайту, включая транзитивные зависимости, которые добавили другие компоненты.
• Неподдерживаемые или ограниченные версии. Есть ли в дереве зависимостей проекты без подходящего релиза для вашей основной версии Drupal.
• Критичность. Какие модули влияют на вход пользователей, платежи, публикацию материалов или другие операции, остановка которых дорого обходится.
• Доля собственного кода. Сколько задач закрывают кастомные модули, а сколько — проекты сообщества. Большой объём собственного кода не обязательно плох, но он увеличивает ответственность команды.
• Цена обновления. Сколько времени уходит на проверку обновлений в тестовой среде и исправление несовместимостей. Записывайте фактические трудозатраты по релизам, а не предполагаемую «стоимость поддержки».

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

Как принять решение перед установкой

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

1. Уточните, есть ли нужная возможность в ядре Drupal или уже подключённой зависимости. Проверка: вы можете объяснить, какую конкретно задачу решает новый проект.
2. На Drupal.org откройте страницу проекта и проверьте заявленную совместимость, релизы, документацию и активные задачи. Проверка: выбранная версия подходит вашему Drupal и не требует неподдерживаемой ветки.
3. Посмотрите, какие дополнительные зависимости добавятся. Проверка: список компонентов зафиксирован и понятен, включая зависимости второго уровня.
4. Установите модуль сначала в тестовой среде и проверьте критические сценарии сайта. Проверка: автоматические тесты и ручная приёмка проходят на том же окружении, что и планируемый релиз.
5. Запишите владельца обновления и критерий отказа от модуля. Проверка: в команде понятно, кто проверит следующий выпуск и что делать, если сопровождение прекратится.

Менеджер зависимостей Composer помогает зафиксировать версии проектов Drupal в проекте и проверять ограничения, но он не заменяет оценку качества самого модуля. И наоборот: хорошая страница проекта не гарантирует, что обновление безболезненно пройдёт на вашем сайте.

Где подход ломается

У подсчётов есть предел. Число зависимостей не показывает, насколько они важны: небольшой модуль авторизации может быть критичнее нескольких декоративных дополнений. А количество выпусков не равно скорости реакции на уязвимости или качеству тестирования.

Не делайте вывод о надёжности по одному признаку — например, только по дате последнего релиза или числу установок. Проект может выпускаться редко, но оставаться совместимым и сопровождаться; может быть активно обновляемым, но не подходить вашей архитектуре. Проверяйте контекст и закладывайте тестирование обновлений.

Ещё один граничный случай — крупное обновление Drupal. Совместимость модуля с текущей основной версией не обещает готовности к переходу на следующую. Перед миграцией составьте отдельный список блокирующих зависимостей и проверьте актуальные инструкции проекта.

Что делать дальше

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

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