Un pequeño (y espero útil) apunte antes de que penséis que he abandonado completamente el blog :-(

Se trata de un consejo para mejorar el rendimiento de nuestro sitio Drupal. El sistema utiliza por defecto la biblioteca GD para manipular imágenes (por ejemplo, generar miniaturas). El módulo ImageAPI inserta una capa de abstracción en Drupal que permite elegir qué biblioteca gráfica usar, GD o ImageMagick. Es mejor utilizar ImageMagick, ya que es una biblioteca independiente de PHP y, por ello obtendremos mejor rendimiento total en Drupal, y además es más estable (si falla GD puede caer todo el motor de PHP, sin embargo, si falla ImageMagick no caerá, ya que es un binario diferente).

Pero aún mejor: existe un proyecto llamado GraphicsMagick, que es un fork de ImageMagick y que es más estable y, sobre todo, con mejor rendimiento, ya que consume menos memoria y es más rápida. Y lo que es mejor, tiene la misma API que ImageMagick (el comando convert), con lo cual podemos engañar a ImageAPI diciéndole que use ImageMagick cuando en realidad tenemos instalado GraphicsMagick.

Para lograr esto no tienes más que instalar GraphicsMagick y el módulo ImageAPI de Drupal, en dos sencillos pasos. Supongamos que trabajamos con un servidor Debian/Ubuntu (en otros sistemas operativos no debería ser muy diferente):

1. Instalamos GraphicsMagick: apt-get install graphicsmagick-imagemagick-compat

   Podemos probar que GraphicsMagick funciona escribiendo convert en la consola:

   isra@salon:~$ convert
   GraphicsMagick 1.3.5 2009-01-26 Q8 http://www.GraphicsMagick.org/
   Copyright (C) 2002-2009 GraphicsMagick Group.
   Additional copyrights and licenses apply to this software.
   See http://www.GraphicsMagick.org/www/Copyright.html for details.
   
   Usage: convert [options ...] file [ [options ...] file ...] [options ...] file
   
   [más opciones]
2. Instalamos el módulo ImageAPI y lo activamos en /admin/build/modules (módulos ImageAPI e ImageAPI ImageMagick).
3. Accedemos a la configuración de ImageAPI en Administración > Configuración del sitio > ImageAPI (/admin/settings/imageapi) y veremos el siguiente mensaje: "The ImageAPI ImageMagick module is the only enabled image toolkit. Drupal will use it for resizing, cropping and other image manipulations".
4. Si también hemos activado el módulo ImageAPI GD2, nos dará a elegir (seleccionamos ImageAPI ImageMagick como opción por defecto):

   

¡Y listo! Fácil y rápido. Podemos comprobar que funciona accediendo a Administración > Configuración del sitio > ImageAPI > Configurar (/admin/settings/imageapi/config), lo que nos mostrará información sobre GraphicsMagick (versión, tipos soportados, etc):

¿He hecho benchmarks para comprobar la ganancia de rendimiento con respecto a ImageMagick?

Pues no, lo siento. Pero los chicos de GraphicsMagick sí los han hecho, y son bastante jugosos ;-)

Pero... ¿no es necesaria la extension imagick de PHP?

No, no es necesaria, ya que ImageAPI interactúa con ImageMagick/GraphicsMagick a través del binario convert.

Iré escribiendo algunos artículos más sobre técnicas fáciles para optimizar el rendimiento de Drupal.

El ritmo de publicación del blog está algo bajo últimamente, y seguirá así en las próximas semanas ya que estoy bastante ocupado con diversos proyectos, alguno de los cuales contaremos en detalle ;-)

No obstante, me gustaría comentar el informe de CMS Wire sobre los gestores de contenido más en boga en este año 2009, que el creador de Drupal ha comentado con gran acierto. Las encuestas arrojan unos resultados esperables pero muy interesantes.

En primer lugar, la ya tradicional hegemonía de PHP como tecnología más popular para gestión de contenidos. Me sorprende que, en la era de los frameworks no tengan tanta fuerza otras tecnologías como Python con Zope o Django (a excepción de Plone), aunque quitarle el puesto al "trío de ases" es tarea difícil, por el recorrido y la comunidad que tienen.

En segundo lugar, es muy importante notar que el estudio no es un ránking de los mejores CMS, sino de aquellos más populares, con los que más familiarizados están los encuestados. Que Wordpress y Joomla sean los más populares no significa que sean los mejores. Tienen grandes bazas como el apoyo de la comunidad, mucha documentación, gran cantidad de plug-in y muy buena aceptación en entornos empresariales.

