Reunirse con un puñado de bloggers a hablar, redundante pero justificadamente, sobre blogs con una cerveza en la mano era una de las grandes cosas que ofrecía la emergente blogosfera de hace ya muchos años. Yo viví aquella época en Málaga, donde los beers and blogs se convirtieron en (buena) costumbre, de la mano de los Bloguerones. Llegado un momento, sin embargo, los B&B cayeron de intensidad, y no porque los blogs murieran; todo lo contrario: murieron de éxito, nos reuniamos demasiados y las quedadas dejaron de ser humanamente manejables.

Y es que, a partir de un cierto número de personas, tenías la sensación de no haber saludado a casi nadie y la solución lógica era quedar no con todos, sino con algunos de esos bloggers. Y punto. Todos hacían lo mismo y sin problemas. De ahí se precipitaba un nuevo status quo: quedabas naturalmente con algunas personas a las que conociste en los primigenios B&B, pero ya no los llamabas B&B, sino ir de tapas (o de cañas, o de concierto).

Llevo un par de meses sumándome a la quedada mensual de drupaleros en Madrid. No es secreto que soy un amante de Drupal y que parte de lo que hacemos habitualmente en Cartograf tiene que ver con este maravilloso framework, así que las conversaciones que ahí tienen lugar me devuelven algo interesante que no había encontrado desde aquellos primeros Beers & Blogs: la frescura de charlar con personas con quienes compartes una cierta afición, en este caso el obvio, en grupos reducidos y sin mayor aspiración (en ese corto plazo, que también se esbozan PDMs por si la cosa se prolonga) que la de echar un buen rato y tomar una caña.

En un blog, sobre todo si en él escribe más de un autor pero no sólo en esos casos, es importante que se sepa quién escribe cada post. Esto lo hacemos mostrando selectivamente una breve información sobre el autor del post en concreto, no sólo su nombre, sino algo más (contexto del autor: trayectoria, biografía, a qué se dedica, ...).

En Drupal es común que esto se aborde mediante la creación de un bloque usando Views, que luego incluye la info relativa al autor de cada post.

Esto tiene dos problemas.

• Uno técnico. El bloque aparecerá vacío cuando en vistas que no sean de un único nodo. Por ejemplo, en la página principal. «Pues indicamos que no aparezca en <front> y santas pascuas», estará pensando alguno. Parece sencillo pero tenemos tantas vistas en las que no queremos ese bloque (archivos, páginas de usuario, cualquier View de tipo página que muestre contenido agregado o especial, ... y podríamos seguir) que nunca estaremos seguros de haberlo filtrado bien.
• Otro de usabilidad. Pero no importa, for the sake of the argument, vamos a considerar que la primera vía fuera una buena solución técnica. En ese caso tenemos tres posibilidades: colocar el bloque justo antes del post, antes incluso del título del mismo. Colocarlo debajo del contenido principal o colocarlo en la sidebar, preferiblemente arriba del todo, en una ubicación preferente. Las tres son malas opciones: sobre el post porque da la mayor importancia de la página no al contenido de la misma sino al autor (en la mayoría de ocasiones no será lo que deseemos), bajo el contenido porque para ver ese bloque habrá que pasar primero por todos los comentarios que haya al mismo. Pueden ser muchos comentarios, y el bloque se perderá sin ser visto. Sobre la barra lateral es una situación intermedia, pero aún mejorable, pues más allá del nombre del autor, quizá el lector no quiere saber más de él antes de terminar el post y saber si el autor del mismo propone ideas interesantes. En ese caso, mejor aprovechar la barra lateral con los tradicionales botones de suscripción, mucho más importantes.

Entonces, ¿cuál es la ubicación idónea de esta información adicional sobre el autor de un nodo y cómo lo mostramos?

La ubicación
Lo idóneo es bajo el contenido del post y antes de los comentarios. En ese momento el lector ya ha leído el artículo y está preparado para recibir información adicional sobre el autor que le servirá para saber si buscar más ideas de este autor o descartarlo, o para contextualizar alguna afirmación arriesgada que el mismo haya podido hacer durante el artículo. Sólo después, con todo el contexto, el lector pasa a ver aportes de otros usuarios en comentarios. Evitamos distraerlo antes de que finalice su lectura, que es lo hacíamos poniendo esta información más arriba en la página.

