Dolores de cabeza actualizando Drupal 8 Beta

Drupal 8 promete traer un montón de nuevas características y herramientas para ayudarnos a construir y darle mantenimiento a nuestros sitios web (para más información, les recomiendo ver mi otro post sobre Symfony y Drupal, con un Release Candidate ya a la vuelta de la esquina (a la fecha de redacción de este blog).

Aquí en Rootstack ya hemos estado trabajando con la nueva plataforma para desarrollar varios proyectos, y entre los nuevos cambios, hemos podido apreciar sobretodo la inclusión de varios módulos contribuidos en el core de Drupal 8 y el sistema de exportación de datos a archivos. Sin embargo, las versiones alpha y beta de todo proyecto siempre conlleva limitantes, y Drupal 8 no es de menos, al convertir la actualización de un proyecto desde su primera versión beta a la última versión disponible en un auténtico dolor de cabeza.

Al momento de arrancar con el desarrollo de un proyecto en Drupal 8, es importante tomar en cuenta la necesidad de extensión del sitio y el uso de sitios contribuidos existentes (incluir varios módulos para la construcción del sitio, en lugar de implementar la nueva API de desarrollo de Drupal para incluir características en el sitio). El problema principal radica en los cambios aún presentes en las versiones beta al API del Core de Drupal, en un proceso de implementar nuevas funcionalidades y pasar las existentes a los nuevos componentes de Symfony. Varios módulos contribuidos se han visto en la necesidad de ser parcheados frecuentemente para prevenir fallos y errores en algunas o todas sus funcionalidades, al igual que los módulos personalizados desarrollados para nuestros proyectos.

Sin embargo, realizar actualizaciones frecuentes al Core de Drupal y de sus módulos no ha resultado ser una opción, debido a que varios de estos cambios han afectado - y se han visto afectados - al sistema principal de Drupal 8 para exportación de código: el Administrador de Configuraciones.

El Administrador de Configuraciones, el nuevo sistema de exportación de datos a código de Drupal 8, es una de las nuevas características más esperadas para los desarrolladores, reemplazando el sistema de Features que, bien siendo una buena proposición para aquellos que han desarrollado en Drupal anteriormente, saben que tiene sus limitaciones (como problemas de conflictos a menos de que se mantenga estrictamente la estructura de las características, o un UI pesante y a menudo poco amigable). Sin embargo, el uso de este sistema para cambios de sitio ha demostrado ser aún un tanto inestable y posiblemente inútil al tratar de realizar actualizaciones de versiones.

La estructura de exportación (y los .yaml generados) ha ido variando con casi todas las versiones beta, por lo cual intentos de importar configuraciones realizadas en versiones más viejas ha resultado en importaciones fallidas o, peor, incompletas, resultado en un malfuncionamiento del sitio.

El sistema de importación singular para características específicas ha facilitado la importación de las estructuras más complejas (como las vistas), pero aún así se han presentado problemas con algunas de ellas, como lo son los Tipos de Contenido y los Bloques personalizados, entre otros.

Finalmente, cabe mencionar que, dado los varios cambios realizados a los módulos contribuidos y a los rápidos ciclos de actualización a los que se encuentran expuestos, estos han resultado ser nuestro enemigo #1. En mi primer proyecto de Drupal 8, basado en su gran mayoría por código personalizado, nos hemos visto menos afectados por los cambios de versiones, con la excepción de toques de mantenimiento para los cambios de API a las funciones y sistemas heredados. Por otro lado, en otro sitio más reciente, intentar actualizar de una o dos versiones no sólo causó problemas con la importación de las configuraciones anteriores, si no que trajo todo tipo de problemas con otros módulos como Views y Panels, los cuales se vieron afectados por una serie de nuevos bugs que afectaron a varios requerimientos del proyecto.

Para concluir, tengan en mente estos 3 puntos para su próximo proyecto con el beta de Drupal 8:

1. Asegúrese de que no sea un sitio que requiera de mucho mantenimiento/extensibilidad a futuro (a menos hasta que salga la versión oficial de Drupal 8).
2. Trate de depender lo menos posible de los módulos contribuidos disponibles de Drupal, aprovechando lo más posible el nuevo API de desarrollo.
3. No trate de actualizar aún sus módulos, ni su instalación de Drupal 8.

Una vez que Drupal 8 salga del beta y empiezen a aparecer más módulos estables y estabilidad en el API del Core, podremos finalmente superar este último obstáculo para los nuevos estándares de desarrollo que esta versión trae.