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.

Traducción literal del artículo: Give Joomla backend managers access to any component! Control who has access! por Fotis Evangelou.

Uno de los problemas más comunes que enfrentan los desarrolladores cuando finalizan un proyecto basado en Joomla! Es la administración de acceso de usuarios o, para ser más exactos, la falta de control en el acceso de éstos. Hay numerosas soluciones para solventar este aspecto, tales como un componente comercial de Joomla Solutions llamado JBAM (Joomla Backend Access Management – $125) y el componente gratuito ACLPlus de Byostech. Ambos son hacks a los archivos del core y cada uno tiene sus inconvenientes, lo cual provoca que muchos usuarios/desarrolladores puedan mostrarse escépticos a la hora de usarlos.

No me malinterpreten, pero JACL es dependiente de la versión y JBAM es una forma complicada (y costosa) cuando todo lo que quieres es dar acceso a tus administradores a -por ejemplo- el componente de Encuestas.

Entonces ¿cuáles otras opciones podemos tener? Sólo modifica un poco un archivo por ti mismo y podrás habilitar a cualquier grupo el acceso al componente que quieras.

El archivo es éste: includes/gacl.class.php

Podemos asignar fácilmente acceso a determinados componentes para determinados grupos. Supongamos que quieres darle a tu Administrador los privilegios de añadir/eliminar cuentas de usuarios desde el panel de administración, pero no acceso a módulos o mambots. O bien quisieras habilitar a tus Managers para acceder a componentes de terceros tales como ArtBanners, lo cual resulta bastante lógico si trabajas con mucho contenido y deseas distribuir tareas diferentes a distintas personas.

Así que basta con modificar o añadir algunas líneas en el archivo includes/gacl.class.php y podremos controlar totalmente a qué partes del sitio pueden acceder los 3 grupos predefinidos del backend (Super administrador, Administrador y Manager).

Les daré un ejemplo de lo que usualmente hago.

1.- Restringir acceso a Administradores (no Super administradores) a módulos y mambots:

Aproximadamente en la línea 136, agrega barras de comentario a estas líneas, tal como aparecen a continuación:

Como puedes ver, se han comentado todas las líneas referentes a “administrator”. Así que cada vez que abra una nueva cuenta de usuario y darle privilegios de Administrador, sabré que nunca llegará a ver los menús de módulos y mambots.

2. Habilitar acceso a los Managers y Administradores a ciertos componentes:

Aprox. en la línea 152 donde dice:

Reemplaza este código…

… con las siguientes líneas:

Con esto hemos permitido el acceso de Administradores a los componentes: Correo masivo, Papelera, Encuestas, JoomFish y ArtBanners, pero NO a YanC o VirtueMart (el acceso al administrador de media es dado como estándar). Esto no sería posible con los controles predeterminados de Joomla! para el control de accesos de usuarios.

Conclusión

De esta manera podemos “distribuir” fácilmente los privilegios de acceso de 2 grupos de usuarios (Administrador y Manager) a determinados componentes sin necesidad de instalar un componente fabricado por terceros.

Nota que existen algunas restricciones para ciertos grupos de usuarios en Joomla! de forma predeterminada que no pueden ser cambiados por los “hacks” mencionados. Por ejemplo, los Managers no pueden manejar la Administración de Usuarios ni pueden accesar a la configuración Global.

Pero en la mayoría de los casos, todo lo que necesitarás es habilitar acceso a tus Managers a los componentes de terceros, y probablemente restringir a los Administradores para que no “jueguen” con módulos y mambots.

Publicado en Maestros del Web | Versión en inglés publicada en JoomlaWorks

CSS es una tecnología web diseñada para controlar la presentación y diseño de los sitios. Su existencia devuelve el propósito original al HTML: gestionar la estructura y flujo del contenido. El CSS también abrió un abanico de posibilidades al diseñador web, al ofrecer novedosos y funcionales recursos aplicables a la maquetación, además de la conocida reducción del conjunto de códigos, lo cual también se resume en ahorro de tiempo, así como mayor facilidad en el control del trabajo.

No obstante, es posible agregar más productividad al CSS implementando lenguaje dinámico. El método no es nuevo; los primeros ejemplos que pudimos observar datan de varios años. En esta oportunidad orientaremos su implementación al sistema Joomla!, una acción que se traduce en múltiples beneficios y ventajas, con las cuales no contábamos antes.

El problema

Entre los inconvenientes de llevar al límite la personalización de Joomla! se encuentra el hecho de que a menudo se generan grandes hojas de estilos. Esto se debe, en parte, a la necesidad de diferenciar estilos correspondientes a las diversas zonas del sitio, tales como contenido, weblinks, contactos, galerías, diversos módulos, etc. El problema en sí no radica en el tamaño del CSS, el cual no suele pesar mucho. Por ejemplo, para que la hoja de estilos pese unos 20Kb se requiere más de 1000 líneas de código.

