Los que somos forofos de Drupal llevábamos años esperando ansiosamente a que llegara la tan anunciada versión 8. Esto sucedió el 2 de octubre del año pasado, con el lanzamiento de la beta 16.
Desde entonces se han sucedido 20 versiones diferentes, hasta llegar a la 8.1.3, que data del pasado 15 de junio. Con ese ritmo, seguro que cuando pasen un par de semanas de publicar este post habrán aparecido un par de versiones nuevas.
Como la mayoría de los adeptos a este CMS, lo primero que hice fue realizar una instalación en local, para ver cómo funcionaba la cosa y palpar, por mi mismo, cuáles eras las novedades.
La primera en la frente vino por la versión de PHP que se necesita (la 5.5.9 o superior), y sus requerimientos. Puedo entender que sea necesario una gran cantidad de modificaciones en el php.ini para que el software funcione a pleno rendimiento (por ejemplo, es un gran punto a su favor el contar con un gestor de cachés gestionado por PHP que aumenta la carga de las páginas de manera realmente sorprendente). Pero eso de activar y desactivar módulos complica muchísimo la cosa. Especialmente si queremos realizar la instalación en un hosting remoto, donde la seguridad prima por encima de cualquier otra consideración.
He de decir que la primera instalación me sorprendió mucho. No tanto por lo que aparecía en la pantalla, sino más bien por el tiempo que tardó en realizarse. En una máquina limpia, bajo Linux Mint, y con las últimas versiones de Apache, MySQL y PHP instaladas y optimizadas, tardó cuatro minutos 😯 Y eso que hice la instalación en inglés, para que el sistema no se tuviera que conectar al servidor de traducciones e instalarme el español.
Me dejó sorprendido el número de ficheros con los que trabaja: algo más de 12.400, así como la cantidad de tablas (66, aunque para la versión en español son 71) que genera.
Todo esto me hizo sospechar que en un entorno más hostil, con llamadas en remoto, como es el de un hosting no local, la situación podría volverse en desesperante.
Efectivamente, así fue. Elegí un hosting gratuito, que es lo mismo que le pido a mis alumnos. Para empezar, la mayoría de los servicios de alojamiento suelen trabajar con versiones de PHP inferiores a las que solicita este Drupal, con lo que las opciones se reducían mucho. Una vez localizado el hosting idóneo, el siguiente problema estuvo relacionado con los tiempos de espera. Como es bien sabido, el tiempo de espera de respuesta de la base de datos suele rondar el minuto, dependiendo del hosting, claro. Una instalación que requiere de más de doce mil ficheros, y que trabaja con tantas tablas en la base de datos, suele requerir de mucho más tiempo.
Aunque finalmente logré realizar la instalación, tras modificar varios ficheros y tener que hablar con el servicio técnico del hosting para pedirles diversos favores (algo de lo que suelen pasar, la verdad), el resultado no me gustó nada. No era posible activar varios módulos de PHP que son fundamentales para que el software se ejecute de manera fluida. Además, la conexión con la base de datos en el trabajo diario convertía a cualquier operación en algo insufrible. Consulté varios foros y descubrí que estos problemas eran comunes en todas las instalaciones.
Luego, por curiosidad, miré las estadísticas semanales de uso de Drupal, donde constaté que, a pesar de ser una versión creada de cero y con muchas expectativas, la realidad es tozuda, y está siendo menos usada, incluso, que la 6.0. Sobre los datos ahí aparecidos he creado un gráfico que muestra perfectamente la evolución de las versiones 7 y 8 durante los últimos meses.
No dudo ni por un momento de la fiabilidad y seguridad de esta nueva versión. Pero si el proceso de instalación tiene tantos inconvenientes, no quiero ni pensar qué sucederá cada vez que haya que instalar un módulo. O, peor, cuando haya que actualizar el CMS. Ya que, tampoco en esta versión se ha contemplado la instalación en un click, y sigue siendo necesario volver a subir los doce mil y pico ficheros de la nueva versión que sustituya a la antigua. Es decir, que este calvario se repetiría cada tres semanas.
Si Drupal ya es un CMS de difícil comprensión para los no iniciados en el mundo de los gestores de contenido, no creo que tenga mucho sentido ir poniendo trabas en cosas que, en principio, deberían ser mucho más simples. O, al menos, lo son en otros programas con características similares.
Deja una respuesta