Mi abuela dice: “Si las tecnologías se convierten en una jaqueca, pues ríete de ellas, úsalas como esclavas, doblégalas a tu parecer, llévalas al límite. Si aún te responden con eficacia pues qué bien, podrás seguirlas machacando, redescubriendo y mejorando. Y el día que te dejen varado, pues mándalas al demonio o continúa creciendo con o sin ellas porque a fin de cuentas eres un ser libre”. Es de esta forma como deberías ver tu carrera profesional… Y es también de dicha forma como deberías leer este artículo.

“Soy fanático de…”

Permítete ser fan de The Matrix, Pink Floyd o los Tigres de Aragua, pero no de tecnología alguna (y menos de un CMS). El sujeto fanático -en general- experimenta a cada rato esa divina mezcla cuasiarmónica de entusiasmo, adrenalina, apego frenético y una ignorancia tan ingenua que llama a la ternura. Si acaso eres fanático a capa y espada de Joomla, Wordpress o cualquier otra aplicación, mi modesto consejo hacia ti es simple: deja de serlo, no vale la pena. En este momento importa más tu criterio y crecimiento profesional que las 4 paredes de código dentro de las cuales estás empeñado en encerrarte. En lugar de invertir tiempo en encajonarte en un CMS, dedícalo a aprender lo que más te gusta: programar, diseñar/maquetar o planificar proyectos.

Quién escribe esto

Antes de entrar en tema, quizás resulte oportuno mencionar un par de datos sobre quien se encuentra martirizando las teclas en este preciso instante. Comenzar diciendo que he implementado Joomla en numerosos proyectos web, además de colaborar en la difusión del conocimiento del software a través de diversos artículos, así como experimentos varios de mejora de la plataforma tales como mostrar componentes como módulos o gestionar el CSS de Joomla dinámicamente. Hasta hace un par de años desarrollé alrededor de 22 portales y tiendas electrónicas bajo esta aplicación, pero el grueso de los trabajos en aquél entonces estaban constituidos por desarrolladores que requerían servicios para desarrollar módulos y componentes personalizados. Adicionalmente soy miembro del equipo de soporte de Joomlaworks (uno de los más relevantes desarrolladores de add-ons para Joomla) y moderador general de los foros de JoomlaSpanish (partner oficial en español de Joomla.org). En fin, conozco el software.

En cuanto a Wordpress, reconozco que todavía no he conquistado el nivel de dominio que llegué a poseer con Joomla, aunque -basándome en lo aprendido hasta el momento- me siento optimista sobre lo que aún está por transcurrir. En el presente aplico Wordpress en los proyectos que desarrollo, pues con éste he alcanzado resultados de mejor calidad integral, ejecutados en la mitad del tiempo y, desde luego, con menores costos para el cliente.

Joomla: estrictamente orientado al usuario común.

Joomla es un CMS esencialmente orientado a facilitarle la vida al usuario como ente creador de presencia en la web. Esto quiere decir que gracias a Joomla cualquier secretaria de recepción puede poseer, en escasos minutos, un completo sitio web con un montón de elementos preintegrados y el consecuente control integral desde un completo panel de administración. En ese aspecto Joomla es un líder indiscutible, superior a cualquier CMS.

Resulta acertado afirmar que Joomla es una aplicación prefabricada en el puro y crudo sentido de la palabra. A diferencia de Wordpress, éste dispone nativamente de múltiples recursos controlables desde el panel administrativo, tales como sistemas de encuestas, banners, formulario de contacto, gestión de feeds RSS y hasta colorizado de sintaxis (basado en GeShi) si lo necesitas en tu contenido. Igualmente Joomla fue pionero en la implementación de la llamada “papelera de reciclaje” en un gestor de contenidos, característica que -en contraste- Wordpress recién implementó a partir de la versión 2.9.

