Les réseaux sociaux sont devenus totalement incontournables. Est-ce un bien, est-ce un mal ? Difficile de juger, mais leur intégration dans les sites web, quels qu'ils soient, est devenu inévitable. Echanger des informations concernant son site avec Facebook et Google+ ne peut plus être ignoré des webmasters. A tel point que Facebook, toujours à la pointe de ce genre d'ouverture a diffusé en 2010 une API pour ce faire : Open Graph. Comme toute API, celle-ci a ses règles, les ignorer ou pour le moins ne pas connaître leurs grands principes conduit à des fonctionnements... étranges. Dans cet article, vous allez apprendre à ajouter des meta-tags à vos articles afin que Facebook et consors sachent plus précisément ce que vous souhaitez mettre en avant. Avant d'aller plus loin avec Open Graph, commençons par un petit tour d'horizon de ce que l'on peut faire avec Joomla! sans (gros) effort.

I - A quoi sert une API ?

Et d'abord qu'est-ce qu'une API ? API acronyme pour Application Programming Interface, désigne un ensemble de méthodes et de propriétés par lesquelles une application offre ses services à une autre application en normalisant les échanges entre elles deux. Grossièrement c'est une bibliothèque de fonctionnalités permettant à un logiciel d'étendre ses possibilités en utilisant les services de l'autre application qu'il intègre alors.

L'API Open Graph de Facebook se trouve derrière tous les échanges existants : qu'il s'agisse d'installer un bouton 'Like' ou un bouton 'Recommander' ou 'Partager', il faut bien être conscient que derrière chacun de ces boutons, c'est l'API de Facebook qui fait le travail. Le protocole mis en place par cette interface programmatique a pour objectif de permettre l'interaction d'un objet (client) avec un profil Facebook et au passage, ne nous leurrons pas, de stocker les informations comportementales qui en découlent.

Pour atteindre cet objectif, le protocole définit un ensemble de données structurées sous forme de metadatas dans les pages clientes. Comme l'API est une API de bas niveau HTTP, l'interfaçage avec les pages Web est naturel. Il se pose comme une interface entre le graphe social de Facebook et l'objet page Web vu comme un composant de ce graphe. Dès lors, demander des informations, ajouter des commentaires ou télécharger des images devient une pratique naturelle puisque par la magie de l'API votre page Web est intégrée dans Facebook par l'intermédiaire d'un identifiant unique, l'identifiant Facebook bien entendu.

Notre objectif personnel dans un site Joomla! sera plus raisonnable, mais également plus immédiat et directement visible.

II - Comment ça marche ?

Plutôt que de décrire sèchement la litanie des propriétés et attributs mis en place par l'API, nous allons regarder dans la pratique comment se passe un échange simple. Si vous ouvrez votre page Facebook personnelle et que dans cette page vous souhaitez présenter votre site web, il vous suffit de saisir l'URL de ce site (la page d'accueil ou n'importe quelle autre page) voire plus simplement de le copier / coller :

Dès lors démarre une cinématique simple et efficace. Facebook (ou l'application sociale utilisant Open Graph, Google+ suit le même schéma opérationnel, de même que Twitter et des tas d'autres, puisque, rappelez-vous, c'est l'API Open Graph qui fait le principal du travail) :

