FB OpenGraph og: image ne tirant pas d'images (éventuellement https?)


301

Premièrement - je ne pense pas que ce soit un problème en double. J'ai recherché des problèmes identiques ou similaires sur SO de manière approfondie, et en raison de la nature du dépannage avant de demander, je pense que ce problème est unique.

Facebook ne peut pas saisir mes og:imagefichiers et j'ai essayé toutes les solutions habituelles. Je commence à penser que cela pourrait avoir quelque chose à voir avechttps://...

  • J'ai vérifié http://developers.facebook.com/tools/debug et je n'ai aucun avertissement ou erreur.
  • Il s'agit de trouver les images auxquelles nous avons lié dans le " og:image", mais elles apparaissent en blanc. Cependant, lorsque nous cliquons sur les images, elles EXISTENT et cela leur prend directement.
  • Il montre une image - une image hébergée sur un serveur non https.
  • Nous avons essayé des images carrées, des jpeg, des pngs, des tailles plus grandes et des tailles plus petites. Nous avons mis les images directement dans public_html. Zéro se présente.
  • Ce n'est pas une erreur de mise en cache, car lorsque nous en ajoutons un autre og:imageà la méta, le linter de FB le trouve et le lit. Il montre un aperçu. L'aperçu est vide. La seule exception que nous obtenons concerne les images qui ne figurent pas sur ce site Web.
  • Nous pensions qu'il y avait peut-être un anti-lixiviation cpanelou .htaccessqui empêchait les images de s'afficher, alors nous avons vérifié. Il n'y avait pas. Nous avons même fait un rapide < img src="[remote file]" >sur un serveur entièrement différent et l'image apparaît très bien.
  • Nous pensions que c'était peut-être la og:typeou une autre bizarrerie avec une autre balise META. Nous les avons tous retirés un par un et nous les avons vérifiés. Pas de changement. Juste des avertissements.
  • Le même code sur un site Web différent s'affiche sans aucun problème.
  • Nous pensions que peut-être il ne tirait pas d'images parce que nous utilisons les mêmes pages de produit pour plusieurs produits (en les modifiant en fonction de la valeur d'obtention, c'est-à-dire "details.php? Id = xxx"), mais il en reste toujours une image (à partir d'une URL différente).
  • En laissant tout og:imageou image_src désactivé, FB ne trouve aucune image.

Je suis au bout de ma corde. Si je disais combien de temps moi-même et d'autres avons consacré à cela, vous seriez choqué. Le problème est qu'il s'agit d'une boutique en ligne. Nous ne pouvons absolument, positivement PAS avoir d'images. Nous devons. Nous avons une dizaine d'autres sites ... C'est le seul à avoir des og:imageproblèmes. C'est aussi le seul https, donc nous pensions que c'était peut-être le problème. Mais nous ne pouvons trouver aucun précédent sur le Web pour cela.

Ce sont les méta-tags:

<meta property="og:title" content="[The product name]" /> 
<meta property="og:description" content="[the product description]" /> 
<meta property="og:image" content="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />
<meta property="og:image" content="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-art-black.png" />
<meta property="og:image" content="http://www.[ADIFFERENTwebsite].com/wp-content/uploads/2011/06/ARS-Header-Shine2.png" />
<meta property="og:image" content="https://www.[ourwebsite].com/images/ARShopHeader.png" />
<meta property="og:image" content="http://www.[ourwebsite].com/overdriven-blues-music-tshirt-art-black.JPG" />
<meta property="og:type" content="product"/>
<meta property="og:url" content="https://www.[ourwebsite].com/apparel-details.php?i=10047" />
<meta property="og:site_name" content="[our site name]" />      
<meta property="fb:admins" content="[FB-USER-ID-NUMBER]"/>
<meta name="title" content="[The product name]" />
<meta name="description" content="[The product description]" />
<link rel="image_src" href="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />
<meta name="keywords" content="[four typical keywords]">
<meta name="robots" content="noarchive">

