Discourse-Kommentare bleiben bei "Loading..." hängen

Hallo,

In den letzten Tagen haben wir in unserem Discourse festgestellt, dass die Schaltfläche „Vollständigen Beitrag anzeigen“ beim Klicken auf „Wird geladen…“ bleibt:

Zusätzlich werden neue Discourse-Kommentare aus unserem Embed auf unserer Drupal-Website nicht mehr angezeigt. Wir verwenden seit Jahren erfolgreich die JavaScript-Embed-Anweisungen von unten:

Aus irgendeinem Grund scheint dies jedoch in letzter Zeit nicht mehr zu funktionieren. Ich glaube, der letzte funktionierende Beitrag war um den 1. dieses Monats. Ältere Beiträge werden in Discourse und im Embed-Modul angezeigt, aber in neueren Artikeln hängt der Discourse-Block nur beim Text „Wird geladen…“.

Unser Discourse Drupal-Modul wird aus dem folgenden Code geladen:

<div id="discourse-comments">
 <script type="text/javascript">
            var discourseUrl = "https://discourse.sitename.com/",
            discourseEmbedUrl = "http://sitename.com/node/' . $nid . '";

            (function() {
              var d = document.createElement("script"); d.type = "text/javascript"; d.async = true;
              d.src = discourseUrl + "javascripts/embed.js";
              (document.getElementsByTagName("head")[0] || document.getElementsByTagName("body")[0]).appendChild(d);
            })();
          </script>
 </div>

Ich habe bestätigt, dass die Datei „javascripts/embed.js“ noch am selben Pfad existiert.
Dies ist der Block, der auf Artikel-Seiten angezeigt wird; er zeigt in letzter Zeit nur „Diskussion wird geladen…“ an:
image

Wir haben in den letzten Jahren keine Änderungen an unserem Discourse-Embed oder Setup vorgenommen. Gab es kürzlich Änderungen an der Discourse-Funktionalität, die dies beeinträchtigen würden? Jede Hilfe bei der Behebung dieses Problems wäre sehr willkommen!

2 „Gefällt mir“

wir verwenden die gleiche Einbettungsfunktionalität auf unserer Website. Ich gehe davon aus, dass discourseUrl und discouseEmbedUrl nicht das sind, was Sie oben gepostet haben, sondern stattdessen die relevanten URLs Ihres Forums?

Andernfalls sieht der Code in Ordnung aus. Ich weiß, dass die Einbettungsfunktionalität für das aktuelle Discourse-Beta funktioniert. Wir hatten letzte Woche eine Menge eingebetteter Beiträge. Ich finde es seltsam, dass der erste Teil des Beitrags eingebettet wird, aber der Button “Vollständigen Beitrag anzeigen” nicht funktioniert. Unsere laden sofort :thinking:

Haben Sie die Konsole auf Fehler überprüft?

Sie könnten immer versuchen, die Einstellung embed_truncate zu deaktivieren, nur um zu sehen, ob der gesamte Text gepostet wird. Das könnte helfen, die Ursache des Problems einzugrenzen.

Haben Sie kürzlich Themes aktualisiert oder geändert? Oder meinen Sie wirklich, dass Sie seit Jahren nichts aktualisiert haben?

1 „Gefällt mir“

Ja, das ist richtig, ich habe den Platzhalter „sitename“ nur zur Verdeutlichung verwendet.
Verdammt, es ist eine Erleichterung, dass die Discourse-Einbettungsfunktionalität anscheinend nicht kaputt ist! Es muss etwas auf unserer Seite sein.

Ich habe die Discourse-Logs (discourse.sitename.com/logs) überprüft und sehe nur eine Menge Deprecation-Hinweise wie unten:

Deprecation notice: SiteSetting.enable_personal_messages has been deprecated.

Ich kann auf jeden Fall versuchen, das „embed_truncate“ zu deaktivieren, danach werde ich als Nächstes suchen. Aber diese Funktionalität funktionierte jahrelang ohne Probleme, daher bin ich mir nicht sicher, warum sie kaputt gehen sollte…

2 „Gefällt mir“

Versuchen Sie, die Entwicklerkonsolen auf Fehler zu überprüfen, wenn Sie auf die Schaltfläche „Vollständigen Beitrag anzeigen“ klicken. Die Entwicklertools können über einen Rechtsklick und „Untersuchen“ aufgerufen werden. Die Fehler werden auf der rechten Seite in roter Schrift angezeigt.

