La mutualización de contenidos

Con SPIP 1.9, el sistema de mutualización (ver el artículo «Los ficheros backend») se enriqueció: de ahora en más es posible intercambiar documentos adjuntados a los artículos (podcasting), de transportar de un sitio al otro las palabras clave (tags) asociadas a un artículo como también su sección (o categoría). Se puede también, si se desea, mutualizar el contenido completo de los artículos.

En todo lo que se sigue, se consideró que el flujo de mutualización [1] ofrecido por el sitio fuente es suficientemente rico para tener previstas todas las posibilidades que ofrece en particular el esqueleto dist/backend.html de SPIP.

Referencia rápida del sitio

Se ubica en primer lugar la URL del flujo de mutualización en formato RSS (o Atom) del sitio que se quiere mutualizar. Según el caso, esta dirección es indicada directamente en la página, y o es «descubierta» automáticamente por el navegador, que muestra entonces un ícono característico. Si los esqueletos del sitio fuente lo preveen, SPIP 1.9 puede también descubrir está dirección de mutualización, y es suficiente con indicar la dirección del sitio que se propone sindicar.

Una vez activada la mutualziación, los artículos presentes dentro del flujo de mutualización del sitio fuente se ve dentro del sitio receptor.

Decidir lo que se va a emitir

El webmaster o la webmistress del sitio fuente puede decidir sobre que se mete dentro del flujo RSS : esta elección se puede hacer obviamente modificando el esqueleto dist/backend.html, o bien se puede inspirar para crear un nuevo flujo.

A su vez la página de configuración dentro del espacio privado propone una opción muy importante para la mutualización : esta permite decidir si el flujo RSS del sitio se compondrá de la totalidad de contenidos de los artículos, en formato HTML, o sólamente de un pequeño resumen (en formato de texto). En el primer caso (que es la configuración por defecto del sistema), los artículos recientes del sitio son completamente legibles con un lector RSS : son también enteramente «recopiables» de un sitio al otro. Esto permite por ejemplo realizar automáticamente sitios espejos, o sitios compuestos de contenidos producidos por otro sitios.

Decidir lo que se va a recuperar

Si el sitio fuente no difunde su contenido completo, es obvio que la mutualización no podrá recuperar más. Pero en caso de una difusión completa, SPIP puede recuperar el contenido HTML y mostrarlo, imágenes incluidas.

Sitio por sitio, se puede elegir que es lo que se va a recuperar mediante mutualización : el contenido HTML de los artículos (si está disponible) o un simple resumen en formato texto.

Se puede también decidir sobre lo que se hace con los artículos que desaparecen del flujo (que en general se limita a los 15 artículos más recientes del sitio) : se puede elegir que SPIP los elimine de la base de datos (después de un período de un mes), y/o los pase automáticamente a modo «rechazado». Estas últimas opciones permiten por ejemplo administrar portales de flujo muy rápido (agencias de noticias, tags muy populares de sitios de fotografía, etc); o alentar a mantener un espejo fiel de un sitio (eliminando los artículos que no son “despublicados”).

Decidir lo que se va a mostrar

-  la fuente:

De manera habitual, #NOM_SITE representa el nombre del sitio mutualizado, que es entonces la «fuente» del artículo. Dependiendo del desarrollo de los generadores de contenido (los portales por ejemplo), la verdadera fuente de contenido puede ser otro sitio. El formato RSS ha previsto este caso definiendo un campo <source> indicando la verdadera fuente del artículo. El motor de mutualización de SPIP recupera estos datos cuando ellos están presentes y las balizas #SOURCE y #URL_SOURCE permiten mostrar respectivamente el nombre y la dirección de la fuente.

-  los tags:

Si las palabras claves asociadas a los artículos se informan dentro del flujo RSS, son recuperadas por el sitio receptor ; no llegan individualmente a la tabla de palabras clave, pero son guardadas en grupo dentro del campo tags de la tabla spip_syndic_articles.

Si el flujo de la mutualización utiliza la notación estándar <dc:subject>Tag</dc:subject>, el tag es guardado tal cuál. SPIP va más allá con este concepto transmitiendo también la dirección de la página de las palabras clave, gracias a los microformatos. El tag se recupera entonces con su página, en la forma: <a rel="tag" href="dirección de la página de la palabra clave">Palabra clave</a>.

En el sitio destinatario, estos tags son mostrados dentro del espacio privado debajo de la descripción del artículo, y son mostrables en el sitio público gracias a la baliza #TAGS (se verá más adelante como filtrar puede hacer una vista selectiva de los tags).

