1. Abstracto

Drupal es un gestor de contenido (un CMS por su acrónimo en inglés) desarrollado en PHP, de código abierto de 10 años de antigüedad que está detrás del 1,5% de todos los sitios web del mundo –casi 800.000-

Su virtud ha sido la de crear un conjunto de librerías de desarrollo en PHP de gran calidad para controlar el día a día de una página web, permitiendo además a terceros ampliar su funcionalidad de forma estructurada, logrando crear una gran comunidad de usuarios y desarrolladores.

Drupal fue desarrollado por y para programadores, siendo esta es una de sus virtudes y a la vez, comparado con alternativas más enfocadas a usuarios finales, sus defectos: mucha de su funcionalidad y potencia viene a costa de implementaciones manuales de procesos.

2. Evolución y partes

Uno de los aspectos característicos de Drupal es el ofrecer unas librerías de desarrollo flexibles y potentes. Esto ha llevado a muchos programadores a escribir sus propias contribuciones -que modifican o amplían su funcionalidad- mediante los llamados “módulos”.

Se distinguen entonces dos partes claramente diferenciadas: el núcleo –la parte principal, autosuficiente que proporciona las librerías básicas- y los módulos, contribuciones de los programadores de la comunidad.

El núcleo es el que define las funciones básicas y la arquitectura y a la que se debe adaptar cualquier proyecto que se realice. Su desarrollo es muy cuidado y cada nuevo cambio profundo en el mismo implica una versión de Drupal (siento la actual la 7)

Entre otras cosas, aporta:

• Seguridad por usuarios y roles
• Sistemas de introducción de datos y de tipos de contenido
• Soporte multi-idioma
• Sistema de “temas”, aspectos visuales que cada diseñador puede cambiar
• Funcionalidades de foro, blog, etc, básicas
• Menús gráficos con los que gestionar todo el sistema
• Y, asociado a todo esto, un potente API que podemos emplear en nuestros desarrollos.

Los módulos proporcionan ampliaciones de todo tipo, ofreciendo desde funcionalidades muy sencillas como extraer un valor de la bolsa a grandes paquetes de funcionalidad, como una tienda virtual entera. A menudo forman cadenas de dependencias, necesitando tener módulos instalados para poder emplear los que dependen de ellos.

A nivel estructural, un módulo es conjunto de ficheros de código en PHP y modificaciones visuales (ficheros HTML, CSS, imágenes, etc.). Existen literalmente miles de ellos: se distribuyen como ficheros ZIP a través de la página de Drupal –que actúa como gran catálogo de los mismos- y se despliegan como directorios dentro de la instalación de Drupal. Cada módulo es gestionado por una o varias personas que se encargan de corregir errores y hacerlos avanzar, normalmente de forma gratuita. La calidad suele ser desigual, con módulos excelentes y muy bien acabados a auténticos desastres. La implicación de los desarrolladores suele variar también bastante, desde personas que siguen la discusión de la comunidad en torno a su desarrollo literalmente hora a hora a otras que ignoran el módulo y lo abandonan.

Es extremadamente atípico en Drupal encontrar módulos de pago siendo en casi todos los casos contribuciones gratuitas de código abierto de los autores.

Alguna funcionalidad que podemos encontrar a modo de ejemplo es:

• Posibilidad de geo-posicionar la información introducida
• Notificar a Google de cada cambio que hagamos
• Crear un foro
• Añadir sistemas de votación para la información disponible
• Integración con Facebook
• Tienda online
• Sistema de blogs
• Taxonomía (clasificar toda la información de acuerdo a nuestro propio criterio y operar con ella)
• Análisis semántico de la información existente
• Gestión de los parámetros típicamente configurados en SEO
• Conexión en tiempo real a servidores de cambio de divisa, meteorológicos, etc.
• Conexión a sistemas corporativos de seguridad en árboles LDAP
• Gestión de imágenes
• Creación de grupos de debate sobre cualquier elemento introducido
• Creación de “vistas” (similares a informes) de la información introducida
• Creación de nuevos tipos de contenido definidos por el usuario

Estos son sólo algunos de los ejemplos de la opciones actualmente disponibles. La funcionalidad de cada módulo interactúa con la de los demás, lo que lo hace extremadamente potente.