Ja, die Einbettungsfunktion ist definitiv nicht kaputt. Bei meiner Website tritt dies mehrmals täglich auf.

Die neueste Betaversion ist Discourse 3.1.0.beta4, die stabile Version ist 3.0.3: Security and bug fix release

2 „Gefällt mir“

Ich glaube, unser Setup ist verwaltet; ich habe keine Änderungen daran vorgenommen, aber unser Discourse-Dashboard zeigt als letztes Update-Datum für Discourse den 18. April an. Wenn ich mir die neueste Ankündigung ansehe, die damit verknüpft ist, scheint es sich um 3.0.3 zu handeln.

1 „Gefällt mir“

Stellen Sie sicher, dass Sie auch die neueste Discourse-Version ausführen. Es könnte sich auch lohnen zu prüfen, ob dasselbe im abgesicherten Modus passiert.

Das ist ein guter Einwand, danke! Ich habe gerade nachgesehen und sehe diesen Fehler:

Uncaught DOMException: An invalid or illegal string was specified

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

Es ist so seltsam, weil ich nichts am Code oder irgendetwas kürzlich geändert habe. Ich erinnere mich jedoch, dass ich am 2. dieses Monats Cloudflare verwendet habe, um die Sicherheit zu erhöhen. Ich muss vielleicht nach etwas auf dieser Seite suchen, das Skripte blockieren könnte.

Ich habe beim letzten Mal, als ich das überprüft habe, einen CSP-Fehler in der Entwicklerwerkzeugkonsole gesehen, vielleicht könnte das das Problem sein, möglicherweise auf der Seite von Cloudflare.

1 „Gefällt mir“

Ich vermute, dass dies damit zusammenhängt.

Ich weiß, dass, als unsere übergeordnete Website ihre Online-Inhaltsrichtlinien und Sicherheitseinstellungen einmal bearbeitete, unsere Einbettungen für ein paar Tage blockiert wurden. Die Auswirkung war jedoch anders und blockierte die Einbettungen in die andere Richtung, nicht das Posten in unserem Forum.

1 „Gefällt mir“

Gute Idee! Wissen Sie zufällig, welche Sicherheitseinstellung geändert werden musste, um dies zu beheben?
Ich habe ein paar Änderungen vorgenommen und bin mir nicht sicher, welche ich genau rückgängig machen soll.

Keine Ahnung, ich verwalte diesen Teil der Website nicht. Ich musste die Leute anrufen, die sie hosten, um die Sicherheitseinstellungen zurückzusetzen.

Ja, etwas ist nicht sehr glücklich über das Klicken dieses Buttons.

Ich konnte herausfinden, was das Problem war! Ich hatte mich an unseren verwalteten Discourse-Support gewandt und sie gaben mir eine IP-Adresse, die wir zuvor auf unserer WAF auf eine Blockierliste gesetzt hatten, aufgrund eines hohen Verkehrsaufkommens von dieser Adresse. Es stellte sich heraus, dass diese IP-Adresse zugelassen werden musste, damit Discourse richtig kommunizieren konnte. Ich bin so froh, dass es kein Problem auf Seiten von Discourse war!

5 „Gefällt mir“

Ja, ein wenig klingt das ähnlich wie das Problem, auf das ich gestoßen bin. Schön, dass Sie es beheben konnten :slight_smile:

2 „Gefällt mir“

Ich glaube, ich habe möglicherweise dasselbe Problem. Ich habe diese DOMException-Fehler in der Entwicklerkonsole meines Browsers. Ich verwende jedoch kein Cloudflare. Mein Blog, der den Discourse-Iframe einbettet, wird von Netlify gehostet, Discourse selbst von Communiteq.

Ich dachte zuerst, diese Änderung würde das Problem verursachen:

Aber jetzt glaube ich, es könnte etwas anderes sein? Jede Hilfe wäre willkommen.

Haben Sie Zugriff auf die Sicherheits- und/oder Netzwerkeinstellungen von Ihrem Server auf Netlify? Aus meiner jüngsten Erfahrung würde ich, wenn ich in Ihren Schuhen stecken würde, Ihre Sicherheitseinstellungen überprüfen, um zu sehen, ob IP-Adressen blockiert wurden. Ich würde dies auch noch einmal mit dem Communiteq-Support überprüfen, da diese Ihnen möglicherweise die IP-Adresse(n) bestätigen können, die erforderlich sind, damit Ihr Netlify-Server mit Communiteq kommunizieren kann, um Skripte erfolgreich auszuführen, die zur Anzeige von Discourse-Ressourcen benötigt werden.