Si vous le souhaitez, voici un lien vers l'une de nos pages produits sur lesquelles nous avons travaillé. [Lien raccourci pour essayer de limiter cette entrée dans les résultats de recherche pour notre site]: http://rockn.ro/114

ÉDITER ----

En utilisant l'outil de grattage "voir ce que Facebook voit", nous avons pu voir ce qui suit:

"image": [          
      {
         "url": "https://www.[httpSwebsite].com/images/shirts/soul-man-soul-music-tshirt-details-safari.png"
      },
      {
         "url": "https://www.[httpSwebsite].com/images/shirts/soul-man-soul-music-tshirt-art-safari.png"
      },
      {
         "url": "http://www.[theotherNONSECUREwebsite].com/wp-content/uploads/2011/06/ARS-Header-Shine2.png"
      }
   ],

Nous avons testé tous les liens trouvés pour une seule page. Toutes étaient des images parfaitement valables.

EDIT 2 ----

Nous avons essayé un test et ajouté un sous - domaine au site Web NONSECURE (à partir duquel les images sont réellement visibles via Facebook). Le sous-domaine était http: // img. [Non sécurisé] .com. Nous avons ensuite placé toutes les images dans le dossier du sous-domaine principal et les avons référencées. Il ne tirerait pas ces images dans FB. Cependant, il tirerait toujours toutes les images référencées sur le domaine principal non sécurisé.

SOLUTION PUBLIÉE ----

Grâce à Keegan, nous savons maintenant que c'est un bug sur Facebook. Pour contourner ce problème, nous avons placé un sous-domaine dans un autre site Web NON-HTTPS et y avons transféré toutes les images. Nous avons référencé l' http://img.otherdomain.com/[like-image.jpg]image de coordination og:imagesur chaque page de produit. Nous avons ensuite dû passer par FB Linter et exécuter CHAQUE lien pour actualiser les données OG. Cela a fonctionné, mais la solution est une solution de rechange, et si le httpsproblème est résolu et que nous revenons à l'utilisation du domaine https naturel, FB aura mis en cache les images d'un autre site Web, ce qui complique les choses. J'espère que ces informations aideront à sauver quelqu'un d'autre de perdre 32 heures de codage de sa vie.


27
Question bien documentée. A voté pour vous!
DMCS

Pour le dépannage, essayez de passer og:type: og_products:productau type de site Web et voyez si les images peuvent être récupérées.
DMCS

2
Juicy, nous avons une og: image référencée à partir d'un site extérieur qui est http et non https et qui apparaît.
Chypre106

1
Salut, merci, super article. Juste une petite remarque sur le fait que vous craignez d'avoir à mettre à jour le cache si vous revenez à https-urls une fois que celles-ci commencent à fonctionner: je ne m'inquiéterais pas de cela car le cache fb est libéré après un certain temps, alors gardez simplement le double de données pendant un jour ou deux et le cache sera libéré automatiquement en utilisant les nouvelles URL.
Niclas Lindqvist

1
@NiclasLindqvist Hé juste pour mémoire, nous avons gardé de vieilles images dans le cache pendant MOIS et des mois avant, donc je prendrais les standards de cache de FB avec un grain de sel.
Cyprus106

Réponses:


93

J'ai rencontré le même problème et l'ai signalé comme un bug sur le site des développeurs Facebook. Il semble assez clair que les og:imageURI utilisant HTTP fonctionnent très bien et les URI utilisant HTTPS non. Ils ont maintenant reconnu qu'ils «étudiaient cela».

Mise à jour: à partir de 2020, le bug n'est plus visible dans le système de ticket de Facebook. Ils n'ont jamais répondu et je ne pense pas que ce comportement ait changé. Cependant, la spécification de l'URI HTTPS dans og:image:securesemble fonctionner correctement.