1. Lecture de la source HTML de la page web, exactement comme le ferait le parser Google, celui de Bing ou tout autre, mais au lieu de chercher des liens vers d'autres pages ou d'autres sites, l'API va chercher les propriétés Open Graph potentiellement disponibles dans votre page et contenues dans des balises <meta>.
2. Chaque balise <meta> contient une paire d'information de type nom - valeur. Le nom est contenu dans l'attribut property et commence par 'og:' (syntaxe habituelle des langages modernes introduisant une notion de namespace 'espace de nommage'), en l'occurrence 'og' pour 'Open Graph', et d'une valeur dans l'attribut content.
3. Lorsque l'API Open Graph rencontre des balises <meta> du bon namespace, elle en lit le contenu. Les attributs 'property' recherchés à ce niveau sont :
   • title : le titre pour l'article dans l'application sociale
   • >type : le type d'élément à insérer  (article, video.movie, music.song, music.album ...)
   • site_name : le nom du site web d'origine
   • image :  l'url de l'image, mais il peut y avoir des sous-propriétés (og:image:width, og:image:type etc.)
   • author : l'auteur (seulement pour les types og:article ou og:book)
   • description : la description (résumé en une ou deux phrases) du contenu (tous types). Attention en français au piège de l'apostrophe qui 'casse' la syntaxe de la balise.
   • locale : la langue d'origine (fr-FR) ou secondaire (og:locale:alternate)
   • app_id : l'identifiant Facebook (seulement si l'application cliente est Facebook)
4. Les propriétés 'content' trouvées sont analysées et reconnues valides ou non valides (syntaxe incorrecte, hors-champ, valeur invalide ou non définie, données erronées ou non utilisables etc.).
5. Si les propriétés n'ont pas été trouvées ou que leur contenu est estimé incorrect, l'application sociale va essayer, via l'API, de les générer à partir du contenu de votre page web, en examinant la source HTML. En ce qui concerne les propriétés og:title et og:description, c'est assez simple, elles ont déjà un équivalent HTTP par défaut. Certaines ne sont pas du tout générées automatiquement (og:author, og:locale, og:site_name), alors que l'information existe dans la page source. Là où les choses se gâtent en général, c'est pour la propriété og:image. Les applications sociales ayant une routine de recherche pas forcément très naturelle. Facebook, par exemple, recherche en priorité des images de format carré (largeur = hauteur) et dont les dimensions sont à minima de 200px x 200px. Si l'application n'en trouve pas ou en trouve plusieurs, les choses ont tendance à échapper au prescripteur. C'est une des raisons pour lesquelles, le résultat surprend parfois le webmaster.

Dans le cas d'un lien saisi dans votre page Facebook, la clé d'identification (identifiant Facebook) est facile à trouver et pour cause! Lorsque l'action démarre de votre site web, il devient obligatoire de la renseigner et la renseigner sous la forme d'ID Facebook, les possesseurs de page Facebook se connectant avec une vanity id (souvent sous la forme prenom.nom), devront rechercher le véritable identifiant en utilisant par exemple l'URL outil :  https://graph.facebook.com/prenom.nom

III - Comment faire

Nous l'avons vu, les propriétés décrivant votre page web vis à vis de l'Open Graph sont contenues dans des balises <meta>, on obtient, dans un cas opérationnel, quelque chose comme ceci :

 <meta property='og:title' content='Présentation'>
 <meta property='og:type' content='article'>
 <meta property='og:image' content='http://www.guerrier-celeste.fr/images/cwopengraph/1.jpg'>
 <meta property='og:url' content='http://www.guerrier-celeste.fr/guilde-guerrier-celeste/la-guilde.html'>
 <meta property='og:site_name' content='Guerrier Celeste'>
 <meta property='og:description' content='La guilde "Guerrier Celeste" présentation et offre de service...'>
 <meta property='fb:app_id' content='168298920099999'>

Qui dit balises <meta>, dit écriture des dites balises dans la section <head> de la page web.

Hélas, c'est une partie quasiment interdite au webmaster Joomla!. Que nous reste-t-il alors comme solutions ?

Le tour est assez vite fait, si l'on élimine un développement de code PHP spécifique, il ne reste que deux possibilités :

IIIa - Processus semi-manuel

