Hoy vamos con un truco para todas aquellas personas que utilizan el módulo de Panels en Drupal y quieren limitar la visualización de distintos widgets de contenidos en paneles de tipo nodo, dependiendo de la taxonomía a la que pertenezca el nodo visualizado.

Dentro del panel que estemos configurando (supongo que todos nuestros nodos tiran de un mismo panel), añadimos un contenido nuevo, pongamos un banner que solo queremos que salga en los nodos que pertenecen a la taxonomía/taxón “XYZ”. Para limitarlo, solo tenemos que añadir a dicho widget una nueva regla de visibilidad (Visibility rules), seleccionar que será de tipo “code PHP” e introducir el siguiente código:

$clave = 'XYZ';
$q = explode("/", $_GET['q']);if(count($q) > 1)
{$node = node_load($q[1]);
$terms = taxonomy_node_get_terms($node);
foreach($terms as $term) {if($term->name == $clave)
 {return TRUE;}}}return FALSE;

Por supuesto, no olvidéis indicar que el tipo de contenido introducido es PHP. Cambiamos “XYZ” por el nombre de la categoría en la cual queremos que salga y… listo!

Este es un claro ejemplo de Drupal llevado al extremo de la personalización y “toqueteo”, pero no ha hecho más que volver a demostrar el potencial que tiene este CMS para crear verdaderas aplicaciones que puedan ser utilizadas como base de negocio de una empresa.

Ya es la hora de que entren aquellas personas que van a dedicarse al mantenimiento evolutivo del proyecto, y sólo puedo esperar que lo traten con mucho mimo.

Cesar y Alex han tenido una gran parte de la “culpa” de que esta nueva versión viese la luz, al segundo de ellos, Alex, mucha suerte en Asturias, vas a vivir como un rey y a ser muy feliz.

Ahora, como corresponde a este negocio (al igual que muchos otros), tocará cerrar un libro y después de un par de días de vacaciones (que creo que me merezco ), empezaremos con un nuevo proyecto, todo nuevo, y a seguir aprendiendo.

Como es habitual, basándonos en que los dos buscan resolver una funcionalidad definida, en este caso ser un CMS, podemos resumir sus diferencias de la siguiente forma: Joomla busca ser un gestor sencillo, intuitivo y fácil de implementar mientras que Drupal sacrifica sencillez a cambio de una flexibilidad y posibilidad de ampliación infititamente superior a la de su homólogo.

Y en este punto nos encontramos, a lo largo de los años me he encontrado ya con demasiados proyectos que han sufrido el mismo problema, lo que los anglosajones definen como “hit the wall” al utilizar Joomla: una mala planificación incita al uso de este gestor pensando en “lo bonito que es” y lo “fácil que resulta utilizarlo”. La pesadilla ocurre cuando se intenta ampliar la funcionalidad de la página y empiezan los dolores de cabeza: limitaciones en la lógica de tratamiento de los datos, limitaciones en las modificaciones visuales… resulta que lo que en un principio parecía sencillo se vuelve en contra del usuario.

Es fácil encontrar ejemplos, entre ellos los que tengo más cercanos ahora mismo: en Joomla entras en el administrador, creas tus secciones y categorías y publicas contenidos. A partir de ese momento ya tienes el portal. Por un momento pensemos que queremos definir taxonomías (por ejemplo varios árboles de categorización), distintos tipos de contenidos, vistas personalizadas… paremos de contar, con Joomla es “casi” imposible, y digo casi porque existir, existen módulos que intentan crear esa funcionalidad… aunque sin demasiado éxito por el momento.

Este resulta ser un grave problema que deja muy tocado al proyecto, y además es una “enfermedad” que se repite constantemente. Son proyectos que en un inicio buscan tener un coste menor y con un periodo de desarrollo más corto… pero que en algún momento de su vida por su crecimiento necesitan incorporar nuevas funcionalidades, y ahí se acabó lo bueno.

Sin embargo, no vayamos a pensar que Drupal es la panacea y que el uso de Joomla es un error en todos los casos. Drupal no es intuitivo, ni para el usuario ni para el desarrollador. Necesita mucho más trabajo que Joomla para crear un portal “comestible”, algo que los usuarios y editores puedan utilizar sin problemas… y eso por supuesto implica tiempo y dinero. Es bastante lógico que se dé esta situación si pensamos que Drupal intenta no poner limitaciones de ningún tipo al desarrollo de un proyecto con el fin de que pueda ser ampliado sin encontrarse con paredes que impidan la creación de funcionalidades.

¿Entonces qué hacemos? Respuesta rápida: pararse a pensar. Respuesta larga: analizar correctamente las necesidades actuales y la previsión de las necesidades en un futuro medio (1-2 años). Si tenemos claro que el portal no va a cambiar, que sólo mostraremos contenidos con una categorización simple, que no querremos incluir funcionalidades más allá de lo que los módulos pueden hacer y que no resultará un problema encontrarse con limitaciones, Joomla es la respuesta: saldrá más barato y se tendrá en menos tiempo.

Si no tenemos claro que lo anterior se vaya a cumplir, mi consejo será el de utilizar Drupal. Si, el desarrollo será sensiblemente más caro (aunque sólo sensiblemente), y a cambio de sacrificar un poco de usabilidad, en el futuro nos habrá salido más rentable. ¿Rentable? Si, ya son unos cuantos los proyectos que he visto en los que después de pocos meses hay que “tirar” la plataforma Joomla y volver a hacer el desarrollo en Drupal, incluyendo los costes de la migración de todos los contenidos.