¿Por qué un programador fullstack experimentado acaba escogiendo Drupal para desarrollar un proyecto de dificultad indeterminada? Por “recomendación” de un cliente, obviamente.

 

El caso de uso que he vivido ha sido el de un desarrollador RubyOnRails con buenos conocimientos en HTML5 y Javascript, Versus un proyecto de complejidad media y creciendo, que debía ser desarrollado en Drupal. Ante mi tenía dos problemas principales:

 

a) A nivel del gestor de contenidos, comprender la ingente cantidad de opciones que se ofrecen desde la administración. Donde buscar, modificar y configurar cada aspecto de la web, los cuales crecen a medida que se añaden módulos.

b) Entender como funciona la magia de Drupal a nivel avanzado. Crear un nueve theme, crear módulos propios, como funcionan los hooks, el naming de los métodos y los ficheros, etc.

 

Una vez superado este risco, gracias a la potente comunidad que respalda la plataforma, tuve momentos de disfrute con Drupal. Un requerimiento fue geolocalizar en un mapa que no fuera el conocido de Google, teniendo como parámetros el radio de busqueda y la ciudad, el código postal, la dirección o la geolocalización del usuario por HTML5. OpenLayers Proximity Locator module al rescate. En dos horas estaba funcionando. Resultó muy fácil añadir funcionalidades complejas como ésta cuando se encuentra el módulo que encaja.

 

Otro momento de logro personal fue añadir un módulo de envio de sms de forma periódica. Un poco de magia Drupal, algunos módulos complementarios y mi código php era ejecutado cuando cron así lo determinaba. El punto de dolor en este caso fue el acceso a la base de datos. Nunca he visto sistema de persistencia menos legible que los generados por Drupal. Por poner un ejemplo, las entidades de mi administración no se corresponden con tablas sino que cada uno de sus campos conforman una tabla en si misma, de forma que una query sencilla pasa a tener numerosos joins, nombres de tablas y campos muy extensos y una legibilidad nula.

 

Pese a todo, mi pesadilla no había llegado a su momento álgido. Drupal me reservaba una sorpresa de última hora. Cuando el proyecto ya había alcanzado una complejidad media alta, llegaron las incompatibilidades entre módulos. Para que nos hagamos una idea, hablamos de 90 módulos, incluidos los que vienen inicialmente con Drupal. Al observar comportamientos erráticos en la aplicación empece a tirar del hilo. Buscando en foros, encontré que muchos de los problemas eran ocasionados al tener instalados dos módulos incompatibles y para ello la solución son parches. No quisiera ahondar más en ello pero puede deducirse los problemas que esto conlleva si quieres mantener un poco al día tu aplicación.

 

Pros

- Por complejo que sea un requerimiento, primero busca un módulo que se adapte, porque probablemente exista. Lo podrás utilizar directamente o realizar tus pequeñas modificaciones.

- Gran comunidad activa respaldando la plataforma. Tanto a nivel de foros donde resolver tus problemas como módulos realizados por colaboradores.

- Velocidad para crear funcionalidad concreta.

 

Contras

- Dificultad para encontrar el lugar donde realizar las modificaciones en el gestor de contenidos.

- Dificultad para encontrar el lugar donde realizar las modificaciones en el código fuente. Insertar en el header las meta tags de Facebook fue una locura.

- Problemas de compatibilidad entre módulos.

 

Consejos.

- Configura cron para hacer un backup de base de datos cada muy poco tiempo.

- Usa git. O un sistema de control de versiones. La mayor parte de tus modificaciones se guardan en base de datos, pero todo proyecto agradece de un control de versiones y yo lo agradecí en más de una ocasión.

- No dejes que tu cliente introduzca contenidos en el gestor hasta que el proyecto este en producción. Es muy difícil de gestionar los cambios, las restauraciones de base de datos, desactivaciones de módulos, etc, y además Drupal es propenso a fallos con la activación y desactivación de módulos. Mucho más si estás trabajando en local y ellos en el servidor de pruebas, obviamente.

 

En resumen, sabiendo los pros y los contras, y ahora que conozco Drupal, lo escogería solo para proyectos de complejidad baja y conocida. El proyecto que realicé se podría haber hecho,  por ejemplo, en RubyOnRails y Backbone, en el mismo tiempo, pero con una escalabilidad y sobre todo, una estabilidad mucho mayor.

 

Esa es mi experiencia.

kanedaki@gmail.com