COMO mostrar información adicional del autor de un nodo en Drupal

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:

Sobre el autor en Drupal 7

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.

Facebook construye un datacenter en Suecia

Facebook construye su nuevo datacenter en Suecia (The Reg via Global Guerrillas). Es curioso que el mismo Estado que permite la existencia de cosas como The Pirate Bay, sea el que permita a Facebook almacenar datos personales sin problema ninguno y, presumiblemente, servir datos con intercepción de tráfico à la Phorm, ya que allí no hace falta petición judicial para realizar este tipo de prácticas, en virtud de la ley aprobada en junio de 2008. Si aún usas Facebook, la solución pasa por dejar de usarlo. El problema es que a menudo no es suficiente.

Persiguiendo usuarios en la web

Estamos muy lejos de haber superado los problemas de privacidad que la Red nos planteaba hace unos años. No obstante, el camino para resolverlos pasa más por la toma del control de los actos (y datos) propios que por reformas faraónicas.

Facebook y el filo de la navaja
[Ilustración: Antonio Cerón.]

Entre las cookies de KISSmetrics y otras historias de naturaleza más o menos similar, últimamente no se habla de otra cosa que de lo muy vigilados que estamos cuando usamos la web. Aquí llevamos años comentándolo. En 2007 titulábamos «lo que el usuario no ve» en relación, precisamente al seguimiento de la actividad en la web. Poco tiempo después llegó Beacon, ¿lo recuerdan?.

Aunque se retractaron de Beacon, en Facebook no se conforman. Por ello, no les basta con seguir tu actividad incluso cuando estás deslogueado, quieren ser los únicos que puedan hacerlo. Por eso quieren patentarlo. La patente tiene por nombre Communicating Information in a Social Network System about Activities from Another Domain y el resumen de la misma es:

In one embodiment, a method is described for tracking information about the activities of users of a social networking system while on another domain. The method includes maintaining a profile for each of one or more users of the social networking system, each profile identifying a connection to one or more other users of the social networking system and including information about the user. The method additionally includes receiving one or more communications from a third-party website having a different domain than the social network system, each message communicating an action taken by a user of the social networking system on the thirdparty website. The method additionally includes logging the actions taken on the third-party website in the social networking system, each logged action including information about the action. The method further includes correlating the logged actions with one or more advertisements presented to the one or more users on the third-party website as well as correlating the logged actions with a user of the social networking system.

Suplantar la red no es suficiente. Si eres avispado y, percibiendo el scam, decides salir corriendo y no pisar sus dominios, te alcanzarán igual. «Podrás correr, pero no esconderte», confesó un apócrifo Zuckerberg antes de soltar una risita nerviosa, incómoda, como si estuviera ocultando las manos entre sus pantalones y una guía de teléfonos a la que piensa exprimir.

Y, entre tanto, seguimos con el bullshitting en torno a las métricas de lo emotivo. Y ahí tenemos a Klout, lo más in entre los community managers (by Fanta), que sin embargo comienza a recibir críticas crecientes por el poco respeto que guarda hacia los usuarios, de los que recopila datos aunque éstos nunca se hayan registrado en Klout. Parece lógico: Klout recopila datos públicos y demás… el problema es que hacer opt-out de su sistema es, en la práctica, inviable porque Klout no accede a ello.

Ni accede ni podrás saber nunca si accedieron. Ya me dirás cómo puedes estar seguro de que se borran los registros vinculados a un usuario si no tienes acceso directo a la base de datos (ni te lo dejarán tener).

Ante esta situación, lo único que queda es ser prudente. No poner en Internet aquello que no pondrías en una postal y hacerse cargo de que todo lo que pongas en una web, incluso eso que supuestamente es privado o tiene accesos restringidos, es público. Information wants to be free, decíamos hace años. Nada ha cambiado: es la naturaleza de la Red, los datos vuelan y se escurren como agua entre los dedos.

¿Hay alternativas a la persecución de Facebook y similares? Seguramente sea complicado pues hace falta que quienes administran páginas web opten por no usar Connect ni demás sistemas, y éstos no paran de crecer en adopción. Últimamente no me quito de la cabeza un verso de los cuatro cuartetos de T.S. Eliot: «Espera sin esperanza, porque la esperanza sería esperanza por lo equivocado».

