L’un des aspects qui me dérange un peu avec Onebox, c’est que le contenu de Onebox est mis en cache dans le message et ne se met pas à jour lorsque les champs sont modifiés, tant que le message n’est pas édité.
Par exemple, nous créons un OneBox à partir d’un compte, et une semaine plus tard, l’utilisateur modifie sa biographie…
Télécharger à nouveau le Onebox à chaque fois que la page est consultée ralentirait considérablement les choses. Il serait absurde de télécharger à nouveau un Onebox qui n’a jamais changé. Il n’y a aucun moyen de savoir s’il a changé, donc forcer une reconstruction du message (avec la clé à molette ou en l’édition) est la meilleure solution. Si vous saviez qu’une catégorie était susceptible de contenir des Onebox que vous souhaitez mettre à jour régulièrement, vous pourriez créer un plugin qui, par exemple, régénérerait tous les sujets de la catégorie quotidiennement.
En général, les Oneboxes sont mises en cache car vous souhaitez limiter le taux de scraping des sites externes localement pour éviter d’être banni ! (bien sûr, la mise en cache offre aussi un avantage en termes de performances !). Pour contourner le cache dans les rares cas où cela est nécessaire, il suffit d’ajouter une fausse chaîne de requête comme :
?myname=isbill
ou quelque chose de similaire à la fin du lien.
Cela provoquera un rafraîchissement.
La mise en cache des Oneboxes est absolument nécessaire pour le contenu externe, et il n’est pas attendu qu’elle soit actualisée. Je faisais référence aux Oneboxes internes. Comme mentionné dans l’exemple ci-dessus, il est attendu qu’une Onebox créée par un utilisateur soit mise à jour sur tous les sites lors d’une modification de la biographie de la personne concernée.
De plus, les Oneboxes devraient être mises en cache pour le contenu interne afin de réduire la charge, mais il ne serait pas nécessairement mauvais d’indexer ces Oneboxes internes quelque part. Ainsi, si l’enregistrement source change, une tâche de mise à jour pourrait être planifiée pour elles.
Dans la situation actuelle, si Discourse modifie le formatage des Oneboxes (pour les cas internes), les anciens messages continueront d’être affichés avec le même modèle. Ce problème sera résolu si nous mettons en cache le contenu de la Onebox au format JSON dans le message et que nous effectuons le formatage côté client.
Je suis en train d’intégrer le support Onebox sur mon site, et la modification d’un message ne rafraîchit pas le cache Onebox. Je ne vois pas non plus d’option pour « reconstruction après publication » dans mon menu à clé à molette.
Cependant, l’ajout d’une chaîne de requête factice fonctionne, bien que si je reviens à l’URL initiale, la version mise en cache réapparaisse.
Y a-t-il un paramètre ou une astuce que j’aurais manquée ?
Ma version est : Discourse 2.5.5
Soyez prudent : parfois, l’utilisation d’un CDN comme proxy devant le site et l’activation de la couche de cache dans le proxy peuvent causer des problèmes. Si vous utilisez un CDN comme proxy (comme Cloudflare), désactivez-le une fois et vérifiez à nouveau le problème.
Je ne suis pas familier avec les CDN et je n’utilise pas Cloudflare. J’ajoute simplement des métadonnées og: à mon site pour implémenter OpenGraph et ainsi activer les Onebox.
Par conséquent, je procède à de nombreuses modifications sur mon propre site et je souhaite voir comment elles apparaissent lorsqu’elles sont référencées depuis Discourse.
Je remarque que la modification d’un message ne provoque pas la mise à jour du Onebox pour le lien. Ajouter ?x=1 à l’URL le fait.
Le Onebox devrait-il re-scanner l’URL cible à chaque fois qu’un message est modifié ?
Je ne vois pas beaucoup d’adhésion à cette idée… cela me semble être un bug. À moins qu’il existe une case à cocher pour activer ou désactiver l’actualisation du Onebox ?
À titre d’exemple d’une approche alternative, cette page vous permet de tester vos métadonnées pour voir ce que vous obtiendrez, mais elle sert également d’interface pour le cache de Facebook.
C’est drôle que leur balise OpenGraph semble être cassée ! 
Si vous essayez une URL dans cet outil, il récupérera les résultats du cache, puis vous proposera un bouton que vous pourrez utiliser pour re-gratter le site et mettre à jour leur cache.
Ce pourrait être une option intéressante pour cet outil… peut-être un bouton qui apparaît lorsque vous survolez une URL qui se trouve dans le cache ?
Pour l’instant, mes premiers tests lors de l’implémentation de cette fonctionnalité afficheront toujours ce qui est présent sur certains liens.
Nous recherchons également un moyen de rafraîchir les oneboxes, dans notre cas, les oneboxes d’autres sujets de notre forum.
Notre cas d’usage consiste à créer une documentation à travers le forum, qui peut réutiliser d’autres articles wiki. Cependant, comme il s’agit d’articles wiki, il n’est évidemment pas idéal que les oneboxes ne se mettent pas à jour automatiquement avec les nombreuses modifications susceptibles d’être apportées au fil du temps.
Il serait idéal de pouvoir disposer d’un paramètre permettant de rafraîchir automatiquement les oneboxes si elles correspondent au domaine de notre forum et/ou appartiennent à la catégorie où ce cas d’usage se produira (wiki/docs).
Alors que je développe le support OpenGraph sur mon site principal (lié à Discourse via SSO), je rencontre de plus en plus ce problème.
Une astuce qui aide vraiment est de ne plus jamais insérer l’URL réelle immédiatement. À la place, j’utilise l’astuce suggérée par @merefield ci-dessus :
J’ajoute un ?n=1 à la fin de chaque URL la première fois que je la référence. Si le onebox n’est pas satisfaisant, je peux mettre à jour la page, puis incrémenter ma variable N et itérer jusqu’à ce que le résultat soit bon.
Une fois terminé, toute personne qui insère simplement l’URL obtiendra le dernier scraping de la page plutôt que le premier.