Au cours des derniers jours, dans notre Discourse, nous avons remarqué que le bouton « Afficher le message complet » reste sur « Chargement… » lorsqu’il est cliqué :
De plus, les nouveaux commentaires Discourse n’apparaissent plus dans notre intégration depuis notre site web Drupal. Nous utilisons avec succès les instructions d’intégration JavaScript ci-dessous depuis des années :
Cependant, pour une raison quelconque, cela semble avoir cessé de fonctionner récemment. Je pense que le dernier message fonctionnel date du 1er de ce mois. Les anciens messages s’affichent dans Discourse et dans le module d’intégration, mais pour les articles plus récents, le bloc Discourse reste bloqué sur le texte « Chargement… ».
Notre module Discourse Drupal se charge à partir du code suivant :
J’ai confirmé que le fichier « javascripts/embed.js » existe toujours au même emplacement.
C’est le bloc qui s’affiche sur les pages d’articles ; il affiche juste « Chargement de la discussion… » dernièrement :
Nous n’avons apporté aucune modification au cours des dernières années à notre intégration ou à notre configuration Discourse. Y a-t-il eu des changements récents dans la fonctionnalité de Discourse qui pourraient casser cela ? Toute aide pour résoudre ce problème serait grandement appréciée !
nous utilisons la même fonctionnalité d’intégration sur notre site. je suppose que discourseUrl et discouseEmbedUrl ne sont pas ce que vous avez posté ci-dessus et plutôt les URL pertinentes de votre forum ?
sinon, le code semble correct. je sais que la fonctionnalité d’intégration fonctionne pour la version bêta à jour de Discourse. nous avons eu énormément de messages intégrés cette semaine. je trouve étrange qu’il intègre la première partie du message mais que le bouton “afficher le message complet” ne fonctionne pas. les nôtres se chargent immédiatement
avez-vous vérifié la console pour des erreurs ?
vous pourriez toujours essayer de désactiver le paramètre embed_truncate juste pour voir s’il publie tout le texte. cela pourrait aider à cerner la cause du problème.
Oui, c’est exact, j’ai utilisé le placeholder sitename juste pour plus de clarté.
Zut, heureusement que la fonctionnalité d’intégration de Discourse ne semble pas être cassée ! Ça doit être quelque chose de notre côté.
J’ai vérifié les logs de Discourse (discourse.sitename.com/logs) et je ne vois que beaucoup d’avis de dépréciation comme ci-dessous :
Avis de dépréciation : SiteSetting.enable_personal_messages a été déprécié.
Je peux certainement essayer de désactiver également embed_truncate, je vais chercher ça ensuite. Mais cette fonctionnalité fonctionnait depuis des années sans problème, donc je ne suis pas sûr pourquoi elle se serait cassée…
essayez de regarder dans la console des outils de développement pour voir s’il y a des erreurs lorsque vous cliquez sur le bouton « Afficher le message complet ». Les outils de développement sont accessibles en faisant un clic droit et « Inspecter ». Les erreurs s’afficheront en rouge sur le côté droit.
oui, la fonctionnalité d’intégration n’est absolument pas cassée. C’est quelque chose qui arrive plusieurs fois par jour sur mon site.
Je pense que notre configuration est gérée ; je n’y ai apporté aucune modification, mais notre tableau de bord Discourse indique une date de dernière mise à jour de Discourse du 18 avril. En regardant la dernière annonce liée à cela, il semble qu’il s’agisse de la version 3.0.3.
assurez-vous que vous exécutez également la dernière version de Discourse. il pourrait également être utile de voir si la même chose se produit en mode sans échec.
C’est une bonne idée, merci ! Je viens de vérifier et je vois cette erreur :
Uncaught DOMException: Une chaîne de caractères invalide ou illégale a été spécifiée
postUp embed-application.js:6
onload embed-application.js:36
EventHandlerNonNull* embed-application.js:25
<anonymous> embed-application.js:66
[embed-application-4e18c443be26cb7c50c56d1a8f39fcf176af9b4ae8e42243648f33c23d9b7eb9.js:5](https://conversation.spectrummagazine.org/assets/embed-application-4e18c443be26cb7c50c56d1a8f39fcf176af9b4ae8e42243648f33c23d9b7eb9.js)
postUp embed-application.js:6
onload embed-application.js:36
(Async: EventHandlerNonNull)
<anonymous> embed-application.js:25
<anonymous> embed-application.js:66
C’est tellement étrange car je n’ai apporté aucune modification au code ni quoi que ce soit récemment. Cependant, je me souviens avoir utilisé Cloudflare le 2 de ce mois pour renforcer la sécurité ; je devrai peut-être vérifier s’il y a quelque chose de ce côté qui pourrait bloquer les scripts.
J’ai vu une erreur CSP dans la console des outils de développement la dernière fois que j’ai vérifié cela, donc peut-être que cela pourrait être le problème, potentiellement du côté de Cloudflare.
je sais que lorsque notre site parent a modifié sa politique de contenu en ligne et ses paramètres de sécurité une fois, cela a bloqué nos intégrations pendant quelques jours. l’effet était différent cependant et cela a bloqué les intégrations dans l’autre sens, pas leur publication sur notre forum.
Bonne idée ! Sauriez-vous par hasard quel paramètre de sécurité a dû être modifié pour résoudre ce problème ?
J’ai effectué quelques modifications, donc je ne suis pas sûr de celle que je devrais annuler spécifiquement.
Aucune idée, je ne gère pas cette partie du site. J’ai dû appeler les personnes qui l’hébergent pour rétablir les paramètres de la politique de sécurité.
J’ai pu identifier la cause du problème ! J’ai contacté notre support géré de Discourse et ils m’ont fourni une adresse IP que nous avions précédemment ajoutée à une liste de blocage sur notre WAF, en raison d’un trafic élevé provenant de cette adresse. Il s’avère que cette adresse IP devait être autorisée pour que Discourse communique correctement. Je suis tellement content que ce ne soit pas un problème du côté de Discourse !
Je pense que je pourrais avoir le même problème. J’ai ces erreurs DOMException dans la console de développement de mon navigateur. Je n’utilise pas Cloudflare, cependant. Mon blog qui intègre l’iframe Discourse est hébergé par Netlify, Discourse lui-même par Communiteq.
J’ai d’abord pensé que ce changement était la cause du problème :
Mais je pense maintenant que c’est peut-être autre chose ? Toute aide serait appréciée.
Avez-vous accès aux paramètres de sécurité et/ou réseau de votre serveur sur Netlify ? D’après mon expérience récente, si j’étais à votre place, je vérifierais vos paramètres de sécurité pour voir si des adresses IP ont été bloquées. Je vérifierais également auprès du support de Communiteq, car ils pourraient être en mesure de confirmer l’adresse IP (ou les adresses IP) requise pour que votre serveur Netlify communique avec Communiteq afin d’exécuter avec succès les scripts nécessaires à l’affichage des ressources Discourse.
Je ne suis pas sûr de ce que je peux faire du côté de Netlify, mais je vais enquêter. Je doute que le problème vienne de là, car techniquement, les requêtes proviennent des navigateurs des visiteurs de mon site, n’est-ce pas ? Si je comprends bien comment cela fonctionne, et s’il vous plaît éclairez-moi si ce n’est pas le cas, il s’agit de JavaScript côté client exécuté dans le navigateur du visiteur du site. Discourse voit le nom d’hôte du serveur dans la requête, mais pas l’adresse IP. Mon serveur de blog ne communique pas avec le serveur du forum. C’est de toute façon une installation de blog statique. C’est juste du HTML avec du JavaScript côté client. Il utilise un script pour envoyer les données des articles de blog à Discourse et charger des éléments du forum dans un iframe.
Le problème était effectivement un bug dans la dernière version de Discourse. Communiteq le corrige sur mon instance de forum. Pour plus d’informations, voir ici :
Le problème abordé dans ce sujet concernait l’impossibilité pour Discourse d’afficher le « post complet » car le site intégré refusait de servir le contenu de l’article de blog à Discourse.
Le problème dans le sujet de @fabsh est le résultat d’un correctif de sécurité (plus récent) dans Discourse qui contient un bug.
Salut, je publie une mise à jour à ce sujet, car certaines choses ont changé dans mon enquête sur ce problème. Le problème persiste depuis la mise à jour vers la version 3.0.4 ; tous les nouveaux articles créés ont des problèmes d’affichage du code Discourse intégré. Tous les articles créés avant cette mise à jour ne posent aucun problème, ce n’est donc pas un blocage d’adresse IP qui en est la cause.
Il semble que Discourse, dans sa version la plus récente, ait modifié la logique de la façon dont les publications sont automatiquement créées par le code d’intégration, de sorte que le nouveau code nécessite désormais l’URL canonique. Voir le sujet précédemment lié :
Cependant, cela casse complètement la fonctionnalité d’intégration sur des sites comme le mien. J’utilisais auparavant l’ID de nœud dans Drupal pour l’intégration, comme on peut le voir dans le code ci-dessous :
Ce nouveau code Discourse nécessite l’utilisation de l’URL canonique à la place, ce qui entraîne la création de sujets en double si quelqu’un renomme simplement le titre de l’article. C’est la raison pour laquelle j’utilisais l’ID de nœud, car il ne change pas.
Serait-il possible de rendre cette nouvelle URL canonique facultative ? J’ai essayé de modifier mon code d’intégration pour l’utiliser, mais le problème de chargement est revenu pour toutes les publications créées avec l’ancien code d’intégration.
Ainsi, actuellement, avec le nouveau code Discourse exécuté sur mon site de production, je suis coincé avec l’une des deux options suivantes :
Les nouveaux articles sur Drupal affichent “Chargement…” mais ne chargent jamais le bloc d’intégration des commentaires ; les anciens articles créés avant Discourse 3.0.4 se chargent correctement.
Ou,
Les nouveaux articles sur Drupal chargent le bloc d’intégration des commentaires sans problème, mais tous les anciens articles créés avant Discourse 3.0.4 affichent “Chargement…” mais ne chargent jamais le bloc d’intégration des commentaires.
Y a-t-il un moyen de rendre cette nouvelle fonctionnalité facultative ? Devoir choisir entre l’une ou l’autre de ces options me met dans une situation perdant-perdant.
