Una comparación entre WordPress y Drupal

Recientemente tuve la oportunidad de participar en el desarrollo de dos sitios con WordPress. Una de las razones que tuve para este ensayo fue tener una experiencia de primera mano sobre WordPress. Considerando que trabajo con Drupal desde hace aproximadamente 10 años, no puedo evitar la comparación entre ambos.

Mi primera impresión es que WordPress es un programa ligero, que fue creado como un sistema de blogs, y este objetivo original se nota a pesar de los grandes esfuerzos para convertirlo en un CMS con todos sus derechos.

WordPress es rápido, sencillo, tiene pocas opciones de configuración y las que le faltan se cubren a través de código personalizado que puede ponerse indistintamente en el tema o en un plugin (un equivalente a módulo de Drupal). Está preparado para manejar sistemas pequeños. Se extraña un sistema de caché en el core, aunque al momento de desarrollo esto puede verse más como una ventaja que como un problema. Su sistema de templates basado en php no tiene toda la potencia del correspondiente en Drupal.

Para evitar malinterpretaciones es importante que haga una aclaración de los criterios que podemos usar para evaluar el "tamaño" de un sitio, y por lo tanto saber si es pequeño o no. Podemos tomar en cuenta:

• La cantidad de visitas concurrentes
• La cantidad de contenido
• La complejidad de la estructura. Por ejemplo el número de tipos de contenido, de campos, de taxonomías, secciones, bloques de infopormación, etc.
• La cantidad de usuarios logueados simultaneamente

Puedo afirmar, sin haberlo probado, que WordPress puede escalar en cantidad de visitas concurrentes (ayudado por algún plugin de caché), y hasta de usuarios logueados simultaneamente, pero tendría problemas para manejar una cantidad grande de contenido y para el manejo de estructuras complejas.

Si quisiera comparar WordPress 4.x con Drupal 8.x, que son las dos últimas versiones mayores de ambos. Para esta comparación pueden tomarse varios criterios. Comencemos por ejemplo con la parte administrativa. Drupal viene desde el core con los módulos suficientes para crear tipos de contenido, campos, listados, configurar permisos, etc. En el caso de WordPress viene con lo suficiente para funcionar, es decir, un número específico de tipos de contenido, roles y permisos bien definidos. Si en Wordpress se desea personalizar estos aspectos, por ejemplo, crear un tipo de contenido nuevo, o un permiso, se tiene que hacer uso de un snippet de código que se pone o bien en un tema o en un plugin. O caso contrario hacer uso de un plugin que ya implemente esta posibilidad.

Al parecer "la cultura" WP se orienta bastante por usar snippets, lo cual de alguna manera tiene sentido si lo que se desea es un pequeño cambio. De acuerdo a lo que pude captar de esta cultura, esto se interpreta como que las cosas son sencillas, y también podemos decir de nuestro lado que puede ser una ventaja para el rendimiento. Pero esto podría ser un problema si es que este sistema tiende a crecer en estructura, ya que para poder mantener un orden sería necesario planificar correctamente donde se realizará cada uno de los cambios. Y acá puede existir una de las razones por las que Drupal puede escalar más en este aspecto, y es que ya existe una forma más estandarizada de hacer estas "configuraciones básicas".

Esta idea de sencillez también se aprecia en la cantidad de tablas que se crean en una instalación estándar de WP (12 tablas) vs. una instalación estándar de Drupal (65 tablas). Cuando se extiende la estructura de WP, es usual que se sigan usando las mismas tablas, mientras que Drupal tiende a aumentar las tablas al crearse diferentes configuraciones, por ejemplo nuevos campos. Al guardar todos los campos de todos los tipos de contenido en una sola tabla, es mucho más fácil disponer en WP de campos que solo se apliquen a un contenido por ejemplo, característica que incluso viene incorporada en el core. Por otro lado esta capacidad de sencillez de WP tiene un efecto si es que el sitio crece en estructura y en cantidad de contenido, ya que todo se almacenará en una misma tabla, y está tenderá a crecer desproporcionadamente. También obliga a WP a tener un sistema propio de consultas (internamente crea las consultas SQL).

Uno de los temas que precisamente decíamos que tiene Drupal es una forma de crear listados, usando solo el administrador, con el módulo Views del core ¿cuál es equivalente de WP?. Lo usual es usar la API de consultas de WP, ya sea en el tema o en un Plugin y hacer el marcado directamente a mano. Acá también se observa claramente esa misma orientación filosófica de ambos. Mientras Drupal intenta tener las opciones para que desde el administrador se hagan los cambios sin tocar código, WP prioriza tener una forma "sencilla" y "flexible" (al estar en código es bastante flexible) de hacer las cosas.

Como conclusión de esta experiencia pienso que si se necesita un sitio web sencillo, con pocos tipos de contenido, un workflow sencillo (idealmente un rol que publica y otro anónimo que ve el contenido), y que por otro lado no crezca excesivamente en cantidad de información a publicarse WP puede ser una buena opción. Un plus es si además los cambios los va a manejar un equipo de desarrollo que tiene acceso al servidor de producción para subir archivos.