Por otro lado puede existir más de un módulo para cada cosa –esto es, diferentes programadores ofreciendo aproximaciones distintas entre las que podemos elegir-.

3. Situación actual

Drupal 6 es la versión actualmente instalada en el mayor número de máquinas. Drupal 7 ha sido lanzado en enero de este año siendo el futuro de este gestor de contenido. Su principal problema viene de los módulos que estaban disponibles, pues necesitan ser adaptados para la 7. Esto está ocurriendo lentamente y muchos aún están en fase beta o directamente no disponibles.

La plataforma sigue en crecimiento, con más usuarios, desarrolladores, libros, conferencias y presencia en la red año a año. Es el sistema empleado en la actualidad por numerosas multinacionales de primer orden y organizaciones gubernamentales, siendo simbólico el empleo de la misma por la Casa Blanca en Estados Unidos.

4. Adopción

Hasta aquí ha sido una descripción general de este gestor de contenido. Vamos a destacar ahora qué aspectos es interesante conocer sobre Drupal.

5. Factores negativos a tener en cuenta

1. Drupal son esencialmente dos partes de calidad extremadamente desigual: el núcleo y los módulos. Aunque habitualmente se presenta Drupal como un CMS en el que podemos elegir entre, literalmente, miles de extensiones gratuitas disponibles –que le proporcionan su increíble versatilidad-, es muy importante recordar que no tienen absolutamente nada que ver en cuanto a calidad, documentación, soporte y comunidad. Los módulos, salvo excepciones concretas, suelen ir muy, muy por detrás en calidad del núcleo.
2. El núcleo de Drupal no está bien documentado. Si bien existe abundante documentación online, ésta adolece de muchas, muchas lagunas y funciones indocumentadas. Se está haciendo un esfuerzo constante y especialmente intenso en los últimos tiempos en este sentido, pero a día de hoy es así.
3. Los módulos esencialmente están totalmente indocumentados. Si bien nos podemos encontrar alguno que sí lo está –o al menos en parte- especialmente entre los más conocidos, lo habitual es que sean simplemente código. La comunidad de desarrollo es también muchísimo más reducida en cada uno (no es posible enfatizar esto lo suficiente) y en muchos casos esencialmente lo conoce la persona que lo ha desarrollado y quien lo está manteniendo.
4. Muchos módulos están desarrollados por una o dos personas. Esto es absolutamente frecuente, incluso con módulos muy empleados y de reconocida utilidad. Por ejemplo, el “Foro avanzado”, el foro de-facto empleado en Drupal, está desarrollado por una madre soltera que trabaja en él cuando puede.
5. La evolución y mantenimiento de los módulos es lento. Excepto en los más empleados, si hay un bug o un problema de seguridad, éste puede tardar bastante tiempo en corregirse. Muchas veces se nos pedirá que lo desarrollemos nosotros para enviar el parche con la corrección. Esto es totalmente lógico, pues estamos trabajando con una comunidad y es coherente que se nos pida formar parte de ella. Pero es algo a tener en cuenta.
6. Hay una curva de aprendizaje, y no es trivial. Mientras que Drupal está en PHP y eso invita a pensar en algo sencillo e inmediato, lo cierto es que es un conjunto de librerías con un API extenso que hay que conocer. La arquitectura general se puede adquirir en un curso sin problemas, pero los primeros meses de desarrollo implican descubrir el API.
7. Extrema lentitud. La escalabilidad y el rendimiento dependen del uso de datos cacheados. Algo común a los lenguajes de script es la necesidad de cachear todo lo existente. Su velocidad suele ser mala de forma general y en Drupal de forma especial.
8. Necesidad de hacerlo todo respetando la arquitectura de Drupal. Cuando estamos desarrollando de forma pura en un framework de Java o en Rails en Ruby, modificar una página suele ser tan rápido como abrirla y editarla. En Drupal debemos seguir un procedimiento concreto, indicando qué vamos a editar, declarando las funciones oportunas (los así llamados ‘hooks’ a los que se refiere la documentación) –que debemos haber consultado previamente- para finalmente escribir una plantilla con el cambio que deseamos.