3
KEEGAN! Je vous remercie! C'est la première fois que nous voyons le problème HTTPS documenté comme étant un bogue ..... et nous avons cherché sérieusement. Poster notre solution de contournement dans les commentaires de la question.
Cyprus106

2
Depuis août 2013, cette URL n'affiche pas le bogue. Y a-t-il eu des mises à jour?
Andreas Andreou

3
developers.facebook.com/bugs/256470807842897 Ce nouveau bug est également pertinent. Bien que la question ait été répondue, je me suis dit que j'ajouterais le lien ici, donc si quelqu'un d'autre avec un problème similaire atterrit ici, il le trouvera.
Zoidberg

4
Dit que le problème a été résolu le 18 mars 20145, pas pour moi.
Mike Flynn

1
@MattBrowne Nope, ce n'est pas résolu pour moi :-(
starbeamrainbowlabs

131

Certaines propriétés peuvent être associées à des métadonnées supplémentaires. Celles-ci sont spécifiées de la même manière que les autres métadonnées avec propertyet content, mais elles propertyauront un extra:

La og:imagepropriété a des propriétés structurées facultatives:

  • og:image:url - Identique à og: image.
  • og:image:secure_url - Une autre URL à utiliser si la page Web nécessite HTTPS.
  • og:image:type - Un type MIME pour cette image.
  • og:image:width - Le nombre de pixels de large.
  • og:image:height - Le nombre de pixels de haut.

Un exemple d'image complète:

<meta property="og:image" content="http://example.com/ogp.jpg" />
<meta property="og:image:secure_url" content="https://secure.example.com/ogp.jpg" /> 
<meta property="og:image:type" content="image/jpeg" /> 
<meta property="og:image:width" content="400" /> 
<meta property="og:image:height" content="300" />

Vous devez donc modifier la og:imagepropriété de vos URL HTTPS enog:image:secure_url

Ex:

HTTPS META TAG POUR L'IMAGE:

<meta property="og:image:secure_url" content="https://www.[YOUR SITE].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />

ÉTIQUETTE META HTTP POUR IMAGE:

<meta property="og:image" content="http://www.[YOUR SITE].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />

Source: http://ogp.me/#structured <- Vous pouvez visiter ce site pour plus d'informations.

J'espère que cela vous aidera.

EDIT: N'oubliez pas d'envoyer une requête ping aux serveurs Facebook après la mise à jour de vos codes - URL Linter


1
SIR, merci beaucoup. Je ne savais pas qu'il y avait d'autres métadonnées pour les images! Nous avons essayé de faire image: secure_url par lui-même et FB a lancé une erreur. Nous avons essayé image & secure_url * de plusieurs façons) et linter n'a montré aucun changement.
Cyprus106

Pour moi, il continue d'afficher les images d'aperçu, pas l'image de la balise META. J'ai aussi la bonne URL! :( Des idées?
jaminroe

1
@jaminroe Avez-vous peluqué? Si ce n'est pas le cas, alors. Cela devrait principalement résoudre le problème. S'il ne sélectionne toujours pas, alors voyez ce que l'outil est capable de gratter, vous pouvez également voir ce qui est exactement gratté, il y a un lien à la fin du résultat, See exactly what our scraper sees for your URLcliquez dessus et voyez s'il montre la source complète de votre lien ou son effacement n'importe quoi. Si le problème charsetest réglé, le grattoir ne pourra pas gratter pour une raison quelconque (j'avais répondu à une question similaire il y a quelque temps avec ce problème). Assurez-vous donc que toutes ces choses sont correctes.
Syed IR

3
Au cas où cela aiderait quelqu'un - notre URL og: image n'a pas d'extension de fichier car les images sont créées par un service (/ foo / bar). Cette réponse a corrigé nos problèmes avec Facebook linter, probablement à cause de og: type = "image / png". Je vous remercie!!
Dunc