¡Precisamente en esa cantidad kilométrica de líneas está el problema! Quienes trabajamos con Joomla! de manera constante, seguramente ya nos hemos inventado un sistema de procedimientos para no perdernos en esa maraña de códigos. Para contrarrestar esto, algunos diseñadores separamos los archivos CSS según la organización del trabajo, importándolos luego desde una hoja de estilos principal. De esta forma no nos confundimos tanto como si se tuviera todo en un solo documento. Dicha acción soluciona el problema… hasta que llega el momento de dispersar los selectores para evitar la redundancia de propiedades, lo cual constituye un verdadero tropiezo que destroza el orden de los estilos, sobre todo si somos dados a clasificarlos alfabéticamente.

Entonces ¿Cuál es la causa específica de este problema? La respuesta es simple: La calidad estática de la hoja de estilos. Cuando la parte del HTML contiene toda la carga de código, obviamente el CSS debe compensar la desigualdad de condiciones con más información, más datos. Una gestión dinámica de los estilos nivela la ecuación de manera sorprendente. Y los resultados te encantarán.
Los beneficios

El nivel de beneficios que ofrece un CSS dinámico depende directamente de los requerimientos del proyecto a desarrollar. En el caso de webs dinámicas las ventajas son indiscutibles. En esencia podemos resumirlas así:

• Reducción de la redundancia de código CSS y/o dispersión de selectores: Sobre todo, esto se observa en la maquetación de webs dinámicas, donde se hace necesario asignar estilos a diversas secciones del sitio. Un procedimiento usual para contrarrestar esto consiste en la asignación de varios selectores a un mismo conjunto de estilos, lo cual rompe el orden de su disposición, sobre todo si están clasificados alfabéticamente.
• Recursos extra para el desarrollador: todas las bondades del PHP están disponibles para ser usadas con creatividad y lograr objetivos que serían imposibles con una hoja de estilos común.
• Distribución equitativa de la carga de código dinámico: El hecho de implementar PHP en la hoja de estilos se resume en la simplificación de muchos procesos. Más adelante abordaremos este tema en detalle.
• Interpretación limpia del documento: No existen bugs ni sorpresas extrañas en la lectura de un CSS dinámico por parte del navegador.
• No rompe con los estándares W3C: Si la “hoja de estilos” está bien construida, el validador lo aprobará normalmente.

Los puntos en contra

Hasta ahora hemos visto un par de pequeños inconvenientes que no afectan el funcionamiento, pero aún así los anotamos:

El CSS se incluye en el HTML interpretado: Una hoja CSS separada puede procesar la mayoría del código PHP. Sin embargo, existe un problema con las funciones específicas de Joomla!, las cuales no se ejecutan si la hoja de estilos es enlazada como un CSS normal. Sólo funciona si agregas el archivo como un include. Esto ocasiona que el contenido se refleje directamente en el HTML, funcionando a la perfección, pero es posible que algunos encuentren esto un tanto antiestético.

La información CSS se carga cada vez que se cambia la página: Unos cuantos gramos de más en el conjunto de Kb de carga. Algunos diseñadores prolijos en la reducción de peso en el conjunto de archivos experimentarán cierta incomodidad con esto.

En cuanto al trabajo del CPU en procesar la información PHP contenida en la hoja de estilos dinámica, no creemos que represente un inconveniente. La carga de instrucciones correspondientes al CSS no serán tan relevantes como para retrasar el tiempo del servidor en procesarla. Recordemos también que la intención no es agregar más código a nuestro proyecto, sino reducirlo de manera sinérgica para lograr mejores resultados gracias a su distribución lógica y equitativa.

El método actual de trabajo en Joomla!

A continuación explicaremos parte del método profesional de personalización de un sitio Joomla!. Supongamos que deseamos colocar un logo en nuestra Página de Inicio y otro en el resto de la web.

En el index.php:

… Y en la hoja CSS:

Ahora bien, si no se desea la repetición de estilos, ésto es lo que se hace:

Lo anterior ilustra un mínimo ejemplo de asignación de clases distintas a una sola sección. Imaginemos el pandemonium de estilos que se produciría cuando además deseamos personalizar módulos, tipografía y toda la presentación entre un área y otra del sitio. Algunos nos “ahorramos” un trecho de trabajo cambiando el nombre de la clase de la capa padre que funciona de contenedor y en lugar de escribir -por ejemplo- div#cabezal-2 lo colocamos como #contenedor-2 div#cabezal; de esta manera todo lo que afecte a dicha sección estará regido por #contenedor-2 [clase]. Si existe una capa padre, todas las etiquetas contenidas dentro de ésta llevarán su clase anticipada.

