Desarrollador Drupal para actualizaciones, migraciones y módulos

Administraciones, universidades y entidades

Drupal es habitual donde una organización gestiona muchos sitios, muchos editores y permisos detallados: ayuntamientos, comunidades autónomas, universidades y fundaciones, a menudo con contenido en castellano y en otra lengua cooficial. En el sector público se aplica el Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público. Reviso la accesibilidad en cada migración.

Lo que hago

Actualizaciones de seguridad con un flujo de Composer repetible, migración desde Drupal 7 a una instalación nueva de Drupal 11 y paso de 10 a 11, módulos y temas a medida, despliegues con Drush, caché y optimización de base de datos, integraciones con sistemas externos e inicio de sesión único, y frontends headless que leen el contenido por JSON:API.

Lo que evito

No te propongo rehacer el sitio ni pasarte a WordPress cuando Drupal encaja con tu organización. Varios sitios en una instalación, roles editoriales detallados y contenido multilingüe son puntos fuertes de Drupal. La migración entre Drupal y WordPress, en cualquier sentido, solo la planteo cuando el sitio ha superado la plataforma o el equipo no puede mantenerla.

¿Cómo es una migración de Drupal 7 a Drupal 11?

Drupal 7 no se actualiza sobre el propio sitio. Monto una instalación nueva de Drupal 11 y paso contenidos, usuarios, archivos y taxonomías con los módulos Migrate y Migrate Drupal del núcleo, y ejecuto drush migrate:import en el entorno de pruebas hasta que el número de registros coincide con la base de datos antigua. Si tu web publica en castellano y en otra lengua cooficial, reviso primero cómo enlazaba Drupal 7 las traducciones, porque de eso depende que cada página conserve su versión en catalán, valenciano, gallego o euskera. Las vistas de Views las rehago a mano, las field collections suelen pasar a Paragraphs y el tema PHPTemplate se sustituye por uno nuevo en Twig. Migrate Drupal está marcado como obsoleto y desaparece en Drupal 12.0 sin sustituto, así que un sitio en Drupal 7 debe pasar ya a Drupal 11. Las URL antiguas reciben redirecciones con el módulo Redirect.

¿Qué se revisa antes de actualizar Drupal 10 a 11?

En una copia del sitio instalo el módulo Upgrade Status con Composer. Ejecuta PHPStan sobre el código propio y los módulos contribuidos, se apoya en drupal-check y lista llamadas a APIs obsoletas y módulos que aún no tienen versión para Drupal 11. Las correcciones mecánicas las hace Drupal Rector (paquete palantirnet/drupal-rector), y yo reviso cada línea reescrita. El sitio tiene que estar ya en Drupal 10.3.0 o posterior, porque Drupal 11 eliminó las funciones de actualización de versiones anteriores, y el servidor necesita PHP 8.3 o superior; si tu web está en la infraestructura de una diputación, esa versión se pide con antelación. Basta un módulo sin versión para Drupal 11 para que Composer no pueda resolver toda la actualización. Si el módulo solo necesita otra restricción de versión, el plugin Drupal Lenient de Composer lo instala con un parche; si su código falla, lo corrijo o lo sustituyo. composer update --dry-run muestra qué caso es antes de cambiar nada. Recibes una estimación por módulo, útil para el pliego de prescripciones técnicas.

¿Qué incluye el mantenimiento mensual de un Drupal?

Las versiones de seguridad del núcleo de Drupal salen un miércoles al mes, normalmente el tercero, y los módulos contribuidos pueden recibirlas cualquier miércoles, entre las 16:00 y las 22:00 UTC, es decir, por la tarde y la noche en la península. Leo el aviso esa misma noche y el jueves por la mañana la actualización está en el entorno de pruebas. El orden no cambia: composer update de los paquetes afectados, drush updatedb, drush config:export, revisión de las páginas que más usa el equipo editorial, copia de seguridad de la base de datos y los archivos, y después el paso a producción. Las versiones menores del núcleo siguen el mismo camino unas semanas más tarde, cuando sale la primera versión de correcciones. La exportación está en la lista porque una función de actualización puede cambiar la configuración activa, y si ese cambio no llega al directorio de sincronización, el siguiente despliegue con drush config:import lo revierte. En el contrato dejamos por escrito el tiempo de respuesta ante un aviso crítico y quién aprueba el paso a producción, para que un parche no espere a una firma.