3
@JohnWasham La og:imagebalise peut être HTTPS (c'est ce que font StackExchange, YouTube, WordPress.com, Amazon, etc.). Cela vous fait vous demander à quoi ça og:image:secure_urlsert vraiment?
DocRoot

16

Je ne sais pas, si c'est seulement avec moi mais pour moi og:imageça ne marche pas et ça choisit le logo de mon site, même si le débogueur facebook montre la bonne image.

Mais changer og:imagepour og:image:urltravaillé pour moi. J'espère que cela aidera quiconque face à un problème similaire.


Acclamations - travaillé pour moi - mais le débogueur facebook veut aussi de l'image, alors j'envoie les deux. og: image et og: image: url - les deux avec la même valeur / url
pperrin

1
La syntaxe og: image: url est-elle reconnue ou est-elle incorrecte et n'est-elle donc pas analysée? En d'autres termes, est-ce la même chose que de ne pas avoir du tout la balise META?
Jonathan Tonge

@JonathanTonge Accoding to ogp.me , " og:image:urlest identique à og:image".
DocRoot

9

Je suis venu de Google, mais cela ne m'a pas beaucoup aidé. Il s'est avéré qu'il y avait un rapport d'aspect minimum de 3: 1 requis pour le logo. Le mien était presque 4: 1. J'ai utilisé Gimp pour le recadrer exactement à 3: 1 et le tour est joué - mon logo est maintenant affiché sur FB.


2
C'est un rapport hauteur / largeur maximum de 3: 1 ( developers.facebook.com/docs/opengraphprotocol ), avec une taille minimale de 50 px x 50 px
rpearce

1
Selon le débogueur facebook, la taille requise est maintenant de
200 px

8

tl; dr - soyez patient

Je me suis retrouvé ici parce que je voyais des images vierges servies à partir d'un site https. Le problème était tout à fait différent cependant:

Lorsque le contenu est partagé pour la première fois, le robot d'exploration Facebook supprimera et mettra en cache les métadonnées de l'URL partagée. Le robot doit voir une image au moins une fois avant de la rendre. Cela signifie que la première personne qui partage un élément de contenu ne verra pas d'image rendue

[ https://developers.facebook.com/docs/sharing/best-practices/#precaching]

Pendant les tests, il a fallu environ 10 minutes à Facebook pour afficher enfin l'image rendue. Alors pendant que je me grattais la tête et jetais des balises og aléatoires sur Facebook (et soupçonnant le problème https mentionné ici), tout ce que j'avais à faire était d'attendre.

Comme cela pourrait vraiment empêcher les gens de partager vos liens pour la première fois, FB suggère deux façons de contourner ce comportement: a) exécuter le débogueur OG sur tous vos liens: l'image sera mise en cache et prête à être partagée après ~ 10 minutes ou b ) en spécifiant og: image: largeur et og: image: hauteur. (En savoir plus sur le lien ci-dessus)

Je me demande encore ce qui leur prend si longtemps ...


La raison en est le rapport d'image. Si le rapport de dimension d'image n'est pas exactement de 1,91: 1 et / ou les données og:image:widthet og:image:heighti ne sont pas incluses, Facebook devra alors traiter l'image après l'avoir mise au rebut pour l'adapter à ses dimensions. L'image finira également par être rognée, ce qui peut être indésirable. Pour plus de détails, voir: developers.facebook.com/docs/sharing/best-practices/#images
Slicktrick

1
Spécifier og: image: largeur et og: image: hauteur sur des images qui ne figurent pas sur leur très courte liste de résolutions qualifiées, n'accélérez pas les choses dans mes tests.
Chris Moschini

5

J'ai eu la même erreur et rien de précédent n'a aidé, j'ai donc essayé de suivre la documentation originale de Open Graph Protocol et j'ai ajouté l'attribut prefix à ma balise html et tout est devenu génial.

<html prefix="og: http://ogp.me/ns#">

2

J'ai eu des problèmes similaires. J'ai supprimé la propriété = "og: image: secure_url" et maintenant il va effacer avec juste og: image. Parfois, moins c'est plus


1
Votre réponse devrait avoir beaucoup plus de votes! Vous avez tout à fait raison, si vous ne diffusez que du contenu via https, utilisez simplement og: image: url et finissez-en.
marcvangend

1
Je ne comprends pas pourquoi c'est une solution. la question n'a clairement pas eu le secure_url en premier lieu, pourquoi pensez-vous que cela fonctionne, c'est trop aléatoire
Decebal

1

J'ai découvert un autre scénario qui peut provoquer ce problème. J'ai parcouru toutes les étapes décrites dans la question et les réponses, le problème restait toujours.

J'ai vérifié mes images et j'ai constaté que certains de mes messages avaient des images miniatures beaucoup trop grandes og:imagedans la gamme de plusieurs milliers de pixels et plusieurs mégaoctets.

Cela s'est produit en raison de la récente migration de WP vers Jekyll, j'ai optimisé mes images avec gulp, mais j'ai utilisé les images originales dans og: image par erreur.

Facebook nous donne les recommandations suivantes à partir d'aujourd'hui :

Utilisez des images d'au moins 1 200 x 630 pixels pour un affichage optimal sur les appareils haute résolution. Au minimum, vous devez utiliser des images de 600 x 315 pixels pour afficher les publications de la page de liens avec des images plus grandes. La taille des images peut atteindre 8 Mo.

Il y a donc une limite supérieure de 8 Mo.


1

Comme je l'ai trouvé accidentellement, une image vierge transparente est livrée avec un en-tête de réponse indiquant la cause possible du problème.

  1. Accédez au débogueur à https://developers.facebook.com/tools/debug/og/object/
  2. Mettez votre URL
  3. En bas, facebook affiche votre "image" (GIF 1x1 transparent)
    1. L'image est liée à votre image d'origine - inutile de la presser
    2. Appuyez à droite et affichez l'image (vous obtiendrez quelque chose comme https://external-ams3-1.xx.fbcdn.net/safe_image.php?d=...&url=...)
  4. Activez l'onglet Net sur les outils firebug / développeur, actualisez la page si nécessaire
  5. Vous obtiendrez x-error-detailun en-tête de réponse avec une explication

Par exemple, dans mon cas, c'était Invalid image extension for URL: https://[mydomain]/[myfilename].jpg

Le vrai problème dans mon cas était lié à prerender.io .

Il s'avère que si l'image est demandée via une prérendeuse, elle est convertie en HTML. Quelque chose comme ça:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head>
<body style="margin: 0px;"><img style="-webkit-user-select: none; cursor: -webkit-zoom-in; " src="https://[yourdomain].com/[yourfilename].jpg" width="1078" height="718"></body>
</html>

C'est soit un bogue dans le prerender lui-même, soit il est censé être configuré dans votre proxy pour ne pas utiliser le prerender pour les *.jpgdemandes (même si elles sont demandées par le bot Facebook).

Il est vraiment difficile de le remarquer, car la prérender n'est utilisée que sur certains en-têtes d'agent utilisateur.


1

Je suis tombé sur le même problème, puis j'ai remarqué que j'avais un domaine différent pour le og:url

Une fois, j'ai vérifié que le domaine était le même og:urlet og:imagecela a fonctionné.

J'espère que cela t'aides.


2
Cependant, cela n'est pas toujours possible, car og: image peut être une URL CDN cloudfront. De plus, dans mon cas, alors que FB (en 2017!) Ne récupère pas l'image CDN de la page elle-même, il récupère une autre image CDN qui est également Cloudfront, ce qui signifie que ce n'est pas non plus mon og: url. Votre point est donc incorrect.
PKHunter

C'est vrai. Je n'utilisais pas d'URL CDN. Je pensais juste que je partagerais ce qui fonctionnait pour moi.
Darren Hall


1

Des symptômes similaires (Facebook et al ne récupérant pas correctement og: image et autres actifs sur https) peuvent se produire lorsque le certificat https du site n'est pas entièrement conforme.

Le certificat https de votre site peut sembler valide (clé verte dans le navigateur et tout), mais il ne se raclera pas correctement s'il manque un certificat intermédiaire ou de chaîne. Cela peut entraîner de nombreuses heures perdues à vérifier et revérifier tous les différents caches et balises META.

Cela n'a peut-être pas été votre problème, mais il pourrait en être d'autres avec des symptômes similaires (comme le mien). Il existe de nombreuses façons de vérifier votre certificat - celui que j'ai utilisé: https://www.sslshopper.com/ssl-checker.html


1

Je l'ai http://sorti de mon og:imageet l' ai remplacé par un simple vieux www.puis il a commencé à bien fonctionner.

Vous pouvez utiliser cet outil, par Facebook, pour réinitialiser votre cache de capture d'image et tester l'URL qu'il tire pour l'image de démonstration.


0

Je peux voir que le débogueur récupère 4 og:imagebalises de votre URL.

La première image est la plus grande et prend donc plus de temps à charger. Essayez de réduire cette première image ou modifiez l'ordre pour afficher d'abord une image plus petite.


Merci Lix! Nous avions en fait une petite image carrée, environ 200x200 max, comme première image depuis longtemps. Nous avons réorganisé et re-gratté un certain nombre de fois. Nous avons également fait une combinaison de rendre les plus petites, les plus grandes ou les alternatives les seules images et le recadrage avec un taux de réussite nul.
Cyprus106

0

En outre, ce problème se produit également lorsque vous ajoutez une histoire générée par l'utilisateur (où vous n'utilisez pas og: image). Par exemple:

POST /me/cookbook:eat?
  recipe=http://www.example.com/recipes/pizza/&
  image[0][url]=http://www.example.com/recipes/pizza/pizza.jpg&
  image[0][user_generated]=true&
  access_token=VALID_ACCESS_TOKEN

Ce qui précède ne fonctionnera qu'avec http et pas avec https. Si vous utilisez https, vous obtiendrez une erreur qui dit: Impossible de télécharger l'image attachée ()


J'adore, Google s'oriente vers une plus grande pertinence des sites avec les sites avec https, et deux ans après avoir posé cette question, FB punit toujours (par inadvertance, peut-être, mais toujours un péché) les sites Web qui valorisent la sécurité de leurs visiteurs
Chypre106


0

J'ai eu un problème similaire aujourd'hui, que le débogueur de partage m'a aidé à résoudre. Il semble que Facebook ne puisse pas (actuellement) comprendre les images avec les métadonnées XMP intégrées. Lorsque j'ai remplacé les images de nos articles par des versions sans métadonnées XMP et que j'ai re-gratté la page (à l'aide du débogueur de partage), le problème a disparu. Un éditeur hexadécimal vous aidera à voir si votre image contient ou non des métadonnées XMP.


0

Dans mon cas, il semble que le robot ait juste un bug. J'ai essayé:

  • Modification des liens vers http uniquement
  • Suppression de l'espace blanc final
  • Revenir complètement à http
  • Réinstaller le site Web
  • Installer un tas de plugins OG (j'utilise WordPress)
  • Suspecter le serveur a une mauvaise configuration étrange qui bloque les bots (car tous les vérificateurs OG ne peuvent pas récupérer les balises et les autres demandes sur mes sites sont instables)

Aucun de ces travaux. Cela m'a coûté une semaine. Et soudain, sorti de nulle part, il semble fonctionner à nouveau.

Voici mes recherches, si quelqu'un rencontre à nouveau ce problème:

En outre, il existe plus de vérificateurs autres que le débogueur d'objets de Facebook pour vous de vérifier: OpenGraphCheck.com , Open Graph Tester d'Abhinay Rathore , Iframely's Embed Codes , Card Validator | Développeurs Twitter .


0

OK ... Je me rends compte que ce fil est vieux et surpeuplé, mais au cas où quelqu'un arriverait comme si j'avais du mal à faire fonctionner sa balise og: image directement sur Facebook, voici l'astuce qui a fonctionné pour moi:

N'utilisez PAS ce lien:

https://developers.facebook.com/tools/debug/sharing/?q=https%3A%2F%2Fwww.google.com

pour résoudre votre problème. Ou si vous le faites, faites défiler immédiatement vers le bas et cliquez sur Scrape VIA API.

https://developers.facebook.com/tools/explorer/?method=POST&path=%3Fscrape%3Dtrue%26id%3Dhttps%3A%2F%2Fwww.google.com&version=v5.0

Il y a des erreurs affichées dans l'outil d'exploration qui ne sont PAS affichées dans l'outil "débogage". Exaspérant!!! (dans mon cas, un espace dans le nom de fichier de l'image a assommé mon image en silence dans l'outil de débogage, mais il a montré l'erreur dans l'outil d'exploration).