El otro modo de personalización de clases lo ofrece Joomla! de forma nativa, a través de la posibilidad de agregar un sufijo a la clase de determinado módulo, componente, menú y hasta artículo a través del panel de administración. El cambio quedaría archivado en la base de datos. Personalmente no utilizo este recurso porque no es necesario, salvo en casos muy esporádicos.

Bien sea de una u otra forma, el resultado inevitable es 1) la acumulación de estilos y 2) la dificultad en la localización y manejo de los estilos a partir de cierto punto. No es un padecimiento exclusivo de Joomla! sino de toda aplicación web, pero dada su amplitud de funciones y recursos (y por lo tanto de estilos), en Joomla! se hace más notable. Ya mencionamos que el problema es la calidad estática del CSS. La solución siempre estuvo ante nuestros ojos y es la siguiente:

Construyendo un CSS dinámico orientado a Joomla!

El método que estamos a punto de aprender da un vuelco radical a la forma en que actualmente vemos el diseño de sitios Joomla!. Es posible que otro tipo de plataforma dinámica no requiera de tanta sofisticación en la gestión de estilos. En Joomla! se hace necesario una vía capaz de abreviar los pasos a seguir a la hora de abordar el diseño de una web. La primera vez que observé este procedimiento fue en la hoja de estilos del pack PhpMyAdmin; luego de recoger mi mandíbula del suelo pude comprobar que efectivamente no es una novedad, sino -para nuestra fortuna- un método bien practicado y documentado en la web a nivel general, aunque lamentablemente escaso en nuestro idioma.

La preparación de los archivos constituye uno de los pasos más importantes. Lo primero que haremos será definir las rutas en el index.php de la plantilla. Esto lo lograremos a través de variables, las cuales no sólo servirán para que nuestro CSS dinámico funcione correctamente, sino para abreviar muchos procedimientos en el diseño. Igualmente le diremos al index dónde están los estilos:

Como puedes notar, la hoja de estilos está siendo llamada como un archivo PHP común. Repetimos que ciertamente es posible enlazarla como una hoja CSS aparte, pero dicha acción desactiva la funciones más importantes de Joomla! y en dicho caso no valdría la pena implementarla.

En cuanto a la acción de definir las rutas, tiene su buen motivo: Al ser un CSS incluido en el HTML, las rutas de las imágenes ya no apuntarán desde el index de la plantilla, sino desde el index.php del directorio raiz del sitio. Las variables nos ahorran la molestia de escribir esas largas direcciones todo el tiempo.

Ahora nos ocuparemos de crear un archivo llamado css.php (o como desees) en la ubicación que nos resulte más cómoda. En este caso lo colocaremos en el directorio de las hojas de estilo /templates/mi_template/css/css.php. Le introducimos los primeros datos:

¿Ya estás comprobando la importancia de definir las rutas? La penúltima línea tiene como objetivo direccionar correctamente la carpeta donde se encuentran las imágenes por medio de una función de reemplazo. Por otra parte, la última línea es la que dará salida a todo lo que coloques en el espacio destinado a los estilos.

Ya nuestro CSS dinámico está lista para recibir datos. Abordemos ahora algunos ejemplos prácticos.

Ejemplo 1

Supongamos que deseamos colocar un logo en nuestra Página de Inicio y otro en el resto de la web. (Para ayudar a comprender la sintaxis hemos colocado comentarios a la derecha de cada línea).

Seguramente ya comienzas a visualizar el ahorro de tiempo y esfuerzo. Sólo esta acción evitó:

• Que hiciéramos el trabajo de diferenciar componentes en el index.php, sólo para asignarles clases distintas, y consecuentemente…
• Que redundáramos las clases en la hoja CSS, o…
• Que asignáramos sufijos de clases distintos a nivel de panel, de forma innecesaria, lo cual provocaría más redundancia o -en el mejor de los casos- la dispersión de selectores al tratar de reducir la repetición.

Mientras tanto, el resultado del ejemplo anterior es sencillo de comprobar. Al observar tu hoja de estilos desde el navegador, sólo existirá un div#cabezal, pero con datos acordes a la sección en la cual nos encontremos en ese momento. Sigamos con más ejemplos.

Ejemplo 2

Ahora imaginemos que queremos colocar un logo distinto en la sección de Enlaces Web, pero manteniendo lo anterior.

Ejemplo 3

Veamos ahora otra variante del caso un poquito más compleja. Supongamos que ese mismo logo de los Enlaces Web tiene un tamaño distinto a los otros