9. Dependencia del desarrollador de un módulo para ampliarlo y corregirlo. Drupal se comenzó a desarrollar antes de la incorporación de los elementos de orientación a objetos a PHP, imposibilitando emplear patrones típicos en la orientación a objetos. La lógica a modificar no se podía ni sobrescribir ni delegar.

La aproximación de los desarrolladores de Drupal ha sido interesante: definir unos criterios de nomenclatura para las funciones que se desean permitir modificar por otros módulos. Durante el proceso inicial de una invocación al servidor, aprovechando la capacidad de introspección de PHP, se comprueba si el usuario ha escrito funciones con ese nombre y, de ser así, se invoca su código.

El problema viene de la necesidad de prever por parte del programador original qué partes van a poder ser modificables por terceros desarrolladores. En caso de no estar éstas previstas, se puede proponer a este programador la inclusión de esas nuevas funciones.

El problema es dual: por un lado puede no ser aceptado, y por otro puede serlo pero tardar demasiado en llegar a una versión estable que podamos emplear en producción.

En caso de no integrar nuestra necesidad con el programador original, pasamos a ir por nuestra cuenta. Esto implica aplicar las correcciones que se produzcan en el módulo original, tanto en bugs como en problemas de seguridad y perder las evoluciones futuras o tener que integrarlas una a una con nuestro código modificado. Es una tarea mucho, mucho más seria de lo que parece, que consume gran cantidad de tiempo, es propensa a generar errores y debemos repetir periódicamente.

6. Factores positivos a tener en cuenta

Aunque algunos de estos puntos se podrían resumir en aspectos más generales, son lo bastante importantes como para incluirlos de forma independiente.

1. Hay una comunidad gigantesca detrás. Visitar los foros y los grupos de Drupal es entrar en contacto con miles de desarrolladores y usuarios intercambiando ideas, soluciones y aproximaciones a los problemas que aparecen. Como se suele decir, emplear Drupal es no volver a caminar ya nunca más sólo.
2. Podemos contratar consultoría en cualquier momento. Imposible enfatizar esto lo suficiente. Hay un mercado enorme y dinámico de excelentes desarrolladores en torno a Drupal a los que se puede recurrir, ya sea para participar durante todo el proyecto o para participar de forma puntual desarrollando o ampliando un modulo concreto. Es frecuente encontrar una diferencia de calidad enorme entre el trabajo de un programador que forma parte de un proyecto de código abierto y uno que simplemente trabaja de 9-a-5 en una compañía.
3. Está probado en batalla. Desde la Casa Blanca en Estados Unidos a miles de empresas, incluyendo multinacionales de primer nivel, emplean Drupal. Con 800.000 sitios web -y creciendo- es difícil para un producto estar más probado.
4. Gran número de desarrolladores PHP. El propio creador de Drupal reconoce que eligió PHP –a pesar de que él mismo era un programador profesional en Java- por el gran número de desarrolladores que existían en este lenguaje y que podían contribuir. Es un mercado amplio al que se puede acceder con facilidad.
5. Es código abierto. Cuando la necesidad surge podemos ver o tocar los aspectos necesarios. Es una garantía: en un sistema con código propietario, si aparece un problema automáticamente se depende de la empresa proveedora: una vez que les hemos pedido ayuda, pasamos a depender en exclusiva de ellos, en resolución, coste y tiempo. Drupal, a pesar de tener una base de código amplia, ésta es razonablemente comprensible como para acometer por desarrolladores del equipo. Al mismo tiempo podemos solicitar ayuda a terceras partes sin problema.
6. Gran cantidad de módulos. Si queremos desarrollar una nueva funcionalidad siempre podemos ver si un módulo ya la ofrece al completo o, si no lo hace, se puede personalizar o ampliar. Incluso aunque no se emplee en absoluto puede servir como ejemplo totalmente funcional de código en un apartado que queremos tocar.
7. Independencia de la parte visual. Como es frecuente en la actualidad, Drupal establece una distinción clara entre la parte visual y la parte lógica. Esto posibilita la contratación de diseñadores que, ya de antemano, conocen el sistema a emplear y pueden trabajar de forma independiente.

7. Factores neutros a tener en cuenta

