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

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.

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.

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

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.

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.

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 ...

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#">

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

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.

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.

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.

Dans mon cas , le problème était de ne pas fournir CA le certificat racine . Je l'ai compris après avoir utilisé: https://www.ssllabs.com/ssltest/analyze.html pour analyser la configuration SSL.

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

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.

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.

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 ()

N'oubliez pas de rafraîchir les serveurs via:

Débogueur Facebook

Et cliquez sur "Collecter de nouvelles informations"

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.

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:

• Qu'est-ce qui empêche les vérificateurs Open Graph de détecter les données Open Graph?
• Comment savoir quels robots d'un site Web, si je n'ai pas d'accès root à l'hébergement qu'ils liront? t
• 👍 Qu'est-ce qui empêche les vérificateurs Open Graph de détecter les données Open Graph? - Let's Encrypt Community Support
• 👍 Le robot n'est pas en mesure de récupérer des images, mais l'ajout d'une toute nouvelle chaîne de requête unique peut le faire fonctionner pour la première fois - Facebook for Developers

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 .

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).

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.

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.

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"/> 

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"

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