Definir secciones en una web

Para construir una web de cierto tamaño se usan hoy en día potentes gestores de contenidos. Esto es así porque no se puede organizar correctamente ni configurar todos los elementos sin un motor que se encarge de la gran cantidad de detalles necesarios: menús, plantillas y elementos visuales, permisos, bloques resumen, links y herramientas sociales, formularios, URLs y muchas otras cosas. Muchos de esos elementos son entidades que se organizan de forma fácil en algunos de estos gestores de contenidos como páginas, comentarios, menús, usuarios, listados o bloques laterales. Pero un elemento que no es tan fácil de organizar son las diferentes secciones de una web.

Una sección de una web sería todo un rango de páginas que comparten algun tipo de característica suficientemente distintiva como para percibir que estamos en una parte de la web totalmente distinta de otra. En general una página o un elemento que pertenece a una sección, no pertenece a otra. Una página de descripción de producto estará en una sección de productos claramente distingible de una página de noticia que estará en una sección de noticias. Dividir una web en secciones suele ser algo importante cuanto más grande es la web. Puede que cada sección tenga un público distinto, herramientas contextuales diferentes y incluso un aspecto gráfico diferenciado.

Generalmente esto es algo que se decide en la fase de arquitectura de un proyecto. El estudio de objetivos de la web debe distinguir estas secciones y sus páginas de entrada, a veces llamadas "home de sección" o "landings" (aunque este último término puede tener otros significados). En esta fase de arquitectura sobre todo lo que se decide es qué elementos contextuales, es decir, qué bloques y destacados conforman la información en las cabeceras, columnas laterales, pies de página y ventanas auxiliares, en cada página de cada sección. En general, dentro de una misma sección todos estos elementos son comunes y son los que nos ayudan a distinguir una sección de otra.

Rutas y bloques

Drupal en sí mismo no tiene una herramienta propia, a excepción de un mecanismo rudimentario en su gestión de bloques, para definir en qué rangos de páginas va cada bloque. Pero es un mecanismo que no permite grandes variaciones, es propio de webs pequeñas. Si el proyecto requiere dividir la en secciones diferenciadas necesitaremos alguna herramienta para definir qué rangos de páginas forman una sección.

Sin usar módulos adicionales aún podemos usar algunos trucos basados en patrones de URLs. Cualquier forma de organizar las URLs por patrones como "dominio/noticias" para la página inicial del listado de noticias, y un patrón para cada noticia del tipo "dominio/noticias/título-de-la-noticia" nos permite agrupar esta sección. La gestión de bloques de drupal permite entonces asignar un bloque para que solo aparezca en todas aquellas páginas de tipo "dominio/noticias" y "dominio/noticias/*" (ver siguiente pantallazo). Para ello es imprescindible usar el módulo "Pathauto", uno de los módulos más populares de la historia de Drupal desde sus principios. Estos patrones de rutas pueden hoy por hoy intercalar cualquier variable entre diversas del sistema o de los campos o taxonomías que aparezcan en un nodo.

La gestión de bloques de Drupal no solo se rige por las URLs, como podemos ver en el pantallazo adicional, también podemo usar otros criterios como el rol del usuario que ve una página, el tipo de contenido e incluso, si está activo el módulo "PHP" y tenemos suficientes permisos podemos escribir normas más complejas para este tipo de ajustes.

Módulos para la capa visual

Cualquiera que haya trabajado en sitios Drupal como mínimo medianos, sabe que este sistema resulta insuficiente en muchos casos. La primera limitación es que un bloque es asignado a una región y solo puede salir en ella en función de las normas de visibilidad que le hayamos dado. No hay posibilidad de que en otra zona de la web (sin una herramienta de secciones específica no podemos hablar de secciones) pueda ese bloque estar en una columna distinta, o en el prefooter, por ejemplo.

Para solventar esto tan pronto como a finales del 2004 aparecería el módulo "Sections". Este módulo no se actualiza desde 2010, pero era una solución interesante en su momento. Este módulo definía secciones distintas en funciones de los patrones de URLs, y a partir de eso permitía determinar una capa visual (en lenguaje Drupal un "theme") distinto a cada una. La pericia de los constructures de webs era crear temas visuales iguales en el diseño general pero diferenciados en cuanto a las regiones. De este modo, dado que la gestión de bloques laterales de Drupal permite asignar los bloques distintos para cada "theme", podiamos organizar mejor cada sección de forma diferenciada. En las webs que se contruían con Drupal 4 y 5 esto resultaba bastante interesante.