Utiliser un composant permettant de créer des balises <meta> et pas seulement pour Open Graph :
Les plus efficaces, à mon sens, sont d'une part Sourcerer de noNumber, mais également Tag Meta de selfGet qui présentent tous les deux des facilités pour générer une écriture de balises <meta> dans la partie inaccessible d'une page web, y compris à partir de leur version gratuite. A proprement parlé, Sourcerer peut faire bien davantage que Tag Meta orienté spécifiquement écriture de balises <meta>. Avec Sourcerer on peut coder la présentation précédente dans l'éditeur JCE (tinyMCE doit aussi faire l'affaire) :

Attention à bien respecter la syntaxe et à ne modifier et corriger le texte que dans la partie wysiwyg de l'éditeur, sous peine de voir vos modifications disparaître du fait du contrôle syntaxique de JCE lors de la bascule Editeur / Code Source et retour.

Cela fonctionne parfaitement et permet de résoudre simplement et pour pas cher des situations délicates. Défaut de la solution : il faut saisir manuellement les balises <meta> pour chacune des pages, plus exactement pour chacun des articles de votre site et cela ne peut pas (aisément) fonctionner pour une page d'accueil de type blog des articles en vedette, ou pour des pages du type liste des articles archivés etc.

IIIb - Utiliser une extension

Il faut reconnaître que des solutions complètes gérant l'automatisation de l'implémentation d'Open Graph existent en assez grand nombre pour Joomla! depuis quelques temps et les dernières parues sont particulièrement complètes et efficaces. Quelques-unes sont même tout bonnement excellentes. Parmi celles que je retiendrai, figurent :

• Coala Web Social Links, qui est le composant que je préfère, très complet (trop peut-être ?) dans son implémentation de l'Open Graph. Il apporte notamment une approche originale en ce qui concerne la génération (automatique) des balises <meta> et notamment de la propriété og:image, une implémentation complète de 'Like Box', 'Share', 'Follow' (lire : J'aime, Partager et Nous Suivre) avec une grande quantité d'options et d'applications sociales cibles. A noter que ce composant est payant.
• Open Graph Protocol de Joomla Kave (également payant) est plus complet en ce qui concerne l'intégration d'extensions tierces, là où Coala Web Social Links n'intègre que K2 et Zoo, Joomla Kave intègre également Virtuemart, Flexicontent et quelques autres. L'implémentation d'Open Graph semble convaincante, mais les fonctionnalités de type Like Box, Share et autres objets Facebook sont absentes.

Il existe une quantité d'extensions proposant tout ou partie du service requis. Je me suis borné dans mon choix aux extensions disponibles en français ou en anglais et présentant une version compatible Joomla! 3+.

IV - Et quand ça part en vrille ?

Nous le savons tous, une chance sur mille que ça ne se passe pas bien, ça se produit 99 fois sur cent, il faut donc des solutions de replis ou en tout cas des moyens de comprendre ce qui ne va pas. De ce côté, il faut reconnaître que Facebook a mis les moyens pour fournir aux développeurs les outils requis pour s'interfacer avec son réseau social, du coup Google+, Twitter et les autres se sont mis au même rang.

Débugger un hyperlien se passe en douceur et facilement.

Pour Facebook, il existe linter qui présente le résultat et les étapes qui y mènent, pour chaque erreur rencontrée, un diagnostic détaillé (pas toujours clair, il faut bien le reconnaître, une apostrophe au milieu de la donnée og:description va casser celle-ci, mais c'est pour autant la meta suivante qui sera souvent diagnostiquée en erreur. Cas classique des analyseurs de syntaxe).

Google+ utilise également linter, Twitter lui dispose d'un outil original mais plus complexe et moins précis lorsque les choses dérapent quelque peu : http://iframely.com/debug

Tous mettent à disposition des exemples de code, des générateurs de widgets, votre participation à leur réseau les intéresse, que voulez-vous ! C'est aussi la raison pour laquelle tous ont mis pléthore d'outils complémentaires à votre disposition pour intégrer votre site web dans leur réseau social et leur réseau social dans votre site web. Tout est en tout et inversement ...

Cette pléthore d'outils, c'est une autre histoire... à suivre.