Un año con Drupal

Temas

Hará un año (Mayo'17) que tomé contacto definitivo con Drupal. Lo conocía de oidas, y años antes lo había instalado para trastearlo, pero no llegué a usarlo ni entenderlo. "Qué raro y que feo es este CMS" decía en aquel entonces. Drupal no tiene tanta cuota, ni tiene tantos fans como WordPress, pero una vez que lo usas, lo entiendes y convives con él, ya no lo cambias por nada. Lo dice alguien que la primera impresión que tuvo fué "¿pero qué mierda es esta?!" y ahora no lo cambia ni por un Joomla ni un Wordpress, aunque como todo, tiene sus pros y sus contras.

Antes de meterme de lleno con Drupal, venia de la programación a medida sin frameworks, PHP a pelo. Fué cuando me di cuenta de la evolución de PHP  (o muerte para convertirse en otra cosa), y pagué de lleno el precio del reciclaje en esta profesión. Llevé muchos años como programador PHP, y lo contaré desde ese enfoqué.

En general

Venia de la programación a medida, y la primera sorpresa fué que aquí no se tocan las tablas de la base de datos directamente (es más, casi se me olvida el precioso lenguaje SQL). Lo que hacía de crear una tabla y luego sus campos (integer, varchar, longtext, blob...) en Drupal son "tipos de contenido", y es algo así como una herramienta visual para crear tablas de forma rápida pero con campos más potentes. Imagina un formulario en el backend que permita al usuario subir una imagen a la web y todo lo que eso conlleva: tablas, nombre de archivo, carpeta, código PHP necesario, html para mostrar la imagen. Pues todo esto lo proporciona Drupal en 3 o 4 clicks.

Y si, casi olvido SQL porque en Drupal las consultas se hacen mediante "Vistas". De nuevo click click click. A mi que me gusta y había afinado el uso de left joins, inner joins, con los últimos proyectos, pues es considerado una mala práctica, aunque poder usarse se puede usar. Drupal lleva una capa de abstracción para el tema de base de datos, que choca de mucho a bastante con el típico lenguaje SQL. Cuestión de acostumbrarse.... o no. Alguna vez he tenido de "cincelar" una consulta SQL porque hacerlo mediante vistas o con el pseudo lenguaje de consultas que utiliza Drupal era excesivamente complicado. Está limitado para consultas complejas.

Hay que diferenciar en Drupal lo que es configuración de contenido. Tipos de contenido (lo que venia a ser tablas), y otros muchos datos manipulables desde el backend, se considera configuración. La configuración en Drupal es exportable, el contenido no. Es una ventaja fuerte contra otros CMS, sobre todo cuando hay varios developers trabajando sobre el mismo proyecto y tienen distintas configuraciones. En Drupal 7 se utiliza un módulo para esto llamado "features", y en Drupal 8 se puede hacer desde la propia interfaz web, o por consola con una herramienta llamada Drush. ¿Y qué configuración se puede importar / exportar? Pues la estructura y campos de un tipo de contenido, la configuración de un módulo, permisos, roles, posición de bloques y más cosas.

Como en otros CMS, también existen los hooks, pero más estricto a la hora de escribir sus nombres, ya que tienen una nomenclatura un poco enreversada, con prefijos y sufijos, algo así como nombre_modulo_haz_esto_alter, y la documentación sobre esto tiene cierto truco. Si escribes los hooks tal y como figuran en la documentación no funcionan, debes sustituir HOOK por nombre de la plantilla o módulo (lo descubres al cabo de unos días de cientos de pruebas y errores). Así es, si ves en la docu oficial algo así como : function template_preprocess_node(&$variables) {}, si haces un copia-pega literal y metes tu código entre las llaves..... no funcionará. Hay hooks que proporciona el core de drupal, y otros que proporcionan los propios módulos o que se pueden crear custom.

Drupal 7

Puede resultar más liviano, con menos fricción y cuesta menos esfuerzo hacerse con él. Al contrario que Drupal 8, aquí vi mucho PHP del que había venido escribiendo siempre, y uso de objetos, aunque no tan intenso como en Drupal 8. El sistema de plantillas también es PHP, por lo que no me resultó complicado modificarlas, pero con el tiempo vi que era un arma de doble filo que puede hacer caer fácilmente en las malas prácticas. El modelo vista - controlador, es algo confuso en Drupal, y por las prisas o por no querer dedicar un poco tiempo a conocer como funciona Drupal, todo lo que debería hacerse en el modelo y en el controlador acaba en la plantilla, afectando al rendimiento, obteniendo finalmente una mierda, un desastre. Drupal 7 permite a los malos programadores hacer aplicaciones de mierda sin demasiado esfuerzo. He visto cosas horribles escritas directamente en las plantillas, que además de ser código feo, tenian un impacto negativo fortísimo en el rendimiento de la web.

Drupal 7 tiene muchos módulos para casi todo, está bastante más y mejor documentado que Drupal 8, los módulos más maduros, al menos lo que he visto en este año y he tenido oportunidad de trabajar.

Drupal 8

Una de las diferencias significativas: la presencia de Symfony, y el lenguaje de plantillas twig. Después de haber visto como funcionaba Drupal 7 y sus plantillas, durante un tiempo pensé que Drupal 8 se lo habían cargado con Twig/Simfony y que complicaba muchisimo las cosas. Cosas como por ejemplo, trabajar con arrays en Drupal 7 (PHP) puede ser sencillo, en Drupal 8 con Twig puede ser una auténtica pesadilla. No es tarea sencilla. En Drupal 8 se hace un uso muy intensivo de POO, que unido al uso de componentes Symfony, más la capa de abstracción del core de Drupal para otras cosas, se tiene como resultado un lenguaje nuevo muy estricto que lo único que tiene en común con PHP es como se declaran las clases, las condiciones y bucles. Todo lo demás, no parece PHP. La parte positiva: es realmente complicado incurrir en malas prácticas. La parte negativa: la curva de aprendizaje de Drupal es BRUTAL. Es prácticamente empezar de 0 en un nuevo lenguaje, por muy senior que sea uno en PHP. Posiblemente alguien del core de Drupal dijo: "vamos a meter twig en D8, a ver si tienen pelotas de escribir las mismas mierdas que en D7". Y en D8 también es posible escribir mierdas, pero deben ser mierdas muy muy sofisticadas para que funcione. Pero una vez te haces con él, ahorras mucho tiempo de desarrollo.

Lo mejor
Para site building es excelente, potentísimo, brutal. Después de haber trabajado con Wordpress y Joomla, Drupal es bestialmente superior.
Desarrollar una web que no requiera mucha o nada de programación, es bastante más rápido desarrollarlo con Drupal.
Bien optimizada y configurada es muy muy rápida.
Incluye sistema de traducciones bastante molón, que es muy sencillo de activar y mantener.
Sistema de roles y permisos muy completo.
Los modos de visualización y como exporta / importa configuraciones.

Lo peor
La curva de aprendizaje es brutal. Es un framework que se escribe en algo "parecido" a PHP, pero no es PHP del todo, lo que te lleva a aprender casi de cero.
No está tan bien documentado como debería, y hay módulos que están a medio hacer.
Fué un choque bastante grande entender en funcionamiento de las vistas, no poder escribir SQL manualmente.
Sistema de plantillas twig muy restrictivo.
En mi opinión, como usa Drupal las tablas de la base de datos es horrible, un caos, y eso se nota muchas veces en el rendimiento general de la web.
No es tan flexible como el desarrollo a medida. Para cosas muy custom hay que hacer prácticamente dos trabajos: 1) modificar el comportamiento natural de drupal, para luego 2) hacer que cumpla los objetivos funcionales del proyecto.

Conclusión final
Wordpress, Joomla, etc es para webmasters. Drupal es para desarrolladores, pero tiene un alto precio de entrada: su curva de aprendizaje.

 

Añadir nuevo comentario