Quizás esto te suene. Accedes al Informe de estado de Drupal para comprobar si algo requiere atención y aparece un muro de advertencias ya visto decenas de veces.
Algunas advertencias son importantes. ¿Otras? No tanto. Quizá se esté realizando el seguimiento de una notificación de actualización en GitLab y no sea necesario el recordatorio constante. Tal vez exista un aviso de obsolescencia de PHP del que ya se tenga constancia y se planee abordar durante la próxima actualización programada. O quizá se muestran advertencias específicas del entorno que no se aplican a la configuración de la infraestructura.
El problema del informe de estado demasiado ruidoso
El problema reside en que todas estas advertencias conviven con problemas reales que sí requieren atención. El ruido oculta la señal. Se termina echando un vistazo rápido sobre los mismos mensajes irrelevantes de siempre, aumentando la probabilidad de pasar por alto algo que sí sea importante.
Con el tiempo, se desarrolla "ceguera ante las advertencias". El cerebro aprende a ignorar por completo la página del informe de estado porque la relación señal-ruido es demasiado baja. Así, cuando aparece una actualización de seguridad real o surge un problema en el esquema de la base de datos, este se confunde con el ya familiar océano de color naranja y rojo.
Este problema se multiplica en los equipos. Cada desarrollador decide de forma independiente qué advertencias ignorar. Quien entra de nuevas al equipo no tiene forma de saber qué avisos son relevantes y cuáles son ruido del entorno. El informe de estado deja de ser una herramienta fiable, perdiendo así su propósito fundamental.
Cómo funciona Requirements Manager
Para abordar este problema, se ha desarrollado Requirements Manager. El módulo proporciona una interfaz centralizada donde se puede gestionar cada requisito del sitio, pudiendo ocultarlos, cambiar su gravedad o dejarlos como están. Así, es posible ocultar un requisito o modificar su nivel de gravedad, además de indicar el motivo.
Requirements Manager dashboard with a list of configurable security settings.
El módulo funciona de forma transparente. Al modificar la gravedad de un requisito, se añade un aviso al informe de estado que muestra exactamente qué ha cambiado y por qué:
''Severity altered from "Warning" to "Info" state by Requirements Manager. Reason: Memory limit controlled by hosting provider, warning not actionable''
Cualquier persona que consulte el informe de estado puede ver de inmediato qué requisitos se han personalizado y comprender la razón tras cada decisión, lo que evita tener que hacer arqueología en la documentación del proyecto.
Info message altered by Requirements Manager from the status report page
Por qué esto es importante para un proyecto
Requirements Manager aporta unos principios que benefician a cualquier proyecto de Drupal:
- Preservar el conocimiento institucional. El campo "Reason" garantiza que el contexto crítico no desaparezca cuando los desarrolladores se marchen o los equipos cambien. Los nuevos miembros del equipo entenderán por qué se tomaron ciertas decisiones sin necesidad de hacer largas búsquedas en el código o costosos procesos de transferencia de conocimientos.
- Seguridad mediante la claridad. Los errores reales no se pierden entre el ruido. Cuando el informe de estado está limpio y cada alteración es transparente, los problemas de seguridad genuinos y las actualizaciones críticas destacan de inmediato. El equipo puede centrarse en lo que realmente requiere atención.
Casos de uso típicos
A través del trabajo con clientes y de lo que se comenta en la comunidad de Drupal, se han identificado escenarios específicos donde Requirements Manager puede resultar muy útil.
- Limitaciones del alojamiento gestionado: el proveedor de alojamiento controla las versiones de PHP y ya ha programado una actualización a PHP 8.3 para el próximo trimestre. La advertencia "PHP version will be unsupported" es correcta, pero el equipo no tiene capacidad para actuar sobre ella ya que depende del proveedor de alojamiento. Se puede reducir al estado "Info" con una nota: "Será actualizado por el proveedor de alojamiento en el segundo trimestre de 2026".
- Ventanas de mantenimiento planificadas: se ha identificado una actualización de seguridad, pero se ha programado para la ventana de mantenimiento del próximo mes tras la aprobación de las personas responsables. Se documenta el plan ("Programado para el mantenimiento de marzo, ticket #1234") y se reduce temporalmente la gravedad para que las comprobaciones de estado diarias no creen una falsa urgencia.
- Despliegues en múltiples entornos: si producción utiliza herramientas de monitorización externas para comprobar actualizaciones, pero el entorno de preproducción depende de las comprobaciones integradas de Drupal, se puede utilizar Config Split para ocultar el estado de las actualizaciones en producción manteniendo su visibilidad en preproducción: mismo código base, diferente configuración por entorno.
- Particularidades de módulos de terceros: un módulo informa de un error de "database schema mismatch" que se ha constatado que es un falso positivo debido a un fallo en la lógica de detección del módulo. Se ha reportado el problema en la cola de issues del módulo, por lo que se oculta la advertencia con un enlace a la incidencia: "Falso positivo, consultar drupal.org/i/1234".
Por qué hemos creado Requirements Manager
En Metadrop, observamos un patrón común en los proyectos de los clientes. Cada uno de los sitios que desarrollamos o mantenemos presenta entre tres y cinco requisitos que ya tenían soluciones planificadas o eran ruido.
Decidimos desarrollar Requirements Manager como una contribución a la comunidad de Drupal. El objetivo era sencillo: sustituir el código personalizado repetitivo por una configuración exportable que incluyera el motivo de cada cambio en cada requisito.
Este era el aspecto del enfoque manual anterior:
/**
* Implements hook_requirements_alter().
*/
function mysite_requirements_alter(array &$requirements): void {
// Las vistas de contenido requieren un filtro de estado para evitar problemas de acceso.
unset($requirements['node_status_filter']);
// Reducir la advertencia de límite de memoria PHP: adecuado para este caso de uso.
if (isset($requirements['php_memory_limit'])) {
$requirements['php_memory_limit']['severity'] = REQUIREMENT_INFO;
}
}Usar un módulo específico refleja mejor la filosofía de Metadrop: se construye para el mantenimiento a largo plazo, por lo que se desarrolla un módulo contrib para tal fin.
Primeros pasos
Requirements Manager está disponible en drupal.org y, como todos los módulos de Drupal, de forma abierta y Open Source para la comunidad de Drupal.
Se instala Requirements Manager como cualquier otro módulo de Drupal:
composer require drupal/requirements_manager
drush en requirements_managerDespués, acceder a Configuración → Sistema → Requirements Manager (/admin/config/system/requirements-manager).
Aparecerá una tabla con todos los requisitos actuales. Para cada uno que se desee modificar, se selecciona una acción del desplegable. Al elegir "Hide" o "Change severity", aparecerán campos adicionales para el nuevo nivel de gravedad y el motivo.
Buena práctica: se recomienda completar siempre el campo "Reason". Una buena explicación aclara el contexto: "Seguimiento en la incidencia #1234, planificado para la actualización del segundo trimestre", "No aplicable en entornos de desarrollo" o "Controlado por el proveedor de alojamiento, no podemos actuar al respecto".
Clicar en Guardar configuración y, a continuación, visitar /admin/reports/status para verificar los cambios. Se exporta la configuración para preservar los ajustes en todos los entornos:
drush cex -yUna característica a mencionar: si se oculta un requisito, lógicamente este sigue apareciendo en el formulario de administración con la etiqueta "(hidden by this module)", de forma que siempre se pueden volver a mostrar los requisitos más adelante cambiando la acción de nuevo a "Hide".
Requirements Manager tiene una consideración de rendimiento que conviene tener en cuenta. El formulario de administración llama a SystemManager::listRequirements(), lo que invoca todos los hooks de requisitos de todos los módulos habilitados. En sitios con muchos módulos, el formulario puede tardar unos segundos en cargar.
Lo más importante es saber cuándo NO se debe usar Requirements Manager: no se deben ocultar errores reales que requieran una solución. Esta herramienta sirve para gestionar el ruido y las advertencias específicas del entorno, no para enmascarar problemas reales. Si la base de datos está realmente desactualizada o la versión de PHP no tiene soporte, ocultar la advertencia no resuelve el problema subyacente.
Un ejemplo de configuración
Tras configurar los requisitos mediante la interfaz de usuario, los ajustes se almacenan en requirements_manager.settings.yml. Este es el aspecto de una configuración típica:
requirements:
php_memory_limit:
action: change_severity
severity: info
reason: 'Límite de memoria controlado por el proveedor de alojamiento, la advertencia no requiere actuación'
cron_last:
action: change_severity
severity: warning
reason: 'Aumentado desde "información" para asegurar la monitorización del cron'
La configuración solo almacena valores que no sean los predeterminados. Si se establece la acción de un requisito en "Hide" (el valor por defecto), este se elimina por completo de la configuración. Esto mantiene limpias las exportaciones de configuración y permite identificar de inmediato qué requisitos han sido personalizados.
Internamente: desarrollo actual en Drupal
Requirements Manager aprovecha las características introducidas en Drupal 11.2, lo que hace que el código sea compatible con los estándares y esté preparado para el futuro. Al utilizar las convenciones más recientes de Drupal, se minimiza la deuda técnica y se garantiza que el módulo siga siendo compatible con futuras versiones de Drupal.
El módulo utiliza el enumerado RequirementSeverity en lugar de las constantes de enteros obsoletas, lo que proporciona una mejor seguridad de tipos y un código más claro:
protected const SEVERITY_MAP = [
'info' => RequirementSeverity::Info,
'ok' => RequirementSeverity::OK,
'warning' => RequirementSeverity::Warning,
'error' => RequirementSeverity::Error,
];Se implementa el hook utilizando atributos de PHP 8 en lugar de un archivo .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;
}
```
}
}El parámetro Order::Last es fundamental. Garantiza que las alteraciones de Requirements Manager se ejecuten después de que el resto de módulos hayan aportado sus requisitos, evitando que las modificaciones sean alteradas inadvertidamente o que surjan inconsistencias sutiles al gestionar los requisitos.
Al emplear atributos de PHP 8 y patrones modernos de Drupal, se asegura de que este código envejezca bien. Los sitios construidos con los estándares actuales evitan las costosas reescrituras que sufren los proyectos desarrollados con enfoques heredados.
Conclusión
Si lidias con mensajes en los informes de estado que no reflejan con precisión la situación actual de un proyecto, algo probable si usas Drupal, este módulo es una buena incorporación a tu caja de herramientas. Es sencillo, fácil de usar, eficiente y proporciona una funcionalidad muy útil para los equipos que mantienen sitios web.
El módulo se ha construido teniendo en cuenta la filosofía de Metadrop: resolver problemas complejos de Drupal con una arquitectura limpia y mantenible, y compartir el resultado. Contribuimos activamente al ecosistema de Drupal porque creemos en la creación de soluciones que beneficien a todo el mundo, no solo a nuestros clientes.
