Métas + est un plugin qui permet d’améliorer l’indexation de vos contenus dans les moteurs de recherche et leur affichage sur les réseaux sociaux grâce aux métadonnées Dublin Core, Open Graph et Twitter Card.
Voir l’article consacré à la version 1.
Évolutions
→ Cette version du plugin génére et insère automatiquement les métadonnées dans le <head> de vos pages, quelque soit le type d’objet éditorial.
Dans la majorité des cas, il suffit d’activer le plugin, et ça fonctionne : plus besoin de modifier les squelettes.
→ Quelques métadonnées ont été ajoutées ou mises à jour, notamment :
- Tous les auteurs sont présents au lieu d’un seul auparavant
- Les mots-clés sont présents
- Les dimensions des images ont été mises à jour pour correspondre aux dernières recommandations des réseaux sociaux, et leur titre est présent.
- 3 images sont sélectionnées pour Open Graph
- Le format « riche » est activé pour Open Graph / Facebook
→ Dans la configuration, on choisit les protocoles à activer plutôt que ceux à désactiver.
→ Côté intégration, le rangement des squelettes a été revu.
→ Pour SPIP 3.1+
Configuration
La page de configuration vous permet plusieurs choses :
- Choisir les protocoles à activer (attention dans la v1 c’était l’inverse : on choisissait ceux à désactiver)
- Utiliser le nom du site comme auteur des contenus.
- Utiliser une image personnalisée à a place du logo du site.
Accès aux images pour les robots d’indexation
Si les images sont absentes lors des partages, il est probable que les robots d’indexation ne parviennent pas à les récupérer.
Pour leur donner accès au répertoire qui stocke les images redimensionnées, surchargez le fichier robots.txt.html en ajoutant des règles.
Voici un exemple pour le robot de Twitter :
User-agent: Twitterbot
Disallow: /local/
Allow: /local/cache-gd2/
Allow: /local/cache-vignettes/Intégration & personnalisation
Le reste de cette documentation ne vous sera utile que si vous avez besoin de personnaliser les métadonnées lorsque la génération automatique ne convient pas.
Le plugin tente de récupérer toutes les informations pertinentes automatiquement (titre, description, etc.), ce qui devrait convenir la plupart du temps, mais il peut arriver que cela ne soit pas suffisant dans certains cas.
Il n’est par exemple pas possible de deviner le « type » exact de chaque contenu, c’est pourquoi on en indique un assez générique par défaut : « article » pour Open Graph, « Text » pour Dublin Core.
Mais il pourrait être utile d’indiquer le vrai type précis pour les nouveaux objets éditoriaux.
Dans ces cas, il faut créer des squelettes de variantes.
Organisation des squelettes et mécanisme de sélection
Les squelettes sont maintenant organisés ainsi (comparaison avant/après) :
| Chemin | Explication |
|---|---|
inclure/metasplus/dist.html |
Génère automatiquement les valeurs des métadonnées, puis les affiche en incluant le suivant. |
inclure/metasplus/inc-dist.html |
Affiche les métadonnées selon les valeurs qu’on lui transmet. |
inclure/metasplus/ {type-page}.html |
Variante spécifique à un type de page |
Pour chaque type de page, le plugin va chercher s’il existe un squelette spécifique inclure/metasplus/{type-page}.html, et à défaut il se rabat sur le squelette générique inclure/metasplus/dist.html qui produit automatiquement les métadonnées [1].
Si, pour un type de page précise, la génération automatique ne convient pas, il suffit de créer un squelette de variante.
Pour exclure certaines pages de l’insertion automatique, on peut les lister au moyen d’une constante à ajouter dans mes_options.php, ou bien créer des squelettes de variantes vides :
define('_METASPLUS_PAGES_EXCLUES', 'article,patate,pomme');Squelettes de variantes
Prenons l’exemple d’un hypothétique objet éditorial « livre », qui aurait plusieurs particularités :
- Le type par défaut ne convient pas.
- La date pertinente n’est pas celle de rédaction du contenu (
#DATE), mais celle de publication du livre (#DATE_PUBLICATION). - Les auteurs seraient différenciés au moyen du plugin Rôles d’auteurs (auteur, traducteur, relecteur, etc.), et nous souhaitons avoir les auteurs avec un rôle précis.
Dans ce cas, il faudrait un squelette de variante inclure/metasplus/livre.html.
Quant au contenu, vous avez plusieurs possibilités :
1) Inclure le squelette dist.html
En incluant ce squelette, vous ne tranmsettez que les valeurs que vous souhaitez modifier, celles non transmises seront générées automatiquement.
<BOUCLE_livres(LIVRES){id_livre}>
[(#REM) Récupérer les données à modifier ]
#SET{auteurs,#ARRAY}
<BOUCLE_auteurs(AUTEURS){id_livre}{role=ecrivain}>
#SET{auteurs,#GET{auteurs}|push{#NOM}}
</BOUCLE_auteurs>
[(#REM) Afficher les métadonnées ]
<INCLURE{fond=inclure/metasplus/dist,
og-type=book,
dc-type=PhysicalObject,
date=#DATE_PUBLICATION,
auteurs=#GET{auteurs},
} />
</BOUCLE_livre>2) Inclure le squelette inc-dist.html
Avec cette inclusion, vous devez transmettre toutes les valeurs, celles non transmises ne seront pas présentes.
<BOUCLE_livre(LIVRE){id_livre}>
[(#REM) Récupérer toutes les données ]
#SET{auteurs,#ARRAY}
<BOUCLE_auteurs(AUTEURS){id_livre}{role=ecrivain}>
#SET{auteurs,#GET{auteurs}|push{#NOM}}
</BOUCLE_auteurs>
<!-- Idem pour les mots-clés, les images, etc. -->
[(#REM) Afficher les métadonnées ]
<INCLURE{fond=inclure/metasplus/inc-dist,
og-type=book,
dc-type=PhysicalObject,
titre=#TITRE,
url=#URL_LIVRE,
desc=#DESCRIPTIF,
lang=#LANG,
date=#DATE_PUBLICATION,
maj=#MAJ,
auteurs=#GET{auteurs},
mots=…,
logos=…,
} />
</BOUCLE_livre>3) Tout faire à la main
Et vous pouvez bien sûr tout faire vous même, si par exemple vous avez besoin d’ajouter des metadonnées qui ne sont prises en compte dans les squelettes génériques.
Paramètres
Voici la liste de tous les paramètres pris en compte.
Les nouveaux sont signalés avec une astérisque*, ceux obsolètes sont barrés.
| Paramètre | Explication |
|---|---|
titre |
Titre de la ressource |
desc |
Description de la ressource |
url |
URL absolue de la ressource |
date |
Date de publication |
maj |
Date de dernière modification |
lang |
Code de langue en 2 lettres : fr |
territoire |
2 lettres pour compléter la langue afin de créer la locale : en_US par ex. |
og-type |
Type de ressource Open Graph |
dc-type |
Type de ressource Dublin Core |
mots* |
Soit un tableau linéaire : |
| Soit une liste de mots-clés séparés par des virgules | |
auteurs
|
Soit un tableau linéraire : |
| Soit une liste de noms séparés par des virgules | |
logos
|
Soit un tableau de tableaux associatifs contenant l’URL et le texte alternatif de chaque image : |
Soit une liste d’URLs séparées par des virgules : |
Métadonnées générées
Voici un exemple complet des métadonnées générées pour un article.
<!-- Plugin Métas + -->
<!-- Dublin Core -->
<meta name="DC.Format" content="text/html">
<meta name="DC.Type" content="Text">
<meta name="DC.Language" scheme="rfc1766" content="fr">
<meta name="DC.Title" lang="fr" content="Omnis quia quo cum eaque – Lorem ipsum">
<meta name="DC.Description.Abstract" lang="fr" content="Sapiente totam quo ut fugiat pariatur voluptatum nihil nulla. Ratione culpa consectetur quo quasi est enim autem repellat,…">
<meta name="DC.Date" scheme="DCTERMS.W3CDTF" content="2018-05-08">
<meta name="DC.Date.Modified" scheme="DCTERMS.W3CDTF" content="2018-05-09">
<meta name="DC.Identifier" scheme="URI" content="https://www.monjolisite.ltd/lorem-ipsum">
<meta name="DC.Publisher" content="Lorem ipsum">
<meta name="DC.Source" scheme="URI" content="https://www.monjolisite.ltd">
<meta name="DC.Creator" content="Lorem Ipsum">
<meta name="DC.Creator" content="Tempus Fugit">
<meta name="DC.Subject" content="Lorem">
<meta name="DC.Subject" content="Ipsum">
<!-- Open Graph -->
<meta property="og:rich_attachment" content="true">
<meta property="og:site_name" content="Lorem ipsum">
<meta property="og:type" content="article">
<meta property="og:title" content="Omnis quia quo cum eaque – Lorem ipsum">
<meta property="og:locale" content="fr_FR">
<meta property="og:url" content="https://www.monjolisite.ltd/lorem-ipsum">
<meta property="og:description" content="Sapiente totam quo ut fugiat pariatur voluptatum nihil nulla. Ratione culpa consectetur quo quasi est enim autem repellat,…">
<meta property="og:image" content="https://www.monjolisite.ltd/image1.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:alt" content="Et cumque sunt explicabo hic tempora">
<meta property="og:image" content="https://www.monjolisite.ltd/image2.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:alt" content="Amet aperiam mollitia sint aut.">
<meta property="og:image" content="https://www.monjolisite.ltd/image3.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:alt" content="Dolorum sed vel saepe perferendis.">
<meta property="article:published_time" content="2018-05-08">
<meta property="article:modified_time" content="2018-05-09">
<meta property="article:author" content="Lorem Ipsum">
<meta property="article:author" content="Tempus Fugit">
<meta property="article:tag" content="Lorem">
<meta property="article:tag" content="Ipsum">
<!-- Twitter Card -->
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Omnis quia quo cum eaque – Lorem ipsum">
<meta name="twitter:description" content="Sapiente totam quo ut fugiat pariatur voluptatum nihil nulla. Ratione culpa consectetur quo quasi est enim autem repellat,…">
<meta name="twitter:dnt" content="on">
<meta name="twitter:url" content="https://www.monjolisite.ltd/lorem-ipsum">
<meta name="twitter:image" content="https://www.monjolisite.ltd/image1.jpg">
<meta property="twitter:image:alt" content="Et cumque sunt explicabo hic tempora">Constantes de personnalisation
Attention, à partir de la v 2.2, les 2 constantes ci-dessous sont obsolètes :
-
_METASPLUS_EXCLURE_GROUPESMOTS. Utiliser le plugin Mots techniques à la place. -
_METASPLUS_MASQUER_AUTEURSest remplacée par une option de configuration.
Discussions par date d’activité
31 discussions
Hello :-)
SPIP 3.2.4 [24285]
Avec uniquement les plug « meta+ » version 2.2.3 et « oembed » en version 2.0.10
php 5.6.40
Juste pour dire que je viens de découvrir un problème avec Facebook, mais je ne suis pas sûr que le problème vienne de meta+ :-(
En faite, le problème est présent, lorsqu’il y a utilisation du plug oembed pour mettre sur un site en spip 3.2.4 https://plugins.spip.net/oembed
Exemple, sur un site, je souhaites que s’affiche https://www.youtube.com/watch?v=ufyZ-sZSz4c
Donc donc mon article, je fais l’ajout de la vidéo via le plug oembed
Donc mon article, j’écris donc <embXXX|center>
Si je regarde dans la médiathèque, la vidéo est présente et il y a bien une vignette que le plug oembed à fait lui même !
Le problème, c’est que Facebook ne semble pas voir l’image, car il indique https://developers.facebook.com/tools/debug/sharing qu’il manque : og:image
A savoir, que j’ai aussi essayer de faire l’ajout d’une image pour remplacer la vignette fait par oembed et cela ne résout pas le problème :-(
Franck
Glop,
À mon avis c’est plutôt un problème éditorial pas lié à oembed : il faut dire explicitement que la vignette de cette vidéo doit servir de logo à l’article.
Donc l’ajouter comme logo, ou alors la mettre en image-jointe.
Re tcharlss :-)
Alors, j’ai fait d’autres tests, et il y a une différence de comportement entre une vidéo qui est héberger localement et dont j’ai fait l’ajout d’une vignette via la médiathèque suivant que dans l’article, je mets <embXXX|center> ou <docXXX|center>
<embXXX|center> cela ne fonctionne pas, la vignette n’est pas visible sur Facebook
<docXXX|center> cela fonctionne, la vignette est visible sur facebook
Donc, c’est « bug » ou pas dans le plug ?
Franck
Il faudra que je fasse des tests chez moi en local pour reproduire, je ne m’explique même pas pourquoi ça fonctionnerait avec
<doc|xxx>puisqu’il ne s’agit pas d’une image.Le plugin ne cherche que des logos ou à défaut des images liées au contenu, mais jamais la vignette d’un document non image lié au contenu.
Répondre à ce message
Bonjour,
Merci pour ce plugin Metaplus
Ce qui est vraiment bien avec SPIP c’est la possibilité de faire les MAJs sans se soucier de savoir si on reste compliant ou pas. Or, malheureusement, avec la dernière version du plugin, il faut mettre les mains dans le cambouis parce qu’il n’y a pas de liaison entre.
Aucun squelette inclure/metasplus-article n’est disponible...Merci à vous !
touti
Hello Touti,
Il s’agit d’une refonte assez substantielle du plugin, la montée du numéro de version X indique une rupture de compatibilité.
Dans cette version il n’est plus nécessaire d’ajouter des
<INCLURE{fond=inclure/metasplus-article}>dans ses squelettes, je suppose que c’est le cas pour toi si tu utilisais la version 1.Je rajouterai un paragraphe plus explicite sur ce point pour les gens qui font mettent à jour depuis la v1.
Répondre à ce message
Tiens, un nouveau format sémantique a émergé : JSON-LD
https://www.alsacreations.com/article/lire/1780-donnees-semantiques-structurees-associees-le-choix-JSON-LD.html
Reste à savoir si c’est intéressant à implémenter et si oui, comment le faire ?
Intéressant, merci pour la veille Erational.
Une implémentation limitée pourrait se faire directement dans le plugin.
Je dis « limitée », car l’implémentation actuelle tend à ne gérer que les données de base communes entre tous les protocoles : titre, description, date, etc.
Donc à priori pas de « location », « offers », « performer » et cie pour JSON-LD.
Et l’implémentation plus poussée pourrait se faire dans un plugin à part, comme c’est le cas pour opengraph.
Dans un v3 ce serait intéressant de pouvoir gérer plus finement chaque protocole quand même, à réfléchir.
Répondre à ce message
Le plugin insère #DESCRIPTIF et ce descriptif se calcule en fonction des 1res lignes du texte. Dans les squelettes on (je) utilise plutôt #TEXTE qui automatiquement concatène le chapeau + le texte.
Quand on lit le manuel des balises à propos de #DESCRIPTIF, c’est très éloquent : https://www.spip.net/fr_article3854.html
Je ne me sers pas de la balise #INTRODUCTION, néanmoins c’est elle qu’on devrait utiliser en fait. https://www.spip.net/fr_article3965.html
Vaut-il mieux que je crée une variante article.html pour utiliser #INTRODUCTION, ou bien est-ce une amélioration à apporter au plugin ?
Je ne pense pas être le seul à utiliser chapeau
C’est censé utiliser #INTRODUCTION en priorité, et seulement si cette balise ne renvoie rien, on se rabat sur #DESCRIPTIF : https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/metasplus/trunk/inclure/metasplus/dist.html#L88
Si ça n’utilise pas l’introduction, c’est qu’il doit y avoir un souci avec la balise #INFO, à investiguer.
Merci de la réponse rapide.
Sur la rubrique où ça me pose souci, j’ai fait le test en insérant
Quel autre test mener ? Désolé mais je ne suis pas développeur, même si je commence à connaître certains basiques
Ah mais attends, c’est comme ça que fonctionne la balise #INTRODUCTION en fait : elle prend en priorité le descriptif, et à défaut le chapeau puis le texte : https://www.spip.net/fr_article3965.html
Donc pas de bug.
Si tu souhaites utiliser le chapeau, crée un squelette inclure/metasplus/article.html :
J’aimerai bien comprendre ce que contient la balise #DESCRIPTIF car la doc spip ne dit rien : https://www.spip.net/fr_article3854.html
OK j’ai trouvé ce qu’est le descriptif. Je ne l’ai pas activé.
Quand je fais le test sur un article de la rubrique incriminée, l’ajout de la balise #INTRODUCTION génère bien le chapeau en 1 et le texte en 2.
Comment trouver l’erreur ?
Effectivement l’aide en ligne est plus bavarde sur l’utilisation de ce champ :
N’hésite pas à te créer un compte sur spip.net et à proposer une amélioration dans le forum de l’article.
Après, son utilisation peut changer selon tes besoins éditoriaux et les squelettes utilisés. Mais très souvent, elle sert juste à avoir un « vrai » résumé avec la balise #INTRODUCTION.
Mais quelle erreur ? Sans descriptif oui, #INTRODUCTION prend le chapo et le texte.
Avec 11000 articles et 15000 urls, le moindre changement peut avoir un impact casse-c...
Ma balise meta description que j’utlise depuis... retourne bien le chapeau en 1er et si pas de chapeau, le début du texte
Si je fais le test sur une page : https://www.tendancehotellerie.fr/articles-breves/communique-de-presse/10967-article/reseaux-sociaux-une-influence-tres-forte-sur-les-voyageurs-d-apres-booking-com, ma méta description
[<meta name="description" content="(#INTRODUCTION{150}|textebrut)" />]donne :<meta name="description" content="17% des voyageurs du monde entier s’inspirent des vacances de leur influenceur préféré pour organiser leur vacances 7% des sondés avouent avoir déjà (...) " />ce qui est mon chapeau
le plugin METAS+ genère
ce qui est mon texte
S’il y a avait un problème avec mon chapeau, pourquoi ma balise « historique » arrive-t-elle à trouver le chapeau et pas METAS+ ?
Pfiou, on va y arriver...
Donc il y a bien un bug avec #INFO_INTRODUCTION.
En attendant que ce soit corrigé dans SPIP, il faut utiliser la solution indiquée dans mon message précédent : https://contrib.spip.net/Metas-version-2#comment500043-500036
Hop : https://core.spip.net/issues/4291
Merciiiii
Avec spip ya des fois où je tourne bourrique mais là, en effet, je vois qu’on va y arriver :)
En attendant une prochaine version de spip, je mettrai en place un squelette
Bon weekend
Répondre à ce message
Salut,
Je viens de voir que le plugin Métas + avait été mis à jour : bravo pour le boulot.
Juste une remarque :
Pour Open Graph le meta og:title est obligatoire, or pour le type website, ce méta n’est pas utilisé !!!
Merci
Glop,
Là c’est un petit compromis pour facebook : ça concerne les pages hors objet éditoriaux (les spip.php ?page=truc), pour lesquelles le plugin ne peut pas connaître automatiquement le titre (ça dépend des squelettes utilisés).
Quand il n’y a pas
og:title, facebook se rabat sur la balise<title>normale (idem pour la description de la page).Ça me semble préférable, plutôt que de mettre le nom du site.
Arf !
Je ne suis pas vraiment d’accord avec ton raisonnement :
En effet si on le pousse jusqu’au bout, et qu’on ne met aucune balise, FB se débrouille, alors a quoi servent les balises meta open graph ?
Bon après, je peux comprendre que ce n’est pas gérable pour toutes les pages, puisque comme tu le dis le titre dépends de ce qui est codé dans le squelette. Mais, pour les pages d’objet éditoriaux aussi le titre dépends de ce qui est codé !
Je pense donc que comme pour les pages d’objet éditoriaux qui utilisent comme og:title la valeur
#INFO_TITRE{#ENV{objet},#ENV{id_objet}}|concat{" – ",#NOM_SITE_SPIP}, la page sommaire doit utiliser la valeur#NOM_SITE_SPIP|concat{" – ",#SLOGAN_SITE_SPIP}.D’autre part, je ne suis pas trop d’accord, toujours pour la page sommaire, pour que og:image soit la première image trouvée, cela devrait être le logo du site.
Je pense que la page sommaire est un cas particulier et doit être traité comme tel.
Je sais je suis ch*an ... :-p
Bredt
Je parle bien d’une exception, bien sûr qu’il est préférable de mettre des metas dès qu’on peut récupérer l’information **pertinente**.
Et pour les pages hors objets éditoriaux, prendre le nom du site comme titre faute de mieux ne me semble pas être le cas : des pages complètement différentes seraient présentées exactement de la même façon quand on les partage.
Oui mais le titre « normal », celui saisit par l’auteur, on le connaît. Si un squelette fait des choses exotiques, il doit surcharger.
Ah oui, pour le sommaire , c’est un oubli.
Ben c’est pas le cas, tu as vu ça où ?
Je ne parlais que du cas sommaire, donc on a l’air d’être sur la même longueur d’onde. Je suis d’accord, pour les autres pages c’est du cas par cas !
Sinon je confirme, c’est bien le logo du site qui est utilisé, mais il ne plait pas à FB, qui va chercher l’image suivante ...
C’est bon pour moi !
Bonne soirée
Bredt
Répondre à ce message
Quand un article n’a pas de logo, on peut utiliser par défaut le logo de la rubrique. Dans le squelette ça se traduit par
#LOGO_ARTICLE_RUBRIQUEA quel endroit du plugin puis-je déclarer
#LOGO_ARTICLE_RUBRIQUEau lieu de#LOGO_ARTICLE?D’avance merci
Plop,
Crée un squelette
inclure/metasplus/article.hmtlavec ce code dedans :Je vais tester
merci :)
J’ai créé ce squelette que j’ai inséré dans /plugins/auto/metasplus/v2.1.11/inclure/metasplus
Maintenant les métas donnent ceci sur une page article
Du coup je supprime le squelette article
Ah oui un souci avec le timestamp, c’est corrigé dans la v2.1.12 qui sera dispo d’ici 1h00
Merci beaucoup :)
Merci beaucoup
J’ai remis en place et ça marche
Merci
Euh... ça marche bien pour les articles sans logo mais pour les articles ayant un logo, ça reprend aussi le logo de la rubrique au lieu du logo de l’article. Du coup, j’ai débranché le squelette article.html.
Autre point que je viens de déceler : le plugin prend les tags. Je me sers des mots clés pour certains affichages, par exemple le slider en homepage et mon tag « slider » se retrouve dans les tags (3 maximum) transmis à Facebook.
Où dois-je interdire au plugin de sélectionner certains groupes de mot clé ?
J’ai l’impression d’être le chieur de service et j’en suis désolé.
> pour les articles ayant un logo, ça reprend aussi le logo de la rubrique au lieu du logo de l’article.
Je ne sais pas pourquoi, la balise est censée prendre celui de l’article en priorité.
Mais bon, là ce n’est pas lié au plugin.
> Où dois-je interdire au plugin de sélectionner certains groupes de mot clé ?
Là doc indique une constante pour ça, mais elle va être bientôt dépréciée. La bonne méthode est d’utiliser le plugin Mots techniques
Répondre à ce message
Bonjour,
Tout d’abord, merci pour ce plugin ! ;-)
Je remarque un petit problème graphique dans l’espace privé : le mini logo à côté du texte « Aperçu des métas+ » est décalé vers le bas et laisse apparaître ce qui semble être le titre ou la balise alt de l’image (cf la copie d’écran ci-dessous).
Version SPIP : SPIP 3.2.1 [23954]
Version Métas + : 2.1.5 SVN [110903]
Bonne journée !
Hello,
Tu as toujours le souci dans la dernière version ?
Avec SPIP 3.2.3 [24211] et Metas + 2.1.13, oui, toujours !
Répondre à ce message
Bonjour,
Merci pour ce gros travail sur le plugin.
Maintenant que le plugin passe par #INSERT_HEAD, les ajouts sont les derniers avant la fin du head alors qu’auparavant, j’arrivais à placer les métas Open Graph dans les premiers ligne du head.
Pourtant mon #INSERT_HEAD est placé avant d’autres insertions, Comment faire pour que les métas Open graph soient placées plus haut dans le head ?
Depuis le changement, Facebook ne lit pas toujours bien ses métas et j’ai un problème avec Hootsuite qui ne récupère pas mes images correctement : il arrive même que Hootsuite récupère le pixel Piwik au lieu de l’image désignée. Mon « inclure » Matomo/Piwik est pourtant censé se placer après #INSERT_HEAD
Par contre les métas twitter sont bien lues par twitter alors que se sont les dernières le mon head
La position des
<meta>dans le<head>n’est pas censée avoir d’impact fonctionnellement. Et je n’ai rien vu de spécial d’indiqué de ce côté là dans les documentations d’open graph ou de twitter.Tu as vu des indications allant dans ce sens quelques part ?
Quel est le problème exactement ? Ça concerne toutes les metas, ou juste une partie (et si oui, lesquelles) ?
Tu as testé avec l’outil de debug de facebook (et si oui, quel est le retour) ?
A priori Facebook s’arrête sur les métas « de base » en haut de
<head>et ne descend pas jusqu’au métas open graphEn haut de sa page debug il indique 3 alertes :
Ensuite Facebook les construit bien « À partir des balises brutes, nous avons construit les propriétés suivantes Open Graph »
On va avoir besoin d’une URL là :)
Déjà sur le lien debug :)
Le robot de facebook a l’air d’être tatillon et de s’arrêter à la 1re erreur, ou un truc comme ça. Quand je passe ta page au validateur w3c, il montre effectivement beaucoup d’erreurs
C’est peut-être lié au doctype que tu utilises, ça ressemble au problème indiqué ici
En tout cas, il n’y a pas de raison de changer la position des metas, ce serait une rustine pour contourner un problème qui n’a rien à voir.
Merci pour tes réponses.
J’ai enfin pu trouver le temps d’essayer de régler le problème : j’ai trouvé un bout de code qui e baladait dans le
<head>au lieu d’être en fin de<body>. Du coup, Facebook voit bien les données Open Graph dans le<head>. Facebook ne voit pas toujours tout du premier coup, néanmoins il remonte les éléments principaux : titre, url, images, author, publisher, description...Le validateur w3c voit toujours des erreurs dont certaines impossibles à régler comme le fait qu’il n’aime pas le prefix dans
<html xmlns="http://www.w3.org/1999/xhtml" prefix="og: http://ogp.me/ns# fb: http://www.facebook.com/2008/fbml">, un bout de code qu’on est pourtant obligé d’avoir.On verra les autres erreurs sur la prochaine version du site.
En tous les cas merci
Répondre à ce message
Re-bonjour,
Suggestion pour une prochaine version :
Facebook relaie le nom de l’auteur d’un article si on insère la méta
<meta property="article:author" content="https://www.facebook.com/XXX" />Dans mon cas, j’ai ajouté un champ extra « fb_author » sur la page ecrire/ ?exec=auteur&id_auteur=YYY et dans lequel j’insère
https://www.facebook.com/XXXPourrait-on automatiser ce processus dans la génération des métas OpenGraph ? Ceci imposerait de créer un champ extra sur la fiche auteur si on coche l’option.
Pour ma part, j’ai ajouté manuellement dans mes squelettes
Merci pour la suggestion.
Pour l’instant je ne vois pas trop comment faire ça proprement, il faut y réfléchir.
Il y a plusieurs moyens de lier des comptes facebook à des auteurs, ça peut être des champs extras, mais aussi d’autres via d’autres plugins plus spécialisés (sociaux, etc.).
Il y a aussi une option à prendre en compte, celle qui fait en sorte de créditer le site comme auteur des contenus au lieu de chaque auteur individuellement, dans ce cas l’identifiant facebook peut venir d’autres plugins (identité extra, etc.)
Ça fait beaucoup de « si » à prendre en compte, bref, à suivre...
Exact
Facebook fait la distinction entre author et publisher qui a sa prope balise
<meta property="article:publisher" content="https://www.facebook.com/ZZZ" />Répondre à ce message
Problème lors de l’installation du plugin du squelette Phantom :
• Mise à jour du plugin « Metas + » (de la version 1.2.8 à) donne page blancheIl semblerait qu’il y ait 2 versions de Metas + 1.2.8 :
Metas + 1.2.8 stable
Metas + 1.2.8 test
Bonjour :-)
Il y a exactement 3 version concernant ce plugin :
https://plugins.spip.net/metasplus.html
Sachant que le squelette « necessite » la version 2.0.0 mini https://zone.spip.net/trac/spip-zone/browser/spip-zone/_squelettes_/html5up_phantom/paquet.xml#L26
La version 1.2.8 ne concerne pas ce squelette, sauf si vous avez fait des modification à une époque pour le rendre compatible avec la version 1.x.x de ce plug (voir l’article de la première version https://contrib.spip.net/Metas-4845 )
Dans ke cas présent, je conseillerais de supprimer la version 1.x.x du plug pour mettre la version 2.x.x et de regarder si des fichiers n’ont pas été modifier chez vous pour le rendre compatible avec la version 1.x.x. du plug
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