0

Je suis tombé sur une autre raison pour que les images og ne s'affichent pas sur les cartes FB. De plus, en utilisant l' outil de raclage FB pour déboguer les balises meta og , je pouvais confirmer toutes les balises requises lorsqu'elles étaient présentes dans ma page WordPress, et pourtant j'obtiendrais l'erreur de téléchargement de fichier suivante,

À condition que og: image, <https-link-to-jpg-image> ne puisse pas être téléchargé. Cela peut se produire pour plusieurs raisons, telles que votre serveur utilisant un encodage de contenu non pris en charge. Le robot accepte les encodages de contenu dégonflé et gzip.

J'ai eu un vague sentiment que le format d'image avait un problème, le lien vers l'image fonctionnait mais le message semble indiquer quelque chose de mal avec l'encodage du contenu.

Après beaucoup de recherches, j'ai fini par regarder les extensions php requises pour un serveur WordPress et j'ai réalisé que le module pho-exif n'était pas installé. Le module exif écrit des métadonnées exif sur toutes les images téléchargées. Par conséquent, les images utilisées dans la balise d'image FB og n'avaient pas de métadonnées exif associées.

Une fois le module exif activé, WordPress permet de réinitialiser les métadonnées exif pour une image (Médiathèque-> sélectionner et image-> Modifier plus de détails-> Mapper les métadonnées exif) et l'image apparaît maintenant sur la carte FB comme prévu.