Nota : SPIP previó una gestión específica de los tags provenientes de sitios del.icio.us (bookmarks colectivos), flickr (fotografía) y connotea (referencia de artículos científicos), de manera de poder asignarles un URL (que no está previsto dentro de sus flujos RSS respectivos).

-  la sección:

Dentro de las numerosas aplicaciones (sistemas de blogs, directorio de páginas...) la categoría (o simplemente directorio) de un artículo es equivalemente a lo que SPIP llama una sección. Es entonces natural usar la noción RSS estándar de <category>...</category> para dar a conocer la pertenencia de nuestro artículo a tal o cuál sección.

Lo mismo que con los tags, SPIP recupera esta información y la muestra mediante #TAGS.

-  los documentos adjuntos:

Los documentos que, en el espacio privado, aparecen debajo de la página de visualización de un artículo, o en la ección «Documentos» o, para las imágenes, en la sección «Portfolio», también se transmiten dentro del flujo RSS, utilizando la notación <enclosure .../>. Esto que se llama los podcasting, es en adelante una función estándar de SPIP [2].

La información sobre los enclosures es también recuperada dentro de la baliza #TAGS, aunque es mostrada de de manera diferenciada dentro del espacio privado, su forma es la de un pequeño trombón por cada archivos.

Usar la baliza #TAGS

Como se vio arriba, la baliza #TAGS muestra apilados los enlaces a las palabras clave, las secciones y los documentos adjuntos. Pero gracias a los microformatos, lo links de cada uno de destos conceptos son «marcados» de la manera siguiente :
-  <a rel="tag" ...> para los tags/palabras clave
-  <a rel="directory" ...> para las secciones/categorías
-  <a rel="enclosure" ...> para los documentos adjuntos/podcast

Si se quisiera mostrar solo un de estos tipos de tags, se utilizará el filtro afficher_tags precisando el tipo de salida en el argumento :

(Por defecto [(#TAGS|afficher_tags)] es equivalente a [(#TAGS|afficher_tags{'tag,directory'})].)

Para los documentos adjuntos, el filtro específico afficher_enclosures permite mostrar los trombones en vez de los links clásicos :

* * *

Alterar el contenido HTML de los artículos mutualizados

Caso práctico : nuestro sitio mutualiza un fotoblog, que publica sistemáticamente un pequeño comentario después de las fotos. Este último se muestra en forma de un tag HTML <img .../>. Una vez que este fotoblog se mutualizó en versión HTML complete dentro de nuestro sitio, podemos decidir mostrar la foto, sin el comentario. Debemos entonces extraer el tag <img /> ; esto se puede hacer gracias al filtro extraire_balise{xxx}, que recupera el primer tag HTML <xxx /> de un contenido.

A partir de esto todo es posible :
-  [(#DESCRIPTIF|extraire_balise{img})] muestra la foto;
-  [(#DESCRIPTIF|extraire_balise{img}|extraire_attribut{src})] su URL;
-  [(#DESCRIPTIF|extraire_balise{img}|extraire_attribut{width})] su largo;
-  se puede mismo modificar el estilo, por ejemplo :

[(#DESCRIPTIF|extraire_balise{img}|
        inserer_attribut{style,'border: double red 4px;'})]

Observación : los contenidos HTML provenientes de un sitio externo son por definición considerados como «no controlados», y por lo tanto potencialmente problemáticos si contienen tags mal formados, o javascript ; SPIP les aplica sistemáticamente el filtro safehtml antes de mostrarlos.

Otros filtros relacionados con la mutualización

Estos filtros permiten convertir los tags de mutualización de un formato en otro, con el fin de poder por ejemplo leyendo el formato RSS de los tags recuperados por mutualización, y registrados dentro de nuestra base de datos en formato de microformats : tags2dcsubject, enclosure2microformat, microformat2enclosure.

Referencias

-  RSS 2.0
-  microformats
-  rel=tag
-  rel=enclosure
-  rel=directory

Notas

[1Nota del traductor: se utilizó el término mutualización en vez de sindicación para mantener la consistencia con otros artículos que utilizan esta terminología. Tener en cuenta que en realidad mutualización y sindicación representan lo mismo: syndication

[2Observar que los archivos no son recopiados : solo sus URL y los datos asociados (título, tamaño, formato) son recuperados. Por otra parte se debe señalar, para los puristas, que se toma aquí alguna libertad con la norma RSS, que prohíbe normalmente tener varios enclosures en un mismo artículo.

Autor o autora Miguel Publicado el: Actualizado: 26/10/12

Traducciones: عربي, català, English, Español, français, italiano, Nederlands, Türkçe