Tal como es ampliamente conocido, Joomla es hijo pródigo de Mambo, una aplicación cuya arquitectura fue conceptualizada desde un principio en función del usuario común, aquél que no sabe ni pío de programación y diseño web pero que al mismo tiempo tenía el derecho y necesitaba tener presencia en internet. En aquél entonces, Mambo le otorgó a ese usuario el poder, no sólo de tener su propio sitio, sino un sitio completo, con todos los accesorios y recursos necesarios para gestionar contenido, interactuar con los visitantes y hasta monetizarlo. Dicho esquema se mantuvo y sigue manteniendo con Joomla.

Wordpress: orientado al usuario y al desarrollador web

En más de una ocasión he mencionado que Wordpress se acerca más al concepto de framework que al de un CMS en sí. Visto desde el punto de vista de un programador, esta aplicación constituye un surtido de recursos que sólo pueden ser calificados como soluciones. La arquitectura de Wordpress está fundamentada en principios productivos, cuya finalidad no es otra que la más apreciada por un desarrollador: consultar datos y devolverlos sin ningún accesorio imprevisto. Wordpress devuelve al desarrollador la capacidad de decidir cómo, cuándo y dónde quiere colocar sus datos. Wordpress permite al diseñador controlar la totalidad de la estructura y presentación resultantes.

Ahora bien, si aquella secretaria de recepción instalara Wordpress, no llegaría a obtener más que un blog en pocos segundos. Por tal motivo, cuando me tropiezo con algún artículo que afirma que “Wordpress sólo sirve para blogs”, inevitablemente imagino que detrás del teclado se encuentra alguna secretaria de oficina (o su equivalente en conocimientos sobre este software).

Wordpress es un CMS para lo que la creatividad dicte (creatividad: imaginación orientada a lo productivo). No obstante, Wordpress necesita de una mano profesional para demostrar todo lo que es capaz de ofrecer. Si pensabas que -por ejemplo- era imposible personalizar una interfaz administrativa de cabo a rabo sin tocar un pelo de los archivos del núcleo, es que aún no conoces Wordpress.

¡Ah! también sirve para blogs :)

Por qué Joomla no puede ofrecer el mismo nivel de personalización que Wordpress

¿Qué son los archivos del núcleo?

Son todos aquellos archivos que conforman la aplicación cuando está recién instalada. Me refiero a todos, desde el directorio raiz hasta el último escondrijo. Esos archivos no deben editarse jamás, pues -y aquí viene la primera Regla del buen CMS- uno de los primeros requisitos que debería cumplir un CMS con quien decida emplearlo, consiste en ofrecer los suficientes recursos que permitan al desarrollador proceder a su criterio sin necesidad de modificar los archivos del núcleo.

¿Por qué es inconveniente editar tales archivos? Porque las actualizaciones requieren tener plena disponibilidad sobre éstos para sobrescribir lo que sea necesario. Las actualizaciones son modificaciones que el equipo oficial de desarrollo efectúa al software. Éstas pueden incluir mejoras, soluciones de fallos o parches de seguridad en sus distintos niveles. Es importante que mantengas tu CMS actualizado. El procedimiento para tal fin es cuestión de minutos si mantienes intactos los archivos del núcleo.

De igual manera, si eres un cliente en la búsqueda de quien se encargue de tu proyecto web y, al mismo tiempo, tu proyecto involucra un CMS, debes asegurarte de que el futuro programador no toque esos archivos. Que proceda a criterio siempre y cuando respete esa regla única. Verás que tal manera de proceder te ahorrará múltiples dolores de cabeza a la hora de mantener el sitio al día. Entiende que las actualizaciones son tareas periódicas y debes considerarlas como parte normal del conjunto de procedimientos implicados en la optimización de un sitio web. En virtud de ello debes evitar todo tipo de elementos obstaculizantes para tal fin.

El problema con Joomla

Entendido el concepto de los archivos del núcleo de un software -así como la importancia de no modificarlos- nos encontramos con uno de los cuellos de botella más aleccionadores que puedan encontrarse.