¿Semántica dinámica?

Existe un factor que desde ahora deberíamos tomar en cuenta e internalizar como principio. En el diseño web moderno hay una regla infalible y muy simple: El HTML se ocupa de todo lo referente a la estructura, y el CSS de todo lo referente a la presentación. Puesto que el CSS también pasó a ser dinámico, esa regla debería seguir vigente: el código PHP que controla la estructura se escribirá en la parte del HTML, y el PHP que controla la presentación se escribirá en la hoja de estilos CSS.

Lo anterior no sólo suena lógico, sino que nos ayudará a organizar mejor nuestro trabajo, tanto en la ubicación/disposición del código como en la resolución de problemas, además de hacer más fácil la búsqueda e identificación de posibles problemas (que van desde una simple capa mal colocada hasta errores de diversos tipos). Construir una web dinámica es un proceso complicado por sí mismo puesto que el sitio no está compuesto por archivos; toda la información, enlaces, secciones, categorías y demás reposa copm texto en una base de datos. Si queremos personalizar al máximo una web en estas condiciones, es necesario encontrarle un uso más sinérgico y organizado al motor que la controla, el PHP.

Sólo imagina las posibilidades de lo que puedes lograr. Para una muestra de lo mencionado veamos el siguiente ejemplo.

Ejemplo 4

Aquí vamos a rotar 3 imágenes de un cabezal en orden aleatorio. La rotación se produciría con cada refresco de página, mientras se conserva la misma clase todo el tiempo. Todo esto empleando sólo CSS dinámico:

Ejemplo 5

Ahora agreguemos más condimento al mismo caso. Supongamos que cuando la Página de Inicio muestre un juego de logos rotatorios, la sección de Contenido mostrará otro, mientras que Enlaces Web tendrá un juego distinto:

Es perfectamente posible lograr esto trabajando la parte dinámica en el HTML y agregando unos cuantos estilos más. El procedimiento anterior refleja sólo un estilo en el resultado del CSS, que cambia según la sección donde se encuentre el usuario. Es muy importante asignar las porciones de código en el archivo correspondiente, distribuyendo así los fragmentos de manera lógica.

Anteriormente se mencionó que podía organizarse mejor el trabajo siguiendo el mismo principio semántico que rige al diseño web: Estructura para el HTML y presentación para el CSS. Ciertamente es posible hacer más de lo debido con el CSS dinámico, pero luego de probar algunos escenarios que fuerzan la capacidad y objetivo original del CSS, pude percatarme que es mejor mantener las cosas dentro de dicho principio, pues de lo contrario se causarán más problemas de los que se resolverían.

Por lo tanto es mejor distribuir la carga, porque una de las principales recompensas la constituye el hecho de liberar buena parte de la responsabilidad a la parte del HTML (el index.php de nuestra plantilla). Anteriormente era necesario crear nuevas clases, dejando todo el peso dinámico a dicha sección, mientras el CSS permanecía estático y acumulando líneas eternas para compensar la desigualdad de condiciones.

Conclusión

Hasta ahora hemos observado al PHP haciendo un trabajo más productivo que un mosLoadModules o cualquier otra sintaxis propia de una plantilla común. Llevando la gestión de estilos a un carácter dinámico, hemos logrado simplificar de manera relevante varios aspectos que hasta el momento resultaban un dolor de cabeza. La combinación PHP + CSS supone la existencia de un cúmulo de recursos, tan extenso como para considerarlo una gran e inesperada puerta abierta con mucho para aprovechar.

La semántica del código también contribuye -aunque no por sí misma- a aumentar la calidad sinérgica del proyecto. En el campo que tratamos, sinergia consiste en el logro de mejores resultados con el menor empleo posible de recursos. Utilizándolos con habilidad y creatividad, seguramente encontrarás vías más rápidas y simplificadas para alcanzar los mismos objetivos que anteriormente exigían unos cuantos pasos extra.

Como diseñador(a) web es necesario que tengas claro qué nivel de flexibilidad necesitas de tus recursos y prepararte para adquirir nuevos conocimientos, cuya dificultad la determinan las mismas metas que te propongas completar. El método explicado no es ciencia astronáutica o ingeniería nuclear. Lo único que se requiere es nuestra disposición a reconocer que existe un ingrediente más que el puro HTML y CSS, el cual nos ayudará a desarrollar webs más impactantes, con altos niveles de personalización y calidad integral. ¿Verdad que ahora te resultará difícil no querer intentarlo?.

Documentación

• CSS Colors: Take Control Using PHP
• Manual de PHP.net
• Generating Dynamic CSS with PHP
• How to create a flexible stylesheet for WordPress theme