Sin embargo, no lo aplicaré. Hay esperanza, y no está a la espera; hay una Red en la que somos más dueños de nuestra presencia, siempre la hay. Pero de eso hablamos mañana.

Cifrado y traducciones

«Uno se pregunta de forma natural si el problema de la traducción podría concebirse y tratarse como un problema de criptografía. Cuando miro a un artículo en ruso, siempre digo: «esto está realmente escrito en inglés, pero ha sido codificado usando símbolos extraños. Ahora procederé a decodificarlo».»

Norbert Wiener, citado en el New York Times.

El artículo (How revolutionary tools cracked a 1700s code) explica una noción que desconocía, pese a que no es nada nuevo (tiene décadas ya): la de aplicar técnicas de ruptura de códigos a la traducción. Como digo, nada nuevo pese a que yo no hubiera oido hablar de ello. Google Translate está desarrollado con esta lógica. Eso sí, yo prefiero usar cifrado a criptografía.

¿Qué le pedirías a un lector de feeds?

¿Qué le pedirías a un lector RSS?

Durante mucho tiempo (quizá demasiado) he sido usuario de Google Reader. Desde 2005 he leído ahí más de 240.000 posts, y eso que durante casi 3 años salí de ahí (primero volví a Bloglines, ya muy muerto, y luego intenté todo tipo de clientes libres en el escritorio y la web). 240.000 son muchos posts.

Bien, lo primero y lo principal que yo pido a un lector de feeds es que sea libre, que además de leer feeds me permita organizar bien la información que me interese conservar para futuras referencias y que funcione razonablemente bien. Seguro que se pueden pedir más cosas, no dudéis en comentar, que este post promete tener consecuencias ;)

Durante mucho tiempo usé todo tipo de lectores, hace unos 3 años que volví a Google Reader y ahí sigo. Sin embargo, hace unos meses que venimos trabajando en alternativas reales al mismo. Los cambios que Google planea introducir en su servicio son, evidentemente, un incentivo a llevar a cabo nuestro plan cuanto antes.

Para que quede claro, hace unas semanas (bastante antes del anuncio de rediseño), en un interesante post en ¿Quién vigila al vigilante? salí con mi pequeña teoría acerca de los lectores RSS libres. Completándola, que para eso esto es un post escrito con algo más de calma, tenemos que:

  1. Los lectores RSS han de ser online (contra lo que se podía pensar hace años, no se usan para leer noticias offline, sino para leer noticias sin consumir tiempo yendo a cargar páginas). Tenerlos online facilita enormemente su acceso/sincronización desde distintos equipos.
  2. El problema de los lectores RSS online domésticos: al ir haciendo fetch de más y más feeds durante un tiempo prolongado, el rendimiento del sistema cae mucho. La base de datos crece hasta límites insospechados y ralentiza la respuesta al realizar búsquedas de enlaces que recuerdas haber leído. Aquí la infraestructura de Google juega todo su valor, convirtiendo su performance en uno de los puntos fuertes de Reader).
  3. De facto, te obligan a elegir entre tener una aplicación lenta o vaciar la cache de posts/feeds guardados, con lo que pierdes enlaces que tuvieras etiquetados especialmente.
  4. La solución pasa por integrar algunas funciones de RSS Lounge (¡en el que funcionan nuestras amadas J y K!) con otras de SemanticScuttle, añadiendo las que entre ambos sistemas no nos proveen que sí tienen otros lectores de Feeds online.
  5. La función estrella será la de recibir en tu instancia de la aplicación los posts que te compartan, desde su propia instancia (vale, también desde la tuya, que el software será multiusuario) tus amigos. Con tal de que tú quieras leer lo que él comparte y él te dé permisos (digamos, a través de OAuth o OpenID). Esto haría de la aplicación algo no solamente libre, sino totalmente distribuido.
  6. Tendremos un lector de Feeds en el cual los posts que etiquetemos (más allá de la etiqueta genérica del feed) se guardarán automáticamente como posts destacados. Si gestionas y estructuras bien la información que vas obteniendo durante tus sesiones de lectura, adquiriendo el hábito de etiquetar todo lo que te gusta, cuando flushees tu cache ésta vaciará los últimos posts recibidos por el lector, pero no borrará tus marcadores.
  7. ¿Es posible que un sistema así sea más sostenible en el tiempo? Yo creo que sí, que es posible tener un sistema que nos permita leer feeds en nuestro propio servidor, recibir recomendaciones de nuestros amigos desde su propio servidor y, todo ello, sin perder calidad en el tiempo de respuesta de nuestra aplicación.