Hace pocos años nació (ignoro de dónde pero nació) un planteamiento muy interesante en la llamada comunidad de desarrolladores web, cuya principal propuesta consistía en la opción de utilizar gestores de contenidos prefabricados en los proyectos para ofrecer más calidad a menores costos y tiempos mínimos de ejecución. Dicha tendencia resultó enteramente imprevista, y más imprevista aún para los respectivos equipos de desarrollo de Mambo/Joomla, quienes -como ya mencioné- habían jugado todas sus cartas en función del usuario común (sí, el que no sabe ni pío).

En virtud de tal estrategia y comparándolo con Wordpress -que desde el principio sí encauzó su código hacia un entorno de desarrollo- Joomla tenía y sigue teniendo muy poco que ofrecer en materia de:

• Sitios que requieran escalabilidad de cero a infinito.
• Recursos nativos que ofrezcan total libertad de acción al programador para controlar lo que éste quiera controlar, sin que por tal motivo sea necesario modificar, desde luego, el núcleo.

Ante las nuevas tendencias de aprovechamiento de la tecnología, muchos individuos (yo incluido) insistían en que Joomla también podía responder exitosamente a requerimientos que involucrasen proyectos web de compleja estructura contextual. Nada más lejos de la realidad.

Si Joomla es el pan listo para servir, Wordpress es la harina aún en el empaque. Puede que el pan servido y calientito guste a unos cuantos, pero justo cuando el comensal comienza a exigir algo más que un pan (o un pan de características más adaptadas a sus requerimientos) es cuando termina el encanto de Joomla, mientras Wordpress recién comienza a calentar motores.

¿Nos entendimos o no? Joomla es el juguete lujoso con todos los accesorios, Wordpress la caja de Lego. Joomla es el edificio, Wordpress el montón de ladrillos, cemento y arena. Quien compre un edificio podrá gozar de su comodidad a mediano plazo, pero sólo crecerá a la misma altura de éste. Quien opte por los ladrillos y cuente con un buen profesional para trabajarlos, sencillamente conseguirá lo que quiere.

Si Neo tuviese que escoger entre ambas, Joomla le diría “My way or the Highway” mientras paralelamente Wordpress diría “There is no spoon”.

No obstante, ser la caja de Lego o el montón de ladrillos no debe implicar que el usuario final (tu cliente) deba estar lidiando diariamente con legos y ladrillos, sino que tú tendrás el camino libre para construirle un sitio justo a su medida y totalmente escalable en el tiempo. Para una mejor comprensión de dicho factor veamos la siguiente lista de casos ilustrativos:

Personas, situaciones y soluciones

Si en este momento se efectuara una encuesta acerca de lo que distintos tipos de usuarios buscan en un CMS, probablemente las siguientes figurarían entre las principales respuestas:

1. El usuario común: “Quiero un software de fácil instalación y operatividad que además me ahorre, en la mayor medida posible, la jaqueca de meterme con los códigos. Quiero un panel de administración desde el cual pueda controlar todo el sitio, hasta el mínimo detalle. Quiero disponer de un montón de recursos al instante, todo sencillo, todo fácil. Y no quiero pagar un centavo por ello”. (Solución: Joomla)
2. El diseñador web amateur: “Quiero un sistema que me proporcione el máximo posible de etiquetas y snippets prestablecidos, a fin de permitirme enfocarme en el diseño/maquetación del sitio, sin necesidad de lidiar con programación”. (Solución: Joomla/Wordpress)
3. El diseñador web profesional: “Quiero lo mismo que el diseñador web amateur, y además necesito controlar el 100% del HTML resultante”. (Solución: Wordpress)
4. El programador web amateur: “No sé lo que quiero y el hecho de no saberlo me parece genial. En este momento estoy encerrado en mi habitación, totalmente enfocado en mi aprendizaje de PHP. No como ni duermo, y uso pañales de adultos para no tener que ir al baño. En la puerta hay un letrero que dice ‘Favor no molestar’ que significa exactamente eso: favor no molestar“. (Solución: una chica que lo salve de la demencia)
5. El programador web profesional: “No quiero nada, yo mismo construyo mi vaina desde cero. Pero si algún día optara por basar mis proyectos en una plataforma de gestión de contenidos, desearía un sistema que bajo ningún concepto entorpezca mi proceso propio de desarrollo”. (Solución: Wordpress)
6. El cliente: “Quiero exactamente lo que pedí. Favor prestar atención a la palabra ‘exactamente’, la cual no significa ‘aproximadamente’ ni ’semejante a…’ sino exactamente“. (Solución: Wordpress + una mano profesional)