1 „Gefällt mir“

Hallo! Danke, dass Sie versuchen zu helfen!

Ich habe mich an Communiteq gewandt.

Ich bin mir nicht sicher, was ich auf der Netlify-Seite tun kann, aber ich werde es untersuchen. Ich bezweifle jedoch, dass das Problem dort liegt, denn technisch gesehen kommen die Anfragen von den Browsern der Besucher meiner Website, oder? Wenn ich richtig verstehe, wie das funktioniert, und bitte klären Sie mich auf, wenn nicht, dann ist das clientseitiges JavaScript, das im Browser des Website-Besuchers ausgeführt wird. Discourse sieht den Hostnamen des Servers in der Anfrage, aber nicht die IP. Mein Blog-Server kommuniziert nicht mit dem Forum-Server. Es handelt sich sowieso um eine statische Blog-Installation. Es ist nur HTML mit clientseitigem JavaScript. Es verwendet ein Skript, um die Blog-Post-Daten an Discourse zu senden und stuff aus dem Forum in einem iFrame zu laden.

1 „Gefällt mir“

Das Problem war tatsächlich ein Fehler in der neuesten Discourse-Version. Communiteq behebt ihn in meiner Foreninstanz. Weitere Informationen finden Sie hier:

Bitte beachten Sie, dass dieses Problem ein anderes ist.

Das Problem in diesem Thema betraf die Unfähigkeit von Discourse, “Vollständigen Beitrag anzeigen” auf Discourse anzuzeigen, da die eingebettete Website sich weigerte, den Inhalt des Blogbeitrags an Discourse zu liefern.

Das Problem in @fabshs Thema ist das Ergebnis eines (aktuelleren) Sicherheitspatches in Discourse, der ein Problem enthält.

3 „Gefällt mir“

Hallo, ich poste ein Update dazu, da sich einige Dinge bei meiner Untersuchung dieses Problems geändert haben. Das Problem besteht seit dem Update auf 3.0.4; alle neu erstellten Artikel haben Probleme bei der Anzeige des eingebetteten Discourse-Codes. Alle Artikel, die vor diesem Update erstellt wurden, weisen keine Probleme auf, sodass keine IP-Adressensperre die Ursache dafür ist.

Es scheint, dass Discourse in der neuesten Version die Logik geändert hat, wie Beiträge automatisch durch den Einbettungscode erstellt werden, sodass der neue Code nun die kanonische URL benötigt. Siehe das zuvor verlinkte Thema:

Dies beeinträchtigt jedoch die Einbettungsfunktionalität auf Websites wie meiner vollständig. Ich habe zuvor die Node-ID in Drupal zum Einbetten verwendet, siehe den unten stehenden Code:

discourseEmbedUrl = "http://sitename.com/node/' . $nid . '";

Dieser neue Discourse-Code erfordert stattdessen die Verwendung der kanonischen URL, was zur Erstellung doppelter Themen führt, wenn jemand einfach den Artikelnamen umbenennt. Deshalb habe ich die Node-ID verwendet, da sie sich nicht ändert.

Wäre es möglich, diese neue kanonische URL optional zu machen? Ich habe versucht, meinen Einbettungscode zu ändern, um sie zu verwenden, aber das Lade-Problem trat für alle mit dem alten Einbettungscode erstellten Beiträge wieder auf.

Mit dem neuen Discourse-Code, der auf meiner Produktionsseite läuft, stecke ich also entweder in einer der folgenden beiden Optionen fest:

  • Neu erstellte Artikel in Drupal zeigen “Laden…” an, laden aber nie den Kommentare-Einbettungsblock; alte Artikel, die vor Discourse 3.0.4 erstellt wurden, laden einwandfrei.

Oder,

  • Neu erstellte Artikel in Drupal laden den Kommentare-Einbettungsblock einwandfrei, aber alle alten Artikel, die vor Discourse 3.0.4 erstellt wurden, zeigen “Laden…” an, laden aber nie den Kommentare-Einbettungsblock.

Gibt es eine Möglichkeit, diese neue Funktion optional zu machen? Die Wahl zwischen diesen beiden Optionen bringt mich in eine Art Lose-Lose-Situation.

2 „Gefällt mir“