Algunas cosas no pueden clasificarse como positivas o negativas, pero tienen definitivamente un peso real al elegir este CMS.

1. Generar un base de código en PHP. Conozco a pocos equipos de desarrollo que trabajen de forma nativa con PHP. Muchos llegan a Drupal porque, a pesar de no ser PHP su lenguaje principal, Drupal aporta una funcionalidad ya probada y es el tipo de herramienta más adecuada para un proyecto concreto. Una consecuencia curiosa es la base de código que se va generando: librerías y módulos en PHP que no son reutilizables en ningún otro proyecto.
2. Estás entregando tu código. Algo que, ofuscando el código, puede no suele ser un problema excepto a nivel político. Si el desarrollo se despliega en un cliente, éste pasará a tener todo el código proporcionado. En desarrollos en Java o .NET esto es más fácil de evitar, pero en PHP, aunque ciertamente se puede ofuscar, es mucho más sencillo acceder a él.
3. Desplegar y/o escalar una aplicación en PHP es un proceso diferente a hacerlo en Java o .NET. Esto va a exigir no sólo tener a las personas adecuadas en desarrollo, sino que en sistemas deberán asumir el despliegue de no sólo una nueva aplicación, sino una nueva arquitectura.

8. Evaluando Drupal

Es sencillo cegarse por la cantidad de funcionalidad disponible en Drupal vía su núcleo y módulos, o por la increíble cantidad de información disponible aportadada por su comunidad. Algunos de estos puntos pueden llevar a desestimar totalmente Drupal o incluso PHP como plataforma.

1. Contenido dinámico de las páginas. Uno de los aspectos más negativos de Drupal es su lentitud. Cuando los datos están cacheados obviamente no importa: basta con generar las páginas una vez. Pero si existen páginas dinámicas es crítico conocer el rendimiento porque, casi con seguridad, va a decepcionar de forma extrema. Se puede usar algo tan sencillo como el Apache Benchmark  (ab) para tener una primera aproximación del rendimiento del sistema. Y no, que en un servidor de última generación, con un solo usuario y una única petición tarde más de dos segundos en generar una sola página no es nada extraño. En muchos casos es lento hasta ese punto o incluso más.

Hay diferentes escenarios: si tenemos un CMS que va a gestionar información estática que no cambia según el perfil y el propio usuario, no es un problema. Si la información depende del usuario (esto puede ser tan sencillo como mostrar los comentarios sin leer que tiene en un foro o tan complejo como mostrar una página tipo Facebook con información específica a cada persona que se conecte) entonces es un factor totalmente crítico a considerar.

Describir cómo optimizar el servidor y hacer una prueba real exigiría un artículo en sí mismo (Carles Climent ha escrito uno muy interesante en el wiki español de Drupal), pero algunas cosas, aunque obvias, es interesante comentarlas:

1. APC debe estar instalado en el servidor. De otra forma estamos obteniendo un resultado con PHP sustancialmente peor que en un entorno de producción.
2. Desactivar cualquier sistema de caché. Interno o externo a Drupal. Lógicamente una de las cosas que más desvirtúa los resultados.
3. La latencia en el acceso a la base de datos es crítica en Drupal. Un signo distintivo de este CMS es la increíble cantidad de peticiones que realiza a la base de datos para procesar cada petición. Este número no hace sino aumentar a medida que se añaden nuevos módulos. La latencia que tengamos en cada petición es extraordinariamente importante empleando Drupal. Normalmente en el entorno de desarrollo tenemos la base de datos en la misma máquina. Si en producción no es así, es crítico probarlo en Drupal.
4. Toda la información está en una sola tabla. Uno de los aspectos característicos de Drupal es el de almacenar todos los tipos de información que introduzcamos (una entrada en un foro, un artículo, los tipos de información definidos por nosotros mismos, etc.) en una sola tabla: nodes. Esto aporta algunas ventajas a nivel de desarrollo pero no es difícil ver el potencial problema. Todos las unidades de información que introduzcamos tendrán una entrada en esta tabla.
5. Velocidad de AJAX. Derivado del punto anterior, impresiona comprobar la lentitud que tiene una simple llamada vía AJAX al servidor. El proceso de bootstrapping (los procesos que siempre se ejecutan cuando hacemos una llamada a una función en Drupal) es pesado y se nota cuando hacemos una simple petición. Que consuma, en una invocación trivial que lea un dato de una tabla de una sola fila, más de 300ms sólo en tiempo de proceso no es extraño. Si bien hay alternativas en forma de módulos, éstas no están bien probadas.
6. Necesidad de un prototipo de desarrollo, no una maqueta. Otro aspecto realmente crítico: que el prototipo que se emplee para evaluar el CMS implique un desarrollo real.  Muchas estimaciones de tiempos en Drupal vienen de evaluar la creación de una maqueta a nivel de usuario. Es rápido, aparentemente muestra la potencia de Drupal y al fin y al cabo es el 80% percibido del producto final. Pero es que el problema con los proyectos que se retrasan no es que estén al 10%, es que están al 90%. Y siguen al 90%  al siguiente año de su hipotética entrega. El riesgo de caer en este espejismo con Drupal es enorme. El coste en tiempo no viene de “Crear un sistema para geo-localizar elementos de información”. Eso es inmediato. Viene de personalizar, aunque sea poco, esa funcionalidad. Lo mismo ocurre con un foro, un sistema de registro, una integración con un sistema de legado existente vía un módulo, etc.