La solución: cómo mostramos esta info
En Drupal 7 tenemos la ventaja de toda la flexibilidad que nos da el módulo Field, que ahora es parte del core y nos permite añadir campos con información adicional a casi cualquier aspecto que se nos ocurra.

1. En nuestro caso, añadiremos un campo adicional al perfil del usuario, con un nombre descriptivo, algo como bio y le decimos a Drupal que será un campo tipo Texto Largo con un elemento de control del tipo Área de texto (varias filas). El breadcrumb para añadir este campo al perfil del usuario es: Inicio » Administración » Configuración » Personas » Opciones de la cuenta, y ahí seleccionamos la pestaña Gestionar campos. La URL relativa es /admin/config/people/accounts/fields.
2. Una vez hemos añadido el campo, empezamos el cacharreo de verdad. Si queremos que este campo se muestre en todos los tipos de contenido, necesitaremos editar el archivo node.tpl.php de nuestra plantilla. Si, por el contrario, queremos que sólo afecte a un tipo de contenido editamos, o lo creamos si no existiera, el correspondiente archivo node--TIPODECONTENIDO.tpl.php, sustituyendo (obviamente) «TIPODECONTENIDO» por el nombre máquina de tu tipo de contenido. (Lo más común es que se trate de node--article.tpl.php.)
3. En ese archivo, justo debajo del render del contenido del post y antes de renderizar los comentarios añadimos estas líneas, asumiendo que el campo recién creado para la info del autor se llame bio:
   
<div class="autor-bio">
<?php print $user_picture; ?>
<?php
$autor = user_load($node->uid);
print ($autor->field_bio['und'][0]['value'])>
?>
</div>

   Estas líneas mostrarán una foto del autor del nodo y, adicionalmente, la información sobre él.

Un ejemplo del resultado lo tenemos en cualquier post del blog de Cartograf, pero aquí enseñamos una demostración:

Es posible que necesites vaciar la cache de tu Drupal para percibir los cambios y, claro, aún tendrás pendiente estilar bio la clase que hemos asignado a la capa, para que se vea verdaderamente bonito.

El resultado será exactamente el que queríamos, y exactamente el que da la información al visitante en el momento en que mejor le sirve. Y este post lo dejo aquí porque, ciertamente, estaba cansado ya de ver cómo la única solución que encuentras por ahí es la del bloque, muy simple y rápida pero también un tanto cutre. Así que ya que cociné ésta en un rato, la dejo aquí para la posteridad y para ahorrar sudores a todo aquel que necesite hacer algo similar.

Esta noche he modificado un poco la apariencia del blog para añadir una nueva región para bloques en Drupal al tema que venimos usando desde hace un tiempo. Es algo que tenía pendiente desde que migré el blog a la última versión de este CMS, pero no había hecho por falta de tiempo. Una vez añadida la nueva región instalé el HEAD de Tagadelic para Drupal 7, que funciona perfectamente, y el resultado de todo ello combinado lo tenemos en la nube de etiquetas que ahora abraza las dos columnas laterales del blog. Lo sé, se parece muchísimo a la que adornaba el blog cuando todavía usábamos Drupal 6, ¿esperaban otra cosa? Por cierto, debería verse bien en pantallas con un ancho mínimo de 1024 píxels, y algo peor si usas resoluciones menores. En todo caso, si ven algo raro o fuera de su sitio, les agradecería que me avisaran en comentarios; recompenso con una birra la próxima vez que nos veamos :)

La migración a Drupal 7 fue una tortura y me dejó algunas cosas rotas en el blog. Como están siendo semanas y meses de mucho ajetreo no tengo el tiempo que me gustaría para volver sobre estas cosas, pero hoy pude solucionar la que más me molestaba: los usuarios anónimos que dejáis comentarios volvéis a tener nombre. El problema era una asignación indebida en el módulo de AntiSpam que ignoraba toda información introducida por el usuario al rellenar el comentario. La solución estaba esperándome en Drupal.org. [Actualización (unos minutos después): arreglar ese problema con el módulo de antispam ha solucionado más errores que veníamos sufriendo (como el de la paginación de post más antiguos, que tenía parcheada de mala manera); adicionalmente, un pequeño error aparecido en Drupal 7.2 ya tiene parche también.]