Aunque el módulo "Sections" también aparecería para Drupal 6, se vería claramente desplazado por "Themekey", que en su misma línea permitía cambiar de sección con una lista larga de muchos argumentos distintos. Si no fueran suficientes "Themekey properties" aún extiende más esta lista. Este módulo aún existe en Drupal 7 y puede ser interesante para muchos gestores de webs por su intuitivo interface, pero obliga a trabajar con varios "themes", lo cual puede ser un inconveniente importante. Además, programadores más avanzados pueden hacer todo eso y más, únicamente programando en el fichero "template.php" de un solo theme si solo se quieren secciones bien distinguidas en una web con una sola capa visual.

Módulos para definir secciones

De entre los módulos que permiten definir secciones se encuentran "Panels" y "Context", del que hablaremos en la próxima sección de este artículo. "Panels" es un módulo del mismo creador de "Views" el entorno universal de crear consultas a la base de datos para hacer listados. Si "Views" es una compleja y sofisticada pieza de software, no lo es menos "Panels". Con "Views" su autor (un señor llamado Earl Miles) intentó tan pronto como en Drupal 5 solventar el problema de generar listados. Con "Panels" resolvió en la misma época el problema de la gestión de bloques en distintas secciones sin tener que manejar la gestión de bloques de Drupal.

Recuerdo el entusiasmo que me generó la aparición de Panels en aquellos días. Panels permitía solventar cosas que eran imposibles con el sistema de bloques del core de Drupal. En esencia Panel sgeneraba nuevas páginas de un tipo distinto y propio que se podían dividir en grupos de regiones definibles en plantillas de Panels. El módulo ofrecía diversas plantillas preparadas pero se podían hacer otras nuevas con un formato relativamente simple. En estas regiones uno podía colocar bloques, listados en views o nodos, distribuyéndolos como más nos conviniera.

Panels 2 y 3 han ido generando mayor entusiasmo en la comunidad, y Panels aparece entre los módulos más descargados y usados de Drupal. Se han escrito libros enteros e incluso videoturoriales gratuitos sobre él, a los cuales remitiré a cualquiera interesado en saber más sobre Panels con una sencilla búsqueda en Google. En términos generales considero que siendo Panels un sistema fabuloso crea un modelo de gestión web un tanto complejo y confuso. En sí mismo usa una batería de módulos que añaden una carga considerable al sistema que no compensa quizá para añadir 2 ó 3 variaciones a la web. Evidentemente para quien no sepa programar esas 3 variaciones de la web en el sistema de plantillas de Drupal puede resultar irremplazable. Pero es innegable que añade más complejidad a la curva de aprendizaje de Drupal, a costa de proporcionar una descomunal flexibilidad que quizá solo tiene sentido en webs enormes y muy complejas.

Por otra parte el creador de Panels preveyó en cierto momento usar Panels como alternativa total al sistema de bloques de Drupal. Para ello se puede usar "Panels everywhere", pero de usarlo obliga a cambiar bastante la forma en que se gestiona Drupal y sus regiones, puede ser un cambio un tanto complejo de realizar.

El trabajo de dividir la web en unas pocas secciones se puede realizar con "Rules". Aunque Rules no es exactamente un módulo para crear secciones, sinó una herramienta mucho más genérica de acciones y reacciones, algunos complementos permiten hacer el tipo de ajustes que se requieren para definir estas secciones. Para ello será necesario instalar algunos submódulos complementarios como "Rules Bonus Pack" o "Theme rules".

"Rules Bonus Pack" es un módulo antiguo creado como ejemplo para crear nuevas acciones y reacciones. Aunque pueda parecer algo desactualizado tiene algunas muy útiles que pueden permitir a través del interface gráfico de Rules algunas actuaciones muy precisas como poner o quitar un bloque lateral, cambiar la etiqueta title de la página, añadir etiquetas de sección al body (realmente muy útil en la maquetación) y unas cuantas maravillas cambiando los views.

Context

Pero en Drupal 6 un importante grupo de desarrolladores de aquel momento que se denominaba Development Seed lanzó una nueva herramienta para definir secciones denominada "Context", que ha seguido desarrollándose también en Drupal 7. Context usa CTools para organizar su gestión y la entrada a su administración permite listar y agrupar las secciones con mucha lógica. Además es posible, en caso de dudas o conflictos, desactivar temporalmente un "context" desde este listado.

