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

Tout d’abord, je ne crois pas qu’il s’agisse d’un problème en double. J’ai cherché des problèmes identiques ou similaires sur SO, et en raison de la nature du dépannage avant de demander, je crois que ce problème est unique.

Facebook ne peut pas saisir mes fichiers og:image j’ai essayé toutes les solutions habituelles. Je commence à penser que cela pourrait avoir quelque chose à voir avec https://...

  • J’ai vérifié http://developers.facebook.com/tools/debug et ai zéro avertissement ou des erreurs.
  • Il s’agit de trouver les images auxquelles nous avons lié dans ” og:image “, mais elles apparaissent en blanc. Lorsque nous cliquons sur la ou les images, cependant, elles existent et sont directement liées à elles.
  • Il ne montre qu’une image – une image hébergée sur un serveur non https.
  • Nous avons essayé des images carrées, des jpegs, des pngs, des tailles plus grandes et des tailles plus petites. Nous avons placé les images directement dans public_html. Zéro sont affichés.
  • Ce n’est pas une erreur de mise en cache, car lorsque nous ajoutons une autre og:image à la méta, celle-ci la trouve et la 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.
  • Nous avons pensé qu’il y avait peut-être un anti-lixiviation sur cpanel ou le .htaccess qui empêchait l’affichage des images, nous avons donc vérifié. Il n’y avait pas. Nous avons même fait un rapide sur un serveur entièrement différent et l’image s’affiche bien.
  • Nous avons pensé que c’était peut-être le og:type ou une autre bizarrerie avec une autre balise meta. Nous les avons tous enlevés, un à la fois et vérifié. Pas de changement. Juste des avertissements.
  • Le même code sur un site Web différent apparaît sans aucun problème.
  • Nous avons pensé que ce n’était peut-être pas en train de tirer des images car nous utilisions la même page de produit pour plusieurs produits (en la modifiant en fonction de la valeur obtenue, à savoir “details.php? Id = xxx”). image (à partir d’une URL différente).
  • En laissant tout og:image ou image_src désactivé, FB ne trouve aucune image.

Je suis au bout du rouleau. Si je disais combien de temps moi et d’autres avons passé sur cela, vous seriez choqués. Le problème est que c’est un magasin en ligne. Nous ne pouvons absolument pas avoir d’images. Nous devons. Nous avons une dizaine d’autres sites … C’est le seul avec og:image problèmes d’ og:image . C’est aussi le seul sur https , donc nous avons pensé 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:

                 

Si vous le souhaitez, voici un lien vers l’une de nos pages de produits sur lesquelles nous travaillons. [Lien raccourci pour essayer de freiner cela pour entrer dans les résultats de recherche pour notre site]: http://rockn.ro/114

MODIFIER —-

En utilisant l’outil “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 sur une seule page. Toutes étaient des images parfaitement valables.

EDIT 2 —-

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

DOSSIER PUBLIÉ —-