No tengo palabras para contar lo que supone migrar de Drupal 6 a Drupal 7. Pensé que era algo tortuoso, pero no es así: es lo siguiente, mucho más terrorífico.

De entrada, aunque seguí a rajatabla las instrucciones del «update.txt», el proceso no funcionó. Un sistema inusable cuya migración automática tuve que deshacer para portar todas las tablas manualmente, usando queries de SQL. Lo expliqué en aquellos días en que pensé que la migración era una tortura.

El tema es que no tengo el tiempo que querría tener y una semana después sigo arrastrando algún que otro problema. De lo que ayer creí entender el problema aparece en algún momento cuando se dejan comentarios; motivo por el cual he aprovechado para cerrar comentarios en todos los hilos viejos... ciertamente hay post con varios años a los que sólo llegan paracaidistas, no es un problema.

El tema es que no falta quien me recomiende migrar a Wordpress. No sin cierta lógica: no me tengo por un tío demasiado listo, pero he usado este CMS desde hace 6 años, lo actualicé desde la versión 4 a la 5 y luego a la 6. Pero la migración a Drupal 7 es, sencillamente, infernal.

Es cierto que han reprogramado todo, que ahora el sistema es (aún) más modular y que, seguramente, sea más eficiente y cargue menos al servidor... o al menos lo hará cuando no arroje errores todo el rato. De lo que creo entender, los errores (que dejan inoperantes los feeds y en unos pocos días hace que también notes el tráfico desde buscadores) aparecerán tan pronto alguien deje un comentario en este post... Así que esto es un test que, de confirmar lo que de él se espera, me obligará a restaurar una copia de la base de datos que no da estos errores... y que no permite, por el momento y hasta que logre solventarlo, dejar comentarios. (Algo muy, muy molesto para los lectores y para mí.)

¿Por qué no hago caso a aquellos que dicen que me mude a Wordpress, que éste es el momento? Porque uno no se rinde cuando va perdiendo: cuando vamos cuesta abajo lo que toca es enfrentar la frustración, dar con el fallo, solucionarlo y entonces, sólo entonces, uno está preparado para migrar de sistema... con la cabeza alta.

Este es el primer post que os llega gracias a Drupal 7. Quedan cosas por pulir, no ha sido sencillo, pero gracias al gran trabajo de Nick Thompson ya estamos aquí. Si ven algo fuera de su lugar, hagan el favor de pasar por comentarios, les estaré muy agradecidos. Actualización (2-feb): Los comentarios anónimos se firman como Timidín pongamos el nombre que pongamos, pero la base de datos almacena los nombres; pronto volverán a tener nombre y caras. Segunda actualización (2-feb):: avanzo a pasitos porque noblesse obligue y tengo muchas cosas que hacer. Los comentarios están algo mejor (aún no muestra vuestros nombres, pero no os preocupéis), gracias a un post que me puso en la pista para arreglar las estadísticas (que arreglé vía mysql query); la lista de usuarios podría recuperarla (y la recuperaré) en cuanto tenga cómo rehashear las contraseñas (el algoritmo cambia de drupal 6 a drupal 7). Mientras tanto habrá que comentar sin loguearse. ¡Corto y cambio!

Drupal 7 lleva unas semanas en la calle. No planeaba migrarme, pero la curiosidad me puede y decidí ver el proceso con una copia. Sin embargo, siguiendo a rajatabla el proceso de migración descrito, no he conseguido que la misma funcione. Admito que sólo he hecho el intento y los parcheos que se me han ido ocurriendo, pero la verdad es que es acojonante que el proceso de actualización no esté depurado. Seguimos como siempre, en Drupal 6, claro.

Actualización con cosas que sé (28 de enero, 22:00): Borrando la tabla de bloques personalizados ("block_custom") y copiándola desde una instalación fresca de drupal7 podemos hacer login... y descubrir que los posts se han migrado pero ahora están vacíos. Pensé que se debía a que quizá el nuevo tema de Drupal 7 los estaba filtrando mal, pero al mirar dentro de ellos podemos ver que se han migrado, pero que efectivamente no tienen contenido. Sólo título y categorías.

Una maravilla la herramienta de migración.