Les deux sites ont certainement des balises OG valides. Les sources d’images sont carrées. Nous ne spécifions pas les dimensions des images dans les balises OG.
L’exemple ci-dessus fonctionne bien dans le débogueur de partage Facebook et iFramely. Cliquez sur le lien ci-dessous pour le voir sur iFramely.
J’ai examiné tous les paramètres de onebox et d’image, mais je ne vois rien qui semble pertinent.
J’ai parcouru les guides de dépannage et de configuration de onebox ici, mais rien n’a aidé.
Je pense que cela doit être quelque chose dans nos paramètres Discourse, ou dans Discourse lui-même.
Voyons à quoi ressemble ce lien sur cette instance Discourse :
Lorsque j’ai collé cela, le onebox dans l’aperçu a brièvement affiché l’image avec le bon rapport hauteur/largeur. Une seconde ou deux plus tard, elle a été écrasée.
Donc, quoi qu’il se passe, cela ne se limite pas à notre instance Discourse. Je suppose que nous devrons peut-être spécifier les dimensions de l’image dans les balises OG, mais je ne pensais pas que ce soit nécessaire.
Alors… des progrès sur ce point ? Ça continue d’arriver. S’il existe une solution de contournement, faites-le moi savoir. Si nous faisons quelque chose d’incorrect, faites-le moi savoir.
Rapport d’état : cela se produit toujours. Lorsque je colle un lien dans un nouveau sujet, l’image associée s’affiche correctement dans l’aperçu. Mais dès que j’appuie sur Entrée ou sur la barre d’espace, l’image est écrasée. J’ai revérifié les étapes de dépannage de onebox, et j’ai de nouveau examiné tous les paramètres remplacés, sans succès. C’est de la folie.
Ce CSS pourrait être considéré comme sous-optimal ou comme une sorte de compromis. Je suis en déplacement, mais peut-être qu’il impose actuellement un format 16:9. Pas idéal pour les logos carrés
Je me demande si la hauteur pourrait être définie sur automatique ? (Bien que cela puisse poser des problèmes pour les images portrait)
À quel CSS faites-vous référence ? Je veux dire, vous avez peut-être raison, mais j’essaie de déterminer s’il s’agit de quelque chose que je peux corriger sur notre instance Discourse, ou s’il s’agit de quelque chose dans le code source de Discourse.
Je pense que le bug ici est que si le type est « rich », et que nous ne récupérons pas la présentation entière du payload html de oembed, nous devrions ignorer l’ajout des dimensions, car nous ne nous intéressons pas à ces données.
Ceci corrige le problème :
diff --git a/lib/onebox/engine/standard_embed.rb b/lib/onebox/engine/standard_embed.rb
index e3175d6247..fc8c300d81 100644
--- a/lib/onebox/engine/standard_embed.rb
+++ b/lib/onebox/engine/standard_embed.rb
@@ -159,8 +159,9 @@ module Onebox
@json_ld ||= Onebox::JsonLd.new(html_doc)
end
- def set_from_normalizer_data(normalizer)
+ def set_from_normalizer_data(normalizer, skip_dimensions: false)
normalizer.data.each do |k, _|
+ next if skip_dimensions && k.in?(%i[width height])
v = normalizer.public_send(k)
@raw[k] ||= v unless v.nil?
end
@@ -179,7 +180,8 @@ module Onebox
def set_oembed_data_on_raw
oembed = get_oembed
- set_from_normalizer_data(oembed)
+ skip_dimensions = oembed.data[:type] == "rich"
+ set_from_normalizer_data(oembed, skip_dimensions:)
end
def set_json_ld_data_on_raw
Cependant, je ne suis pas sûr des autres effets secondaires que cela pourrait avoir, j’alerte l’équipe chargée de l’expérience membre qui examinera cela au cours du mois prochain.
Je suis réticent à simplement ajouter mon correctif car il y a beaucoup de couches et de complexité ici, quelqu’un doit s’assurer que nous pouvons ajouter le correctif de manière très sûre et testée.
Ceci est pri-moyen car l’impact de ce bug est assez large étant donné que wp-json le met en évidence.
Génial ! Ces données oembed semblent bien être la preuve irréfutable. Fait intéressant, la documentation de Wordpress (logiciel) ne parle de oembed qu’en termes d’intégration de contenu d’ autres sites par des sites Wordpress, pas l’inverse. Cependant, la documentation de wordpress.com (service) indique “Chaque publication, page, pièce jointe et vidéo VideoPress hébergée sur WordPress.com prend en charge le format oEmbed via notre API publique oEmbed.” Il est donc probablement sûr de supposer que le logiciel Wordpress le fait par défaut.
J’ai examiné tous les paramètres de Wordpress et je n’ai rien trouvé lié à oembed, il semble donc que toutes les hypothèses faites par Wordpress soient intégrées dans le code.
L’API oembed de Wordpress explique également pourquoi il n’y a aucune référence aux dimensions 600/338 nulle part dans le code source de la page, ce que j’avais précédemment trouvé déconcertant.
Je suis d’accord que toute solution possible pour cela dans Discourse pourrait avoir de nombreux effets secondaires (potentiellement indésirables) et doit être testée avant d’être publiée.
De plus, je ne suis même pas sûr qu’il s’agisse d’un problème de Discourse. La fausse dimension ‘338’ provient de Wordpress. Il me semble qu’il devrait y avoir un moyen dans Wordpress de remplacer les valeurs par défaut liées à oembed comme celle-ci. J’ai l’intention de chercher un plugin Wordpress qui permette plus de contrôle sur oembed.
D’un autre côté, puisque ces liens semblent corrects dans iFramely et ailleurs, peut-être que c’est vraiment quelque chose qui devrait être modifié dans Discourse.