La idea es desarrollar un sistema que permita leer feeds cómodamente, en un marco donde lo importante es el contenido y no la marca del que te da acceso al servicio. Y, por supuesto, superar las debilidades de clientes libres como Tiny Tiny RSS o RSS Lounge. Es que ni siquiera clientes de escritorio como Liferea o RSS Owl funcionan bien (hay que jugar a poner números primos en todas las carpetas de feeds para que coincidan sólo cada mil quinientos años –más o menos–, y aún así se atascan de forma irritante).

Bueno, ésa es mi pequeña propuesta. Y tiene nombre, se llama Río y hasta ahora sólo la conocían personas como Eva o Juantomás, que son tan entusiastas como nosotros. Hemos comenzado su desarrollo (este post cuenta las conclusiones básicas que tenemos hasta ahora sobre qué queremos conseguir, dando una idea de qué puntos de partida tenemos y qué nos falta). Sabemos que la idea es buena, pero nos gustaría saber qué le falta, qué le pondríais o le quitaríais.

Y claro, necesitamos fondos para poder echarle al proyecto más ratos con más regularidad. En este momento estamos buscando sponsors pero ya sabemos que el software libre tiene menos apoyos de los que nos gustaría. ¿Qué te parece la idea? ¿Apoyarías un desarrollo como éste?

ONO aún bloqueando el p2p, ¿sorpresa?

Leía el otro día, pero no tuve tiempo para comentarlo, la noticia y dudaba si sorprenderme por la noticia en si o por el hecho de que la noticia fuera eso, noticia. El test para verificar la calidad de la conexión ofrecida por diferentes ISP que Google puse a disposición de los usuarios permite diagnosticar que varios ISP de los que más cuota de usuarios tienen bloquean sistemáticamente el p2p. Lo veíamos en Banda Ancha.

A la cabeza de todo, ONO. Yo ya me olvidé de ONO, salí de ahí para nunca arrepentirme de ello, tras mucho tiempo con un servicio mejorable, cada vez más caro, y el repetido esfuerzo de ONO mantener el número de atención al cliente oculto de toda luz.

La última que hablamos de ello fue en 2008, por un tema parecido al de hoy, por eso ya había olvidado lo mal que se pasa estando en ese ISP y no sabía si sorprenderme de que esa situación siga así o de que la misma, a estas alturas, sea noticia.

Por cierto, me sorprendió mucho ver a Jazztel en esa lista. Actualmente estoy con ellos y doy fe de que en ocasiones la conexión rinde incluso más de la velocidad que oficialmente tengo contratada y que los torrents suben y bajan sin que haya cap. ¿Cuál es vuestra experiencia con ISPs en Madrid? Como digo Jazztel va bien, pero no es el más económico. Se aceptan alternativas e ideas.

Google, SSL, seguridad y asimetría de la información

En las próximas semanas, Google habilitará el cifrado SSL para todas las conexiones con sus servidores que realice un usuario que haya iniciado sesión en los mismos. Indudablemente, es una buena noticia desde el punto de vista de la seguridad. Aquellos que quieran hacer búsquedas personales desde la oficina también salen ganando (¿estás pensando en dejar tu curro? Ahora será más difícil detectarte, a menos que trabajes en Google, claro). Pero ojo, con este movimiento Google limita la cantidad de información que entrega a webmasters que hasta ahora podían saber qué términos de búsqueda dirigían más tráfico a sus páginas, a la vez que se apoya en los usuarios logueados a los que sirve, además, búsquedas cada vez más fuertemente personalizadas. Dicen que estará disponible por otras vías, pero la realidad es que una conexión cifrada no transmite esa información y habilitando de forma masiva las conexiones SSL, Google amplía la asimetría de la información existente entre lo que ellos almacenan y lo que saben/sabemos los demás. Está claro que no dan puntá sin hilo.

Este blog usa cookies para su funcionamiento.    Más información
Privacidad