Context se basa en algo parecido a Rules, en el concepto de revisar que se cumplan unas condiciones y a partir de ahí disparar unas reacciones. Lo que pasa es que el interface de Context es mucho más intuitivo que el de Rules porque posiblemente tanto las condiciones como las reacciones solo se contemplan en cambios estructurales a nivel de página.

Si observamos el interface de Context de esta imagen precedente, en su parte superior se agrupan las "condiciones" y en su parte posterior las "reacciones". Context lleva incluidas unas cuantas condiciones y unas cuantas reacciones, pero su estructura de programación orientada a objetos permite que sea fácilmente ampliable por lo que han aparecido muchos módulos que proporcionan tanto nuevas condiciones adicionales como reacciones posteriores. Si desplegamos el listado de condiciones podemos obervar que es posible atender cosas como:

• el tipo de nodo
• si estamos en una vista de nodo o en su formulario de edición
• si estamos en una cierta página o en patrones de rutas (y con mayor comodidad que en la gestión de bloques ya que podemos indicar al mismo tiempo en qué rutas sí y en qué rutas no debe cumplirse)
• si es global a toda la web
• si depende de que en una página haya una cierta taxonomía
• cuál es el rol del usuario que está viendo la página en este momento
• si estamos en una página de usuario
• si estamos en un cierto "Views"
• si estamos viendo la página desde un móvil
• si estamos en una página de error
• si estamos en un cierto menú
• si debe producirse alguna de estas condiciones o todas al mismo tiempo

Entre las reacciones podemos observar cosas como:

• qué bloques deben estar activos
• qué menú debe aparecer como activo
• qué ruta de breadcrumb debe aparecer como activa
• si hay que desactivar un context que pueda estar activo (para evitar solapamientos o conflictos)
• qué capa visual debe estar activa
• si debemos redireccionar a otra página
• si queremos escribir una clase en la etiqueta body de la página

En estos pantallazos vemos muchas condiciones y reacciones añadidas desde módulos adicionales. Hay muchos más módulos que proporcionan más elementos, como respetar la configuraciones de los bloques, añadir etiqueta meta, que Rules dispare acciones en función de otros context activos, argumentos de views, valores concretos de campos que esperamos encontrar en esa página, gestionar CSS.

El sistema es muy extensible y fácil de usar. Al final es posible que en una web compleja acabemos con docenas de definiciones de contextos. Por ello es fácil no recordar entre tantos donde activamos tal o cual condición o reacción. "Context filter" crea en la gestión de context una nueva página donde buscar los context con ciertas condiciones o reacciones. Por otro lado existe un interesante módulo que nos permite tener unos cuantos context preparados y seleccionar en cada nodo a qué context queremos enviar esa página, interesante para construir gestores a medida de ciertas necesidades editoriales.

Conclusión

Como hemos visto no hay muchas herramientas para definir y gestionar secciones en Drupal. Aún y así con Rules, Panels y Context disponemos de herramientas muy potentes con enforques distintos, para que cada uno elija el que mejor considere que se adapta a sus objetivos. De todos ellos Rules puede ser el más difícil de configurar, pero puede que permita algunas combinaciones muy excepcionales, y en todo caso puede permitir ajustes muy puntuales que son difíciles de conseguir con Panels o Context.

Panels o Context son dos herramientas para el mismo objetivo aunque con enfoques distintos. Tras mi experiencia de muchos años he podido observar que cada una ha creado adeptos muy fieles a su filosofía. Por muchas razones que no se pueden exponer brevemente aquí yo "soy de Context" por ser muy ajustado en su interface al concepto de sección. Por eso en todas las webs que construyo incluyo este módulo y a menudo muchos de sus complementos, en función de requerimientos específicos de ese proyecto. Puede que Context no llegue a hacer todo lo que hace Panels, pero en general nunca me he encontrado una web que no pueda hacerla con Context, ya que esas cosas que se pueden hacer con Panels las acabo resolviendo de otras formas. El usar en profundidad un herramienta hace que con los años uno llegue a encontrarle formas de uso que quizá no estaban exactamente previstas inicialmente.

Pero en cualquier caso no se puede crear debate sin haberlas probado ambas. Para cualquiera que se esté iniciando en la construcción de webs en Drupal le aconsejamos probar ambos módulos en una sandbox de pruebas, para poder experimentar con ambas y así elegir aquella con la que se sientan más cómodos.