Ce lien n’apparaît pas en « onebox » sur mon site :
Hmmm, et je vois qu’il n’apparaît pas non plus ici. Pourtant, ABC News possède (ce qui n’est pas surprenant) une multitude de balises Open Graph, y compris toutes les balises OG pour Facebook et Twitter. S’agit-il d’un bug, peut-être ? Ou bien Discourse onebox ne peut-il rien exploiter dans toutes ces métadonnées ? 
Merci !
Les deux coupables habituels sont l’absence de balises Open Graph ou un blocage par l’UA de Discourse ou les plages d’adresses IP du fournisseur de services cloud. Le fait que nous puissions voir les balises localement dans notre navigateur ne signifie pas que le serveur peut nécessairement le faire.
Quelques ajustements avec cURL depuis votre VPS permettront généralement d’identifier la cause.
Utilisez l’outil iframely pour dépanner les balises opengraph / oembed sur la page. L’absence de description textuelle de toute nature est une autre raison que je rencontre parfois sur le terrain.
Hum, d’accord. Je pense avoir trouvé… c’est peut-être un champ « description » manquant ?
Voici trois liens provenant de grands sites ainsi que les rapports iframely correspondants.
La seule différence que je remarque entre l’exemple d’ABC News ci-dessus et ce lien de NBC News, c’est que NBC inclut davantage de tailles d’images, des icônes, ainsi qu’une date et une description. L’une de ces différences pourrait-elle être un « obstacle bloquant » empêchant l’activation de la onebox ?
Hum, et CNN manque également d’une description, mais possède une icône et une date. Donc peut-être que le champ description est obligatoire… ?
Oui, pas de description signifie pas de onebox.
Oh. :-/
Cela semble être… une mesure radicale. Je ne vois pas pourquoi toute la beauté de la onebox devrait être jetée simplement parce qu’une description manque. Je vais essayer de faire une PR qui permet aux sites qui n’ont pas de champ de description (jusqu’à présent, nous avons constaté qu’ABC et CNN en font partie) de toujours afficher l’image et le titre.
En y réfléchissant bien, étant donné le nombre de fois où ce sujet est apparu dans le support… si le seul empêchement à l’affichage en un bloc est l’absence de description (ou une description trop courte), nous devrions probablement ajouter une description par défaut, quelque chose comme :
Cette page ne contient aucune balise de description
Au moins, elle s’affichera en un bloc et il sera clair de quoi il s’agit. Peux-tu t’en charger, @sam ?
Avec tout le respect dû-- si une description n’est pas disponible, pourquoi afficher un message comme celui-ci ?!
C’est un message utile si vous déboguez l’affichage des vignettes. Pour les techniciens comme nous, c’est super, formidable.
Mais si vous êtes une personne normale qui souhaite simplement partager un lien vers un site non technique et qui ne se soucie pas du fonctionnement interne des vignettes, ce message n’ajoute rien d’autre que du bruit. Je vous le promets, une vaste majorité des personnes utilisant Discourse (sur des sites concernant les voitures, le support logiciel, les communautés, le matériel audio, etc.) ne savent pas ce qu’est une « balise de description », ni pourquoi cela compte, et elles ne se soucient pas non plus de savoir si le lien qu’elles ont partagé l’a « fournie » ou non. Tout ce qu’elles veulent, c’est que leurs liens soient jolis, point final.
Cela dit : oui, je pense que nous sommes tous d’accord pour dire qu’il n’est pas nécessaire de limiter l’affichage des vignettes aux seuls sites possédant une balise de description-- surtout lorsqu’une description n’est pas vraiment nécessaire. Un titre et une photo non seulement sont tout à fait acceptables, mais ils sont bien mieux que rien.
Ni Facebook ni Twitter n’exigent de descriptions (et ils n’ajoutent jamais un message du type « Cette page ne contient pas de balises de description »), et ils n’ont aucun problème à fonctionner uniquement avec une photo et un titre pour créer un lien attrayant. Je ne vois aucune raison pour laquelle mon logiciel de forum de prédilection, tourné vers l’avenir, ne pourrait pas faire de même. 
C’est prématuré. Cela peut arriver ou non ; @codinghorror est le chef de produit et a le dernier mot sur l’implémentation que nous choisirons.
Je pense que la règle « pas de description, pas de onebox » devrait être levée et devenir une option si nécessaire, mais au final, ce n’est pas à moi de décider.
Si nous levons la règle « pas de description, pas de onebox » ou si nous la rendons facultative, nous aurons peut-être besoin d’un nouveau modèle visuel pour les oneboxes sans description ; ce n’est pas un problème trivial. La règle « pas de description, pas de onebox » est née des plaintes d’utilisateurs qui n’aimaient pas le rendu sans descriptions.
La cour d’appel fédérale infirme le juge et ordonne le rejet de l’affaire Flynn comme demandé par le Département de la Justice, c’est beaucoup de texte bleu. Twitter, par exemple, affiche ce texte en noir, et non en bleu.
C’est juste.
Il me semble étrange que, si les choix sont :
Hé, regardez cet article :
Hé, regardez cet article :
Vraiment, les gens préfèrent l’option A à l’option B ? (Et plus important encore — vraiment, des gens se sont plaints que l’option B était moche ? Cela me semble tout à fait esthétique et fonctionnel…)
Je ne suis pas sûr de bien comprendre ce que vous voulez dire ici ? Quand je publie un lien sur Twitter, s’il n’y a pas de description, il s’étend quand même correctement ? Voici un test que je viens de faire avec le lien CNN de mon premier message dans ce fil.
Et voici comment Discourse rend actuellement exactement le même lien :
Heureux de voir que les gens prennent soin des chiens…
https://edition.cnn.com/2020/05/15/health/gallery/coronavirus-people-adopting-pets-photos/index.html
Désolé de me greffer à la discussion, mais pour réduire le bruit dans le support, pourrions-nous également disposer d’un journalisation plus détaillée des échecs de Onebox à un moment donné, afin que les administrateurs du site soient moins dans l’ignorance lorsque les choses ne « s’encadrent » pas ?
Je suis d’accord avec ce changement, tant que la mise en page ne nécessite pas beaucoup de corrections @sam .. Cela fait longtemps que la règle de 3 a été dépassée, il est donc probablement acceptable d’autoriser les oneboxes sans description à ce stade.
Merci à @codinghorror et à @sam, c’est très apprécié.
Le gem Onebox prend désormais en charge les oneboxes avec uniquement un titre, selon ce commit. Exemple :
Rapport iframely d’ABC News