¿Podría Joomla fexibilizar radicalmente su arquitectura a favor de un entorno de desarrollo?

Posible pero difícil. En realidad Joomla sí tuvo una oportunidad única para replantear totalmente su arquitectura y no lo hizo. Eso fue en el transcurso del año 2007, cuando su equipo oficial de desarrollo decidió separar la plataforma -de las entonces versiones 1.0.X- de la llamada “herencia Mambo”. Ciertamente se efectuaron numerosos cambios que implicaron una reescritura completa del núcleo. Tan profundos fueron dichos cambios, que subir las 1.0.X a la 1.5 no implicaba una actualización sino una migración total de datos, tal como si se tratase de dos aplicaciones distintas.

Al final del día, el nuevo Joomla 1.5 no era extremadamente distinto al 1.0.X. De hecho, aún la plataforma sigue atada al famoso “legacy” (la compatibilidad con versiones viejas). Esta medida fue necesaria para no dejar obsoletos la gruesa cantidad de add-ons y plantillas de terceros existentes hasta entonces. Y el precio del “legacy” fue, precisamente, seguir atado a la “herencia Mambo” hasta el sol de hoy. Creo que es muy difícil que Joomla ejecute una segunda vuelta total de tortilla.

Con Wordpress ocurrió un hecho similar (en cuanto al cambio radical de plataforma) pero la estrategia fue exactamente la contraria de Joomla, ya que el Core de WP sí se pasó por el forro las contribuciones de terceros, es decir, se le dio prioridad a la arquitectura (lo realmente permanente y evolucionable), pero pagaron el precio de dejar obsoletos todos los plugins existentes en aquél momento. Sólo funcionaban los que no requerían la base de datos para operar, es decir, una mínima cantidad. Tal cambio se dio en la versión 2.2, cuando se implementó por primera vez nada menos que el sistema de taxonomías.

Sólo imagínense si el core de Wordpress hubiese tomado la misma decisión equivocada que el core de Joomla: el software hubiese quedado totalmente estancado y -tal como Joomla- debatiéndose entre callejones sin salida: por un lado la evolución/involución de la aplicación, y por el otro los add-ons (plugins en este supuesto negado) con los cuales había que “quedar bien”.

Por cierto, Hoy en día Wordpress cuenta con el doble de add-ons que Joomla, los cuales operan bajo una arquitectura más robusta, versátil y escalable que las pre-2.2.

Conclusión

• Si no posees conocimientos de desarrollo web, deseas instalar un completo sitio en un santiamén de forma libre y gratuita, Joomla es tu mejor opción.
• Si necesitas desarrollar un sitio que requiera máxima personalización de elementos y funciones (incluyendo interfaces de usuario y administrativas), controlar el 100% del código, y posees los conocimientos suficientes para hacerlo, tu mejor opción es Wordpress.

¡Espera el resto de las partes de este artículo!

Las partes 2, 3 y 4 del presente artículo conformarán precisamente la explicación técnica de todo lo expuesto hasta ahora (no pensabas que te iba a dejar en el aire con este aspecto). Prepárate para analizar códigos, diagramas y demás elementos detallados.

2ª parte: Tareas altamente esenciales que no se pueden hacer con Joomla (y sí con Wordpress) sin tocar los archivos del núcleo

• Taxonomías (u organización de secciones). Profundidad, versatilidad y límites. Concepto e importancia para desarrollar estructuras complejas de contenido.
• Controlar el 100% de las funciones y comportamiento del sistema (frontend y backend)
• Controlar el 100% del HTML y CSS de toda la interfaz (frontend y backend)

