Avatares. Dando cariño al plugin de Wordpress GNU Social

El viernes hablé de cómo he incorporado al blog el sistema de comentarios distibuido de WordPress GNU Social con el plugin creado por Manuel de Las indias.

Vengo siguiendo el proyecto desde que se anunció la idea y conversando con Manuel y David acerca de ideas sobre cómo gestionar algunas cosas en el plugin. Esta semana, mientras hacía pruebas antes de incorporarlo al blog, le comenté a Manuel que tenía una idea sobre cómo mejorar la gestión de avatares que se estaba haciendo. Manuel, como buen hacker que es, contestó que le parecía bien, pero me tiró la caña para ver si yo me animaba a hacerlo. Yo dije que sí y la verdad es que ha sido muy divertido.

Nunca había trabajado en el desarrollo de un plugin para WordPress. Sí que había desarrollado temas personalidados pero nunca una linea de código para un plugin y este además presentaba algunos retos como la interacción con el API de GNU  Social o la necesidad de mantener compatibilidad con las primeras versiones del plugin e instalaciones ya existenes.

El escenario previo

Manuel tuvo una gran idea sobre cómo tener almacenada la imagen a mostrar de cada usuario. Hasta ahora en el campo de email del autor del comentario, se almacenaba la url que GNU Social da como avatar a mostrar para ese usuario.

Es una solución ingeniosa, la verdad, pero presentaba varios problemas que los indianos ya habían detectado. A veces cuatro ojos ven más que dos y es parte de la magia del Software Libre así que cuando cuando se me ocurrió cómo solucionar este tema nos pusimos manos a la obra y durante la tarde / noche del sábado hice las modificaciones.

¿Por qué el cambio?

Almacenar una url concreta era depender de que esa imagen esté siempre ahí, lo que puede no ser así por multiples razones.

La primera y más sencilla es simplemente que el nodo al que referencia no nos la pueda entregar. Bien porque el nodo está caído, la imagen ya no esté almacenada, el nodo se haya desmantelado, errores en la red, etc. Eso nos podría dejar con un montón de enlaces con respuestas 404.

La segunda es que, aunque la imagen esté disponible para siempre, el usuario queda atadao, para esos comentarios, a la imagen de avatar que seleccionó en ese momento y eso si bien no es realmente un problema, no es lo más deseable.

Es sobre estos detalles que nace la idea del cambio.

Almacenado usuarios en vez archivos

El primer cambio a realizar es cambiar el almacenamiento de urls concretas de imagenes por el usuario que ha realizado el comentario. Por suerte para nosotros además, la manera en que se referencia a un usuario en GNU Social tiene el formato usuario@nodognusocial.com,   que tiene un formato igual al de un email y esto nos facilita mucho la tarea. De esta manera, almacenando esto en el campo del email, en la fase de pintado de los comentarios, podemos separar ese formato y tenemos disponibles el “nombre” de usuario y el node donde ese usuario está registrado.

Rescatando imágenes

Si no tenemos ni queremos tener almacenadas esas urls de las imágenes de los usuarios, tenemos que solicitarlas en tiempo de mostrar la página al nodo del usuario correspondiente. Para ello atacamos al nodo, solicitando en cada petición la imagen que ese usuario tiene en el momento actual como avatar por defecto. Es algo similar a lo que WordPress hace cuando rescata los avatares de sistemas como Gravatar.

Técnicamente, como tenemos que hacer peticiones a otros servidores desde dentro del plugin, utilizamos funciones de WordPress como wpremoterequest para evitar usar otras soluciones como cURL y mantener todo más integrado en WP y utilizando las herramientas que nos proporciona. Todas las instalaciones de GNU Social tienen un API de tipo REST a la que se pueden hacer consultas y algunas de ellas, como la que nosotros hacemos solo traen datos públicos, por lo que se pueden hacer sin necesidad de usuario y contraseña.

Con esa respuesta, obtenemos en tiempo de pintado la url de la imagen a mostrar para cada usuario.

Me encontré con el asunto de que por supuesto, cada usuario puede y suele tener más de un comentario en cada post y no queremos que esta solicitud al nodo se haga más de una vez para cada página. Es innecesario, retrasaría el tiempo de respuesta de la página y multiplicaría las solicitudes a cada nodo. No es algo brutal que ni que supondría segundos, pero en web, se trata de reducir todo este tipo de ineficiencias para reducir los tiempos del usuario al máximo.

Para solucionar esto, para cada usuario que vamos a mostrar, consultamos si antes hemos guardado ese valor de url en la caché de WordPress a través de wpcacheget, parte de una colección de funciones que WP nos dá para optimizar petciciones trabajando con caché. De esta manera, si ya tenemos el dato, saltamos la petición y procedemos al pintado. Si no, hacemos la petición al nodo y cuando responde, guardamos en caché con wpcacheset y seguimos. Si el usuario se vuelve a repetir en la misma página, ya lo tendríamos y no necesitamos solicitar de nuevo, volveríamos al primer caso explicado.

Retrocompatibilidad

Para mí una de las cosas más bonitas de lo que hemos logrado al hacer el cambio en el plugin es no romper la compatibilidad con todos los comentarios que se han creado con la primera versión del plugin.

Como mínimo en Las indias ya llevan unos cuantos posts con el sistema y no queríamos dejar esos comentarios con imagenes erroneas, ni siquiera con las antiguas, parte del reto era hacerlos igual de compatibles. Por no hablar de otros blog, incluso algunos que quizá ni sabemos si ya lo tienen instalado. Será transparente para el usuario y el autor del blog si se usó originalmente un sistema o el otro.

En caso de usuarios del sistema original, en lugar de tomar el nick del usuario, sacamos la id de usuario y la url de su nodo del campo commentauthorurl y hacemos las mismas peticiones que he explicado antes solo que basado en la id. Caché incluida.

Gestión de errores

En cualquier software pueden pasar cosas. En el nuestro, concretamente pueden pasar varias cosas.  Que el nodo o el usuario ya no existan o estén temporalemte fuera de linea, que existan pero falle el API o que algún dato que hubiese en el nombre de usuario haya sido modificado o mal guardado por la razón que sea en base de datos.

Pero lo bueno es que en ese caso, si cualquiera de esas situaciones se diese, tenemos al autor del blog cubierto. La gestión de errores para el sistema de avatares, en caso de fallo al obtener las imágenes del nodo, tampoco te dejaría con la página llena de errores 404. En lugar de la foto del usuario, mostramos una imagen por defecto. Pero no cualquiera, sino la que el usuario haya decidido configurar como avatar por defecto en los comentarios de su blog.

Siguientes pasos

Según dice Manuel, y estoy de acuerdo, parece que estamos listos para una versión 1.0 del plugin. Así que creo que lo siguiente, aunque él podrá hablar mejor de esto, será hacer los preparativos para incorporar el plugin al directorio de WordPress y quizá otras acciones para darlo a conocer.

Como dicen en Las indias, empiezan a alcanzar velocidad de crucero en el desarrolo con GNU Social y me alegro mucho de que estos pequeños cambios puedan abrir la puerta un poco más para ese futuro.

Pablo Bernardo
Pablo Bernardo

Hola, soy Pablo. Soy programador frontend, padre, estudiante de zen y otras cosas. Para saber más, lee algunas entradas.