Отчет о статусе в Drupal часто показывает предупреждения, которые засоряют административный интерфейс. Мы создали модуль Requirements Manager, чтобы скрывать или изменять эти требования через простой пользовательский интерфейс вместо написания индивидуального кода для каждого проекта.
Вы знаете, как это бывает. Вы заходите в отчет о статусе Drupal, чтобы проверить, нужно ли что-то исправить, и видите стену предупреждений, которые видели уже десятки раз.
Некоторые предупреждения важны. Другие — нет. Возможно, вы отслеживаете уведомления об обновлениях в собственном Gitlab и вам не нужно постоянное напоминание. Возможно, это уведомление об устаревшем коде PHP, о котором вы уже знаете и планируете устранить во время следующего планового обновления. Или же вы видите предупреждения, специфичные для вашей среды, которые просто не применимы к вашей инфраструктуре.
Проблема «шумного» отчета о статусе
Проблема заключается в том, что все эти предупреждения соседствуют с реальными проблемами, требующими вашего внимания. Шум заглушает сигнал. В итоге вы прокручиваете одни и те же нерелевантные сообщения каждый раз, увеличивая шанс пропустить что-то важное.
Со временем у вас развивается «слепота к предупреждениям». Ваш мозг учится полностью игнорировать страницу отчета о статусе, потому что соотношение сигнала к шуму слишком низкое. Затем, когда появляется реальное обновление безопасности или возникает проблема с геометрией базы данных, оно теряется в привычном море оранжевых и красных уведомлений.
Эта проблема умножается в командах. Каждый разработчик самостоятельно решает, какие предупреждения игнорировать. Новые члены команды не знают, какие предупреждения важны, а какие являются «шумом» среды. Отчет о статусе становится ненадежным, теряя свое основное назначение.
Как работает Requirements Manager
Чтобы решить эту проблему, мы разработали Requirements Manager. Модуль предоставляет централизованный интерфейс, где вы можете управлять каждым требованием, которое генерирует ваш сайт: скрывать их, менять уровень серьезности или оставлять как есть. Теперь вы можете скрыть требование или изменить его уровень серьезности и задокументировать причину.
Модуль работает прозрачно. Когда вы изменяете уровень серьезности требования, он добавляет примечание к отчету о статусе, показывающее, что именно изменилось и почему:
«Уровень серьезности изменен с "Warning" на "Info" модулем Requirements Manager. Причина: лимит памяти контролируется хостинг-провайдером, предупреждение не требует действий».
Любой, кто просматривает отчет о статусе, может немедленно увидеть, какие требования были изменены и понять логику каждого решения. Больше не нужно заниматься «археологией» документации.
Почему это важно для вашего проекта
Модуль Requirements Manager демонстрирует принципы, полезные для любого проекта на Drupal:
- Сохранение институциональных знаний. Поле «Причина» гарантирует, что когда разработчики уходят или команды меняются, критически важный контекст не исчезает. Новые члены команды понимают, почему были приняты те или иные решения, без необходимости копаться в коде или проводить дорогие сессии по передаче знаний.
- Безопасность через ясность. Реальные ошибки не теряются в шуме. Когда ваш отчет о статусе чист, а каждое изменение прозрачно, подлинные проблемы безопасности и критические обновления сразу бросаются в глаза. Ваша команда может сосредоточиться на том, что действительно требует внимания.
Типичные сценарии использования
На основе нашей клиентской работы и отзывов сообщества Drupal мы выделили конкретные сценарии, где модуль Requirements Manager оказывается особенно полезным:
- Ограничения управляемого хостинга: Ваш хостинг-провайдер контролирует версии PHP и уже запланировал обновление до PHP 8.3 на следующий квартал. Предупреждение «Версия PHP будет не поддерживаться» верно, но ваша команда не может ничего с этим сделать. Понизьте его до уровня «Info» с примечанием: «Хостинг-провайдер обновляет систему в Q2 2026».
- Плановые окна обслуживания: Вы выявили обновление безопасности, но запланировали его на следующий месяц в рамках утвержденного плана обслуживания. Задокументируйте план («Запланировано на обслуживание в марте, тикет №1234») и временно понизьте уровень серьезности, чтобы ежедневные проверки статуса не создавали ложной срочности.
- Развертывание в нескольких средах: На продакшене используются внешние инструменты мониторинга для отслеживания обновлений, но среда стейджинга полагается на встроенные проверки Drupal. Используйте модуль Config Split, чтобы скрыть статус обновлений на продакшене, сохранив видимость на стейджинге — один и тот же код, разные конфигурации для разных сред.
- Особенности сторонних модулей: Включенный модуль сообщает о «несоответствии схемы базы данных», которое вы подтвердили как ложное срабатывание логики проверки модуля. Вы сообщили об ошибке разработчикам модуля. Скройте предупреждение со ссылкой на проблему: «Ложное срабатывание, см. drupal.org/i/1234».
Почему мы создали Requirements Manager
Мы заметили закономерность в клиентских проектах. На каждом сайте, который мы строили или обслуживали, было по три-пять требований, которые уже имели запланированные решения или были чистым шумом.
Мы решили создать модуль Requirements Manager как вклад в сообщество Drupal. Цель была проста: заменить повторяющийся кастомный код экспортируемой конфигурацией со встроенной документацией.
Вот как выглядел старый подход:
/**
* Implements hook_requirements_alter().
*/
function mysite_requirements_alter(array &$requirements): void {
// Content views require a status filter to avoid content access issues.
unset($requirements['node_status_filter']);
// Downgrade PHP memory warning - adequate for this use case.
if (isset($requirements['php_memory_limit'])) {
$requirements['php_memory_limit']['severity'] = REQUIREMENT_INFO;
}
}
Начало работы
Requirements Manager уже доступен на drupal.org, он бесплатен и открыт для сообщества Drupal.
Установите Requirements Manager как любой другой модуль Drupal:
composer require drupal/requirements_manager
drush en requirements_manager
Перейдите в Конфигурация → Система → Requirements Manager (/admin/config/system/requirements-manager).
Вы увидите таблицу со всеми текущими требованиями. Для каждого требования, которое вы хотите изменить, выберите действие из выпадающего списка. Когда вы выбираете «Скрыть» (Hide) или «Изменить серьезность» (Change severity), появляются дополнительные поля для выбора нового уровня и вашей причины.
Лучшая практика: Всегда заполняйте поле «Причина». Хорошая причина объясняет контекст: «Отслеживается в тикете №1234, запланировано на обновление в Q2» или «Не применимо для тестовых сред» или «Контролируется хостинг-провайдером, действия не требуются».
Нажмите «Сохранить конфигурацию», а затем перейдите в /admin/reports/status, чтобы проверить изменения. Экспортируйте свою конфигурацию для сохранения настроек в разных средах:
drush cex -y
Одна полезная особенность: если вы скрываете требование, оно все равно отображается в административной форме с пометкой «(скрыто этим модулем)». Это значит, что вы всегда можете снова показать требование, изменив действие обратно на «Показать».
У Requirements Manager есть одно ограничение по производительности. Административная форма вызывает SystemManager::listRequirements(), который запускает все хуки требований из всех включенных модулей. На сайтах с большим количеством модулей форма может загружаться несколько секунд.
Что еще более важно, не используйте Requirements Manager для скрытия реальных ошибок, которые нужно исправить. Этот инструмент предназначен для управления шумом и специфическими для среды предупреждения, а не для маскировки настоящих проблем. Если ваша база данных действительно устарела или версия PHP не поддерживается, скрытие предупреждения не решит основную проблему.
Реальный пример конфигурации
После настройки требований через интерфейс ваши настройки сохраняются в requirements_manager.settings.yml. Вот как выглядит типичная конфигурация:
requirements:
php_memory_limit:
action: change_severity
severity: info
reason: 'Memory limit controlled by hosting provider, warning not actionable'
cron_last:
action: change_severity
severity: warning
reason: 'Upgraded from info to ensure cron monitoring'
Конфигурация хранит только значения, отличные от стандартных. Если вы устанавливаете действие «Показать» (по умолчанию), оно полностью удаляется из конфигурации. Это сохраняет ваши конфиг-экспорты чистыми и делает немедленно очевидным, какие именно требования вы кастомизировали.
Под капотом: современные разработки в Drupal
Requirements Manager использует возможности, представленные в Drupal 11.2, что делает код готовым к будущему и соответствующим стандартам. Используя последние соглашения Drupal, мы сводим к минимуму технический долг и обеспечиваем совместимость модуля с будущими версиями Drupal.
Модуль использует перечисление RequirementSeverity вместо устаревших целочисленных констант, что обеспечивает лучшую типизацию и более понятный код:
protected const SEVERITY_MAP = [
'info' => RequirementSeverity::Info,
'ok' => RequirementSeverity::OK,
'warning' => RequirementSeverity::Warning,
'error' => RequirementSeverity::Error,
];
Мы реализуем хук с помощью атрибутов PHP 8 вместо файла .module:
#[Hook('runtime_requirements_alter', order: Order::Last)]
public function runtimeRequirementsAlter(array &$requirements): void {
$overrides = $this->configFactory
->get('requirements_manager.settings')
->get('requirements') ?? [];
foreach ($overrides as $key => $override) {
if (!isset($requirements[$key])) {
continue;
}
$action = $override['action'] ?? 'show';
switch ($action) {
case 'hide':
unset($requirements[$key]);
break;
case 'change_severity':
$requirements[$key]['severity'] = self::SEVERITY_MAP[$override['severity']];
break;
}
}
}
Параметр Order::Last является ключевым. Он гарантирует, что изменения Requirements Manager выполняются после всех остальных модулей, которые внесли свои требования. Это предотвращает случайное изменение наших переопределений другими модулями и защищает от тонких ошибок при обработке требований.
Используя атрибуты PHP 8 и современные паттерны Drupal, мы обеспечиваем долговечность этого кода. Сайты, построенные на текущих стандартах, избегают дорогостоящих переписываний, которые часто случаются с проектами, созданными с использованием устаревших подходов.
Заключение
Если вы столкнулись с той же проблемой — сообщения в отчетах о статусе не точно отражают текущее состояние вашего проекта (а вы, скорее всего, столкнулись), — этот модуль станет отличным дополнением к вашему инструментарию. Он прост, удобен в использовании, производителен и предоставляет полезную функциональность для команд, обслуживающих сайты.
