menu
Drupal 9 explicado
El próximo tres de junio se publicará la novena versión mayor de Drupal.
Históricamente, una nueva versión de este tipo no solo suponía la incorporación de una colección, a veces abrumadora, de nuevas características; si no que rompía lo que en informática denominamos la compatibilidad hacia atrás, obligado a los programadores a adaptar sus módulos y temas contribuidos y a los dueños de sitios, en la mayoría de los casos, a reconstruirlos usando la nueva versión.
Por suerte, la novena versión que se publicará en unos escasos quince días, supone un cambio en este paradigma. Actualizar el sitio de Drupal 8.9 a 9.0 será tan sencillo como actualizar de Drupal 8.8 a 8.9.
Veamos cómo se ha conseguido esto.
El problema: nuevas características vs. compatibilidad hacia atrás
Todo sistema informático, con el paso del tiempo, incorpora nuevas características e intenta mantener la compatibilidad hacia atrás. Desgraciadamente, ambos conceptos actúan como fuerzas opuestas: sistemas que se preocupen de mantener la compatibilidad hacia atrás harán casi imposible la incorporación de nuevas características y, en el caso contrario, incorporar muchas novedades hará imposible mantener la compatibilidad con paquetes antiguos.
Este último caso ha sido hasta ahora la tónica en Drupal. Para mantener un alto grado de innovación, se optó por desarrollar cada nueva versión desde cero, sin tener en cuenta ni módulos ni temas contribuidos ni sitios antiguos y convirtiendo cada nueva versión en un dolor para la comunidad de usuarios del sistema y en abono para chistes recurrentes de cierto mal gusto.
La solución: versionado semántico y código obsoleto
El concepto del versionado semántico se incorporó en las últimas versiones de desarrollo de Drupal 8.
Antes de su incorporación, cada nueva versión de Drupal se identificaba con dos números separados por un punto. El primero representaba a la versión mayor y el segundo a su número de parche. Cada nueva versión que aumentaba el número de parche incluía correcciones, tanto funcionales como de seguridad. Siguiendo este modelo, solo era posible incorporar nuevas características al cambiar la versión mayor y si algunas de ellas rompía la compatibilidad hacia atrás, no dejaba tiempo a la comunidad para adaptarse, provocando lo descrito anteriormente.
Con el versionado semántico, cada nueva versión del sistema se identifica no con dos, si no con tres números separados por puntos: la versión mayor, la versión menor y el número de parche. Solo se rompe la compatibilidad hacia atrás al cambiar de versión mayor y se incorporan nuevas características al cambiar de versión menor. Esto obliga a los programadores del núcleo de Drupal a mantener la compatibilidad, durante un tiempo, para hacer que la comunidad tenga tiempo a adaptarse.
Pero, ¿cómo se hace que una comunidad de millones de programadores adapten su código a nuevas versiones? La respuesta es sencilla: poniéndolo muy fácil.
Ciertas nuevas características, al ser publicadas, hacen que otras usadas hasta el momento queden obsoletas.
Antes del versionado semantico, las viejas formas de trabajar desaparecían al mismo tiempo que se publicaban las nuevas formas en una versión mayor. Hoy, las viejas formas de trabajar permanecen y no solo eso, si no que se documenta en el mismo código que están obsoletas y como solucionarlo.
Sirva el siguiente ejemplo: la función `drupal_set_message` permite a los desarrolladores mostrar mensajes informativos o errores a los usuarios de un sitio. Utilizar una función para este cometido está desaconsejado, hace que el código que la utiliza sea difícil de probar. Por eso se sustituyó por un servicio que, correctamente utilizado, permite probar el código mucho mejor. Este es el aspecto de dicha función, hoy:
function drupal_set_message($message = NULL, $type = 'status', $repeat = FALSE) {
@trigger_error('drupal_set_message() is deprecated in Drupal 8.5.0
and will be removed before Drupal 9.0.0. Use \\Drupal\\Core\\
Messenger\\MessengerInterface::addMessage() instead.
See https://www.drupal.org/node/2774931', E_USER_DEPRECATED);
$messenger = \Drupal::messenger();
if (isset($message)) {
$messenger
->addMessage($message, $type, $repeat);
}
return $messenger
->all();
}
La función tiene dos partes bien diferenciadas, un error que describe que está obsoleta y su implementación usando el nuevo método.
De esta forma, al desarrollar una pieza de código que utiliza esta función el programador es consciente de su obsolescencia y de cómo evitarla.
Y no solo eso, se han desarrollado herramientas para conocer dónde se utiliza código obsoleto, para que encontrar donde se usa y cómo dejar de hacerlo sea aún más fácil: el módulo Upgrade Status.
Este módulo Upgrade Status genera un informe detallando los cambios que hay que hacer en nuestro entorno, código y dependencias para que, cuando llegue el momento, podamos actualizar a Drupal 9 sin problemas. Tiene esta pinta:
Este módulo no solo verifica que nuestro entorno cumple los requisitos mínimos de la nueva versión de Drupal comprobando las versiones de PHP, del servidor Web y del servidor de base de datos; si no que también recorre el código en busca de usos de código obsoleto. Para cada uno de los usos que encuentra muestra en detalle en qué linea de que archivo se produce, cuál es el error y cómo solucionarlo:
Conclusiones: breve guía para adaptar tu sitio a Drupal 9 antes de Drupal 9
Aunque queda poco tiempo para que se publique la nueva versión de Drupal, es posible empezar ahora mismo a adaptar cualquier sitio a ella para que actualizar a la nueva versión mayor sea igual que actualizar entre versiones menores.
Para ello seguiremos los siguientes pasos:
- Instalaremos el módulo Upgrade Status.
- Adaptaremos nuestro entorno siguiendo las indicaciones del informe del módulo.
- Para nuestro código, módulos y temas personalizados, modificaremos las líneas que indique el informe tal como indique el informe.
- Para código contribuido, actualizaremos todo comprobando si los módulos y temas que utilizamos aún utilizan código obsoleto.