Grâce à Keegan, nous soaps maintenant qu’il s’agit d’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 ajouté toutes les images. Nous avons référencé l’image de coordination http://img.otherdomain.com/[like-image.jpg] dans og:image sur chaque page de produit. Nous avons ensuite dû passer par FB Linter et exécuter EVERY link pour actualiser les données OG. Cela a fonctionné, mais la solution est une solution de contournement, et si le problème https est résolu et que nous retournons à l’utilisation du domaine https naturel, FB aura mis en cache les images d’un autre site Web, ce qui compliquera les choses. J’espère que cette information aidera à sauver quelqu’un d’autre de perdre 32 heures de codage de leur vie.

    J’ai rencontré le même problème et l’ai signalé comme un bogue sur le site de développeur de Facebook. Il semble assez clair que les URI d’images utilisant HTTP fonctionnent correctement et que les URI utilisant HTTPS ne fonctionnent pas. Ils ont maintenant reconnu qu’ils “regardent cela”.

    Le bogue peut être vu ici: https://developers.facebook.com/bugs/260628274003812

    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 la property et le content , mais la property aura des valeurs supplémentaires:

    La propriété og:image 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:

          

    Vous devez donc changer og:image propriété og:image pour vos URL HTTPS en og:image:secure_url

    Ex:

    HTTPS META TAG POUR IMAGE:

      

    HTTP META TAG POUR IMAGE:

      

    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 de faire un ping sur les serveurs facebook après avoir mis à jour vos codes – URL Linter

    Je ne sais pas, si c’est seulement avec moi mais pour moi og:image ne fonctionne pas et il choisit le logo de mon site, même si le débogueur facebook affiche la bonne image.

    Mais changer og:image en og:image:url fonctionné pour moi. J’espère que cela aidera toute autre personne confrontée à un problème similaire.

    Je suis venu ici de Google, mais ce n’était pas très utile pour moi. Il s’est avéré qu’il y avait un rapport d’aspect minimum de 3: 1 requirejs pour le logo. Le mien était presque 4: 1. J’ai utilisé Gimp pour le rogner 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 depuis un site https. Le problème était assez différent cependant:

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

    [ https://developers.facebook.com/docs/sharing/best-practices/#precaching%5D

    Tout en testant, il a fallu environ 10 minutes à facebook pour finalement afficher l’image rendue. Donc, alors que je me grattais la tête et que je jetais des balises aléatoires sur facebook (et que je soupçonnais le problème https mentionné ici), il ne me restait plus qu’à attendre.

    Comme cela pourrait 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 plus ) en spécifiant og: image: width et og: image: height. (Lire plus dans le lien ci-dessus)

    Je me demande toujours si ce qui les prend si longtemps …

    J’ai eu la même erreur et rien de précédent n’a aidé, alors j’ai essayé de suivre la documentation originale de Open Graph Protocol et j’ai ajouté l’atsortingbut de préfixe à ma balise HTML et tout est devenu génial.

      

    J’ai eu des problèmes similaires. J’ai enlevé la propriété = “og: image: secure_url” et maintenant, il va juste avec og: image. Parfois, moins c’est plus

    J’ai découvert un autre scénario susceptible de provoquer ce problème. Je suis passé par toutes les étapes décrites dans la question et les réponses, mais le problème est toujours resté.

    J’ai vérifié mes images et constaté que certaines de mes publications avaient des images miniatures beaucoup trop grandes dans une og:image de l’ordre de plusieurs milliers de pixels et de plusieurs mégaoctets.

    Cela est dû à la migration récente 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 dès aujourd’hui :

    Utilisez des images d’au moins 1200 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 messages de la page de lien avec des images plus grandes. La taille des images peut atteindre 8 Mo.

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

    J’ai rencontré le même problème et puis j’ai remarqué que j’avais un domaine différent pour l’ og:url

    Une fois que je me suis assuré que le domaine était le même pour og:url et og:image cela fonctionnait.

    J’espère que cela t’aides.

    N’oubliez pas d’actualiser les serveurs via:

    Debugger Facebook

    Et cliquez sur “Collecter de nouvelles informations”

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

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

    La première image est la plus grande et prend donc le plus de temps à charger. Essayez de réduire cette première image ou de modifier 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 non avec https. Si vous utilisez https, vous obtiendrez une erreur indiquant: L’image jointe () n’a pas pu être téléchargée

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

    1. Accédez au débogueur à l’ adresse https://developers.facebook.com/tools/debug/og/object/
    2. Mettez votre URL
    3. En bas, facebook montre votre “image” (transparent 1×1 GIF)
      1. L’image est liée à votre image d’origine – aucun point en appuyant dessus
      2. Appuyez sur droite et afficher 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 / Developer, actualisez la page si nécessaire
    5. Vous obtiendrez x-error-detail tête de réponse x-error-detail avec une explication

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

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

    En fin de compte, si l’image est demandée via Prerender, 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">     

    C’est soit un bogue dans le prerender lui-même, soit il est supposé être configuré dans votre proxy pour ne pas utiliser le prérendeur pour les requêtes *.jpg (même si elles sont demandées par Facebook bot).

    Il est vraiment difficile de le remarquer, car le pré-rendu est utilisé uniquement sur certains en-têtes d’agent utilisateur.

    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é:

             

    Des symptômes similaires (Facebook et autres ne récupérant pas correctement og: image et autres actifs sur https) peuvent se produire lorsque le certificate https du site n’est pas totalement conforme.

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

    N’a peut-être pas été votre problème, mais pourrait être d’autres avec des symptômes similaires (comme le mien). Il y a plusieurs façons de vérifier votre certificate – celui que j’ai utilisé: https://www.sslshopper.com/ssl-checker.html

    Après plusieurs heures d’essais et d’essais …

    J’ai résolu ce problème le plus simplement possible. Je remarque qu’ils utilisent des “pages de test” dans la page Facebook Developers qui ne contient que les balises “og” et du texte dans la balise body qui référence ces balises.

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

    J’ai créé une seconde vue dans mon application, contenant les mêmes choses qu’ils utilisent.

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