3ª Parte. Templating en Joomla y Wordpress

Hasta dónde puede llegar la capacidad de cada una de estas aplicaciones en el desarrollo de plantillas y cuáles son los recursos que las mismas tienen disponibles para tal fin.

4ª Parte. Desmintiendo mitos trillados.

¿”Wordpress sólo sirve para hacer blogs”? ¿”Joomla es lo ideal para portales de alto tráfico”? Son algunas fantasías trasnochadas que nos ocuparemos de desmentir una a una con pruebas en mano, pelos y señales. También tomaremos ciertos artículos como referencia. Quien luego de leer la 4ta parte aún desee seguir fantaseando, pues nada, que se trague la pastilla azul y despierte creyendo que sólo tuvo una pesadilla.

La verdad aunque duela a algunos: a Wordpress.org no le importa Google, pero aún así Google sigue amando a Wordpress cual masoquista a su sádico. De esta pervertida relación podemos sacar provecho, ya que -a falta del motor de búsqueda nativo de Wordpress- Google es la mejor opción para tal cometido ¡aún mejor que el mismo Yahoo, quien funge de motor interno de búsqueda en el sitio oficial y -a pesar que tiene toda la buena venia que el core le otorga- todavía se le hace imposible superar a Google en resultados!

Lo único que queda es discriminar el contenido de calidad ¿y cuál es el fulano “contenido de calidad”? pues los temas resueltos. Al respecto tenemos dos puntos a favor: 1) Wordpress posee un sistema para indicar si el tema está resuelto o no y 2) Generalmente los usuarios son colaboradores al respecto y, en su defecto, los moderadores suelen hacer el trabajo. El texto publicado es: “This topic is resolved”. Entonces la sintaxis para buscar sería:

Un par de ejemplos para ilustrar: get_posts, WP_Query o “blank page after upgrading” ¿Qué representan estos resultados? Pues nada menos que numerosos problemas experimentados por múltiples usuarios, los cuales fueron resueltos… ¿Útil no?.

Esto último es un problema, pues al involucrarse la BD en el asunto, ya no basta con estrategias externas para redimensionamientos masivos (por ejemplo con un eventual script basado en GD / Imagemagic, o bien un procesamiento por lotes vía Photoshop). Nada de eso. Hay que decirle a la base de datos que los nuevos archivos miden tantos x tantos píxeles, y esto último involucra meterse con cada array del campo (porque son arrays). Todo un infierno descartable por donde se mire.

La otra estrategia se resume en un trabajo “de hormiguita”, el cual consiste en -luego de haber configurado los nuevos tamaños prestablacidos- meterse en cada entrada/página, borrar las viejas versiones y subir las nuevas, las cuales serán reingresadas en la base de datos y -para nuestra fortuna- se ubicarán en los mismos directorios donde se encontraban antes de ser eliminadas.

El método rápido

0) Respalda todo antes de comenzar: archivos y datos.

1) Realiza una nueva instalación de Wordpress en tu servidor local. Asegúrate de utilizar la misma versión que tu sitio web. No olvides hacer lo siguiente:

- Borra toda la información de posts, categorías, páginas y enlaces que vienen predeterminados con la instalación. Es decir, vacía tu nueva instalación por completo de contenido.

- Configura todo lo concerniente a tus imágenes: nuevas dimensiones (Opciones > Media) y además la misma ruta de ubicación del directorio tal como la tienes en tu sitio (Opciones > Misceláneas). Generalmente la ruta es wp-content/uploads, pero si la personalizaste allá, haz lo mismo aquí.

- Dale a tu base de datos el mismo cotejamiento de caracteres que a tu sitio web.

2) Ingresa al panel de tu sitio web, específicamente en Herramientas > Exportar, genera el archivo de exportación y guárdalo en tu disco duro.