-1

D'après ce que j'ai observé, je constate que lorsque votre site Web est public et même si l'url de l'image est https, cela fonctionne très bien.


-1

Pour moi, cela a fonctionné:

<meta property="og:url" content="http://yoursiteurl" />
    <meta property="og:image" content="link_to_first_image_if_you_want" />
    <meta property="og:image" content="link_to_second_image_if_you_want" />
    <meta property="og:image:type" content="image/jpeg" /> 
    <meta property="og:image:width" content="400" /> 
    <meta property="og:image:height" content="300" />
    <meta property="og:title" content="your title" />
    <meta property="og:description"  content="your text about homepage"/> 

-2

Après plusieurs heures de tests et d'essais ...

J'ai résolu ce problème aussi simple que possible. Je remarque qu'ils utilisent des "pages de test" dans la page des développeurs Facebook qui contient uniquement les balises "og" et du texte dans la balise body qui fait référence à ces balises og.

Alors qu'est-ce que j'ai fait?

J'ai créé une deuxième vue dans mon application, contenant les mêmes choses qu'ils utilisent.

Et comment je sais que Facebook accède à ma page pour que je puisse changer la vue? Ils ont un agent utilisateur unique: "facebookexternalhit / 1.1"


-2

Une fois que vous avez mis à jour la balise META, assurez-vous que le lien de contenu (image) est un chemin absolu et allez ici, https://developers.facebook.com/tools/debug/sharing entrez votre lien de site et cliquez sur scrape againdans la page suivante

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.