Es crítico desarrollar un aspecto concreto hasta el final porque sólo de esa forma se pueden ver las carencias reales de documentación del núcleo y los módulos afectados, la dificultad de trabajar con la peculiar arquitectura de Drupal, el esfuerzo real necesario en un módulo y los agujeros de formación que existen en el equipo.

7. Un ejemplo

De forma concreta, se puede plantear un escenario sencillo: personalizar cinco elementos de un foro. No vamos a entrar en la parte técnica, tan sólo en qué implica.

Montar un foro en Drupal es rápido. Añadir nuevos campos al  perfil de un usuario también. Pero esa es simplemente la configuración por defecto, lo que ya nos dan hecho. ¿Qué ocurre si un usuario pide las siguientes cosas –nada descabelladas-?

1. Al igual que muchos foros, mostrar el número de posts que el usuario ha hecho al lado de su nombre.
2. Añadir un campo extra a su perfil, “profesión”, que debe aparecer bajo su nombre.
3. Si el usuario que está visitando la página no está registrado, mostrar un cuadro de texto invitándole a hacerlo.
4. El usuario debe poder insertar vídeos de youtube de forma sencilla, como en la mayor parte de las aplicaciones populares actuales.
5. De la misma manera, algo que van a hacer con frecuencia es subir imágenes, debería poder hacerlo de forma sencilla (un clic y elegir una imagen)

Esencialmente hay dos problemas distintos: desconocimiento del API y coste de integración en Drupal.

Los puntos 1-3 son desconocimiento del API del núcleo. El coste en tiempo es encontrar qué funciones emplear y qué partes tocar para implementarlas. Hacerlo no es siempre tan evidente como parece y hay que recordar que no siempre disponemos de una documentación completa. Estos son sólo tres casos simples, pero en un desarrollo durante los primeros meses hay un bombardeo continuo. Por otro lado, suele ser normal no implementarlas de una forma afín a la arquitectura de Drupal, por lo que lo que estamos haciendo no es sólo perder el tiempo, sino poner bombas en el proyecto que estallarán en el futuro. La figura del mentor durante esta fase –alguien que conoce Drupal en profundidad- es extremadamente útil.

Los puntos 4-5 implican coste de integración. No sólo exigen conocer el API, es necesario conocer en profundidad la arquitectura de Drupal, en este caso en la parte de introducción de datos. Tan cercanos al usuario como pueden parecer (subir imágenes y vídeos) no son en absoluto inmediatos en tiempo de desarrollo. Obviamente podemos ofrecer al usuario la funcionalidad que ya existe en alguno de los módulos existentes, pero de ser necesario establecerla nosotros, el coste es muy alto si no conocemos en profundidad este CMS.

Por poner un ejemplo real: introducir imágenes de forma sencilla mediante es hoy en día un módulo existente con una persona detrás que ha tenido que dedicar una cantidad seria de tiempo y esfuerzo -y aún así existen flecos abiertos.

8. Información adicional

Podcasts