Pero no nos equivoquemos. Wordpress juega en una liga distinta a Plone y Drupal. Wordpress es un gestor de blogs, fácilmente personalizable y puede ser utilizado y administrado por gente con muy pocos conocimientos. Sin embargo, no debe ser empleado como gestor de portales o grandes sitios. Tampoco como sistema ECM ni Intranet. Además, las "tripas" de Wordpress tienen mucho código spaghetti. No obstante, mi experiencia personal (lo estoy utilizando para dos proyectos, una revista on-line y una web corporativa) es muy positiva, ya que en muy poco tiempo pude montar un pequeño sitio web y estoy bastante satisfecho, especialmente con la API para crear themes.

Un último apunte sobre Wordpress: la métrica de popularidad de Wordpress está ligeramente inflada ya que muchos de los encuestados confundieron el gestor de contenidos Wordpress con el servicio de alojamiento gratuito WordPress.com.

Por su parte, Joomla es un portal bastante ampliable (hay plug-ins para hacer CRM y cosas así), además es fácil de usar para editores y administradores. Pero en mi opinión, no puede crecer a sitios realmente grandes.

En otro nivel están Drupal y Plone. Ambos presentan no sólo una solución de gestión de contenidos, sino un framework para desarrollar sistemas de este tipo (Drupal Framework y CMF, que originalmente no forma parte del proyecto Plone), con lo cual la capacidad para ampliar estos CMS es mucho más grande, sobre todo en Plone por estar construido sobre Zope.

En tercer lugar, la gente está entendiendo que el concepto de CMS es demasiado genérico. No se puede comparar Alfresco, que es un ECM, con un gestor de tareas colaborativo o una red social. Todos ellos son gestores de contenido pero es necesario no confundir peras con manzanas. A las PYMES les suelen interesar los gestores de publicación de contenidos, tales como portales, prensa, blogs... soluciones sencillas que permitan crear rápidamente sitios con un diseño propio y contenidos adecuados. Y a organizaciones más grandes, sistemas que puedan crecer hacia la gestión documental (ECM), intranets/portales del empleado o aplicaciones empresariales más grandes.

Otras conclusiones interesantes:

• En la valoración general, Joomla! desciende por debajo Alfresco y Silverstripe. También sale mal parado Plone, en noveno puesto con sólo un 30% de votos positivos. El otro 70% son los que no fueron suficientemente hombres para plantarle cara a Zope ;-)
• Drupal es el que más ha crecido en cuanto a profesionales del desarrollo, y Wordpress en cuanto a márketing/redaccción. Además, hay casi el triple de libros sobre Drupal (25) que sobre Wordpress (9). Sobre Plone, hay 7 libros publicados.
• En general, en Internet se habla mucho más de Joomla que de Drupal. Este dato se invierte en los medios sociales, sobre todo en Twitter.
• Este año, en los blogs (Technorati) se habló de Plone un 55% menos que el año pasado. No obstante, Plone es el cuarto CMS en cuanto a repercusión en la web social.
• Drupal tiene tantos premios como Wordpress y Joomla juntos.

Una última cosa... me alegro de que hayan eliminado del top 20 a PHP-Nuke, que lleva bastante tiempo sin publicar una nueva versión. Antaño fue un sistema omnipresente —diría incluso que marcó una generación— pero malísimo en cuanto a seguridad, diseño, calidad del código, etc. Hoy en día la gestión de contenidos es diferente... gracias a Dios.

Sólo una pequeña nota para informar de lo que he leído en Sitepoint sobre la nueva versión de Drupal. Si hasta ahora era de los mejores CMS (sus premios le avalan), compitiendo directamente con el "monstruo" Plone, con este movimiento, y si todo sale bien creo que se convertirá en el súper-CMS del presente y el futuro (perdona que me ponga en plan gurú-profeta amarillista).

La idea es darle a Drupal la forma necesaria para convertirse en un nodo de la web semántica, perfectamente interconectado por Web Services, REST o HTTP sin más, que sea capaz de tomar y servir información de otros nodos, permitiendo a los usuarios localizar información dentro y fuera del sitio web. Lo que no sé todavía es si el almacenamiento se mantendrá como hasta ahora, en una base de datos relacional, o por el contrario pasarán a usar una base de datos semántica. Si se diera el primer caso (y así parece, según los avances de Carlos Rincón), deberían utilizar una especie de ORM para mapear las descripciones en la BD, y seguramente esa capa fuese reutilizable más allá de Drupal (como pasó con su motor de plantillas).

Drupal pasa dejando huella, haciendo avanzar el ecosistema de programación PHP y la web en general. Gracias y felicidades, Drupal.

PD: la imagen está alojada por Facebook Inc., hosting gratuito de imágenes. Gracias a su falta de privacidad me voy a ahorrar unos eurillos...