3) Ingresa en el panel de tu nueva instalación y dirígete a Herramientas > Importar, luego clic en la última opción “Wordpress” y sube el archivo. Una vez que todo esté listo para hacer la importación, el sistema te preguntará si también deseas agregar las imágenes adjuntas ¡marca esa casilla! y luego espera unos minutos a que Wordpress complete todo el proceso.

4) Una vez terminado el proceso, las imágenes quedarán redimensionadas. Ahora debes hacer los ajustes necesarios a tu sitio real (por favor, respalda archivos y base de datos antes de continuar):

Base de datos

- Métete en el PhpMyAdmin de tu sitio local, escoge la base de datos correspondiente a tu instalación, presiona la pestaña SQL y copia esto:

- Seguidamente te devolverá todos los resultados. Ahora debes exportarlos mediante el enlace Exportar que se encuentra abajo de la pantalla, específicamente dentro del menú “Operaciones sobre los resultados de la consulta”.

- Una vez dentro de la pantalla de exportación desmarca el renglón Estructura (no necesitas crear una nueva tabla) y en Tipo de Exportación elige UPDATE. A continuación marca la casilla “Enviar (genera un archivo descargable)” y descarga tu archivo SQL al disco duro.

- Entra al PhpMyAdmin de tu sitio web, escoge la BD de tu sitio y presiona la pestaña Importar (porque ya respaldaste tu base de datos verdad?). Sube el archivo SQL y espera a que el proceso se complete. Con eso queda lista la parte de los datos.

Archivos

- Borra todo el directorio de tus imágenes (o mejor aún, comprímelo, respáldalo y borra el original) y luego reemplázalo por el directorio local. ¡No hagas sobrescritura directa! Borra el viejo y sube el nuevo.

Listo! ya tienes tu sitio con todas las imágenes redimensionadas a gusto.

Algunos puntos a considerar

- Aparentemente el proceso es complicado. Si no estás seguro de poder completarlo exitosamente, puedes practicar en una copia íntegra de tu sitio web, para luego intentarlo con tu sitio en vivo.

- El proceso completo no debería llevarte más de 30 minutos + la subida de los archivos nuevos en un sitio con menos de 1000 entradas.

- Revisa si el directorio donde subes las imágenes no es utilizado por algún otro plugin. De ser así debes hacer una eliminación/reupload selectivos de directorios.

O me he tropezado con una de esas frases/joyas filosóficas cuyo significado sólo está reservado para las neuronas más portentosas de la galaxia, o ya estoy muy viejo y decadente como para comprender con eficacia esos textos publicitarios tan sofisticados de la actualidad. Hasta el momento me he tomado dos botellas ron y aún no logro contestar la pregunta de rigor: ¿Cómo demonios puede alguien declararse satisfecho antes de que el trabajo comience? ¡Mentes evolucionadas del mundo, he ahí un dilema!

Algunas cosas que el 2009 dejó

• Fundé mi blog y logré mantenerlo.
• Desarrollé un plugin de Wordpress.
• Compré mi primera motocicleta, aprendí a manejarla y estoy aprendiendo mecánica.
• Me acerqué a algunas comunidades de usuarios Wordpress.
• 2 mujeres de mi pasado me perdonaron de corazón.
• Aprendí otro montón más de PHP.
• Impartí dos ponencias muy aplaudidas.
• Probé varios frameworks en PHP y a través de ellos amé más la programación “a manito”.
• Colaboré en otros proyectos opensource.

Algunos planes para el 2010

• Reconquistar a mi esposa.
• Fumar menos (bah, siempre digo lo mismo).
• Aumentar mi colaboración en otras comunidades Wordpress.
• Desarrollar otro plugin.
• Hice nuevos amigos (cosa muy rara en mí pero lo hice).
• Terminar de escribir mi libro.
• Adelantar algunos proyectos propios en la web.
• Retomar las pesas y el trote para no convertirme en una bola de mierda.
• Dominar completamente la mecánica de mi moto.

¿Y tú, qué planes tienes para el año que viene y qué tomaste de este año?