Versuch, die 10-minütige Verzögerung zu umgehen

[Lee_Ars]

Ich plane, das wp-discourse-Plugin auf einer Wettervorhersageseite am Golf von Mexiko zu verwenden, die normalerweise etwa 10.000 bis 20.000 Seitenaufrufe pro Tag verzeichnet, aber während extremer Wetterereignisse gelegentlich 1,5 bis 2 Millionen Seitenaufrufe pro Tag für etwa 500.000 bis 700.000 Besucher generiert. Die Website und ihre Hosting-Strategie wurden bereits bei mehreren extremen Wetterereignissen auf die Probe gestellt und funktionieren dank sorgfältiger Planung und viel Hilfe von Cloudflare auch unter Druck hervorragend.

Die Benutzer der Website sind an eine reibungslose Kommentarerfahrung mit nativen WordPress-Kommentaren gewöhnt. Daher wird es eine gewisse Umstellung geben (z. B. sie daran gewöhnen, auf den Link „Diskussion fortsetzen unter…“ zu klicken), auf die das Personal vor Ort vorbereitet ist.

Was sie jedoch nicht tolerieren werden, ist die variable 10-minütige Verzögerung zwischen dem Posten von Kommentaren und deren Anzeige auf der täglichen WordPress-Beitragsseite. Sie möchten, dass neue Kommentare (bis zum konfigurierten Limit) sofort auf der Homepage erscheinen, nachdem sie gepostet wurden, ähnlich wie native WP-Kommentare sofort nach dem Posten angezeigt werden.

Nachdem ich mit den integrierten Optionen herumgespielt hatte, um zu versuchen, Beiträge sofort anzeigen zu lassen, ohne dass das FastCGI-Caching von Nginx, WordPress oder das Browser-Caching neue Kommentare beim Aktualisieren nach dem Posten beeinträchtigen, habe ich die folgenden beiden MU-Plugins hinzugefügt, um dies zu mildern und neu gepostete Kommentare auf der WordPress-Seite beim Aktualisieren anzeigen zu lassen:

wp-discourse-transient-killer.php
wp-discourse-cache-header-fix.php

Dies hat mein Problem gelöst: Neue Beiträge zu von WordPress erstellten Discourse-Threads erscheinen jetzt sofort unter den WordPress-Beiträgen beim Aktualisieren.

Aber hier stoße ich an meine Kompetenzgrenzen – was breche/verpfusche/untergrabe ich, indem ich das tue?

Ich kümmere mich nicht besonders darum, zusätzliche Last auf meinem Webhost zu erzeugen, indem der Kommentar-Endpunkt von Besuchern, die die tägliche Wettervorhersageseite (mit eingebetteten Discourse-Kommentaren) aufrufen, bombardiert wird – das ist ein Problem, das ich durch Geldausgeben lösen kann. Meine Hauptanforderung ist es, zu vermeiden, dass 20.000+ Benutzer mir E-Mails schreiben und fragen, warum ihre Kommentare nicht sofort auf der Homepage erscheinen, wenn sie sie posten.

Ist das der richtige Ansatz? Ist das, was ich tue, klug? Verursacht es zusätzliche Sicherheits- oder Leistungsprobleme, die ich nicht vorhergesehen habe? Mache ich im Grunde alles kaputt, indem ich das tue?

Danke

[RGJ (Richard - Communiteq)]

Hmm, ich bin verwirrt, warum das funktioniert, denn

@angus

Die Aktion erhält die IDs der Wordpress-Beiträge, die vom Webhook aktualisiert wurden, als Argument, d. h.

do_action( 'wpdc_after_webhook_post_update', $post_ids );

Und Ihr Plugin

add_action( 'wpdc_after_webhook_post_update', function( $topic_ids ) {
    foreach ( (array)$topic_ids as $topic_id ) {
        delete_transient( 'wpdc_comment_html_' . $topic_id );
    }
}, 11 );

Vermischen Sie nicht die (Wordpress) $post_ids, die an die Aktion übergeben werden, mit der (Discourse) topic_id, die als Transient-Schlüssel dient?

Ich würde erwarten, dass Ihr Plugin so aussieht

add_action( 'wpdc_after_webhook_post_update', function( $post_ids) {
    foreach ( (array)$post_ids as $post_id ) {
        $topic_id = get_post_meta( $post_id, 'discourse_topic_id', true );
        delete_transient( 'wpdc_comment_html_' . $topic_id );
    }
}, 11 );

Andererseits sagen Sie, dass dies funktioniert?

[angus (Angus McLeod)]

Hallo @Lee_Ars, kannst du zuerst bestätigen, dass du den Webhook für Kommentare eingerichtet hast?

Configure WP Discourse Webhooks

You can use webhooks to sync data between Discourse and WordPress, and enrich your integration. Reply to this topic if you have questions about how to setup the webhooks, or how they work. Setup WP Discourse First setup an endpoint in WP Discourse: Navigate to WP Discourse > Webhooks in Wordpress admin. Select the endpoint(s) you want to enable (see below). Set a “Webhook Secret Key”, if it’s not already set. Click “Save Options”. Discourse Then create a new Webhook in Discourse (Go to /admi…

Das funktioniert so:

1. Es gibt einen neuen Beitrag in Discourse.
2. Eine Webhook-Nutzlast wird an Wordpress gesendet.
3. WP Discourse aktualisiert die Kommentaranzahl des Beitrags und setzt auch ein benutzerdefiniertes Beitragsfeld wpdc_sync_post_comments.
4. Wenn wpdc_sync_post_comments gesetzt ist, werden Discourse-Kommentare synchronisiert, wenn ein Wordpress-Beitrag geladen wird, unabhängig von der Synchronisierungsperiode (d. h. der 10-minütigen Verzögerung).

Bevor wir uns mit dem Caching befassen, möchte ich sichergehen, dass dies zuerst eingerichtet ist. Wenn ja, schalte vielleicht auch “Verbose Webhook Logs” ein und überprüfe, ob du Webhook-Anfragen erhältst, wenn ein neuer Beitrag in Discourse erstellt wird.

[Lee_Ars]

@angus

Hey @Lee_Ars, kannst du zuerst bestätigen, dass du das Webhook-Setup für Kommentare eingerichtet hast?

Hallo Angus! Das ist bejaht, die Option “Sync Comment Data” Webhook ist auf der WP-Seite aktiviert, und ich habe den Webhook auf der Discourse-Seite erstellt und Pings sind erfolgreich. Die Protokollierung des WP-Plugins zeigt comment.INFO: sync_comments.success-Nachrichten zu den richtigen Zeitstempeln:

[2025-07-07 14:16:38] connection.INFO: check_connection_status.successful_connection
[2025-07-07 14:16:38] connection.INFO: check_connection_status.valid_scopes
[2025-07-07 20:11:31] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 20:25:03] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 20:32:14] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 20:44:15] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 21:00:39] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 21:01:42] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 21:15:40] comment.INFO: sync_comments.success {"post_id":786}

Es ist nur so, dass selbst mit diesen Erfolgsmeldungen bestehende Besucher (oder zumindest ich, mehrfach getestet auf Firefox/Safari/Chrome auf einem Mac, Firefox/Chrome/Edge auf einem Win10 PC und Safari auf iOS) weiterhin einen gecachten /wp-json/wp-discourse/v1/discourse-comments-Endpunkt erhalten, mit cache-control-Headern, die auf einen nicht-null-Wert gesetzt sind. Wenn ich bei Chrome (oder dem Äquivalent in anderen Browsern) ein Strg-Umschalt-F5 mache, um den lokalen Cache beim Aktualisieren zu umgehen, funktioniert alles bestens und die neuen Beiträge erscheinen.

Mit den Mu-Plugins an Ort und Stelle zeigt dieser Endpunkt cache-control auf no-store no-cache usw. gesetzt, und das problematische Verhalten tritt nicht auf – einfach nur das Besuchen des WP-Beitrags oder das Aktualisieren mit der normalen Aktualisierungstaste zeigt neue eingebettete Kommentare.

Ich habe die ausführliche Webhook-Protokollierung aktiviert und einen Testbeitrag gepostet, und die Dinge scheinen in Ordnung zu sein, wenn ich einen neuen Beitrag erstelle:

webhook_topic.INFO: update_topic_content.update_post_metadata_success {"post_ids":"786"}

Alles scheint zu funktionieren, aber ich verstehe immer noch nicht wirklich, warum das ursprüngliche problematische Verhalten aufgetreten ist oder ob es aus einem übersehenen Problem meinerseits entstanden ist. (Sehr gut möglich!)

@RGJ

Hmm, ich bin verwirrt, warum das funktioniert…

D’oh, Entschuldigung, ich bin sicher, du hast Recht, dass ich das vermasselt habe – gestern war ein langer Tag, und wie gesagt, ich bin hier an der Grenze meiner Fähigkeiten. Es hat definitiv etwas getan, obwohl ich jetzt frage mich, ob das “behobene” Verhalten, das ich sehe, nur ist, dass es auf eine neue Weise kaputt ist. (Ich habe das “transient killer”-Plugin aktualisiert, um jetzt das richtige Argument zu verwenden, danke!)

[angus (Angus McLeod)]

Danke, nur noch eine Sache zur Klärung. Ist diese WP Discourse-Einstellung (unter „Kommentare“) aktiviert?

[Lee_Ars]

Ich habe beides ausprobiert, mit und ohne aktivierter Einstellung Cache Comment HTML, und es scheint keinen Einfluss auf das problematische Verhalten zu haben. Ich habe sie derzeit deaktiviert, kann sie aber für die Fehlerbehebung auf alles setzen, was hilfreich sein könnte.

[RGJ (Richard - Communiteq)]

Wenn die Einstellung deaktiviert ist, werden Sie die Vermischung von topic_id / post_id nicht bemerken, da dieses Plugin in diesem Fall nichts tut.
Kein Caching –

Wenn die Einstellung aktiviert ist, sollten Sie bemerken, dass das Plugin nicht richtig funktioniert.

D. h., wenn Sie Fehler beheben möchten, sollten Sie die Einstellung aktivieren.

[angus (Angus McLeod)]

Ok, als erste Maßnahme für Ihren Fall würde ich Folgendes vorschlagen:

1. Deaktivieren Sie die Kommentar-HTML-Zwischenspeicherung (Cache Comment HTML); und
2. Entfernen Sie das Plugin https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt, da es derzeit nichts tut, wie Richard feststellt.

Wenn das das Problem nicht löst, liegt das Problem bei einer anderen Form der Zwischenspeicherung. Die nächsten Fragen, die beantwortet werden müssen, sind:

1. Welche Caching-Lösungen verwenden Sie (und/oder Ihr Hosting-Anbieter) für WordPress?
2. Wenn https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt das Problem behebt, wie macht sein spezifisches Verhalten den/die in 1 angewendeten Cache(s) ungültig?

Wenn ich mir wp-discourse-cache-header-fix ansehe, stelle ich fest, dass eine der Korrekturen für load-comments.js ist. Haben Sie diese Einstellung aktiviert?

[Lee_Ars]

@angus

Welche Caching-Lösungen verwenden Sie (und/oder Ihr Hosting-Provider) für WordPress?

Dies ist ein selbst gehostetes WP auf nginx+php-fpm 8.3 mit nginx Fast-CGI-Caching für dynamische Inhalte und Redis-Objekt-Caching (mit dem aktiven Object-Cache-Drop-in). Es gibt keine weiteren Ebenen (kein CDN, kein CF, kein lokales Varnish oder anderer lokaler Cache über den Fast-CGI-Cache von nginx hinaus). Das Leeren des nginx Fast-CGI-Caches (aggressiv, durch Ausführen von rm -rf /etc/nginx/cache/*) hat keine Auswirkung auf das problematische Verhalten – es werden weiterhin veraltete Ergebnisse geliefert, selbst nachdem das Cache-Verzeichnis geleert und sowohl nginx als auch php-fpm neu gestartet wurden.

Ich habe derzeit das Laden von Ajax-Kommentaren aktiviert, aber auch hier hatte das Deaktivieren (und das Leeren des nginx-Caches sowie das Neustarten von nginx und php-fpm zur Sicherheit) keine Auswirkung auf das problematische Verhalten. Browser lieferten weiterhin veraltete Kommentare.

@angus

Ok, als erste Maßnahme für Ihren Fall würde ich vorschlagen:

1. Halten Sie “Cache Comment HTML” deaktiviert; und
2. Entfernen Sie das Plugin https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt, da es derzeit nichts tut, wie Richard beobachtet.

Option umgeschaltet, Transient-Killer entfernt. Keine Änderung des problematischen Verhaltens.

@angus

Wenn https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt das Problem behebt, wie macht sein spezifisches Verhalten die Caches, die in 1 angewendet werden, ungültig?

Die von ihm angewendete Wirkung scheint das Bereitstellen eines cache-control-Headers mit no-cache anstelle eines Headers mit einer angegebenen Cache-Zeit zu sein. Ohne ihn scheint mein Browser sehr darauf bedacht zu sein, eine veraltete, gecachte Version des Endpunkts wp-json/wp-discourse/v1/discourse-comments aus seinem Festplattencache zu liefern; wie bereits erwähnt, muss ich Shift-Strg-F5 (oder das Äquivalent) drücken, um einen No-Cache-Refresh zu erzwingen.

Das problematische Verhalten scheint eher auf der Browserseite zu liegen als in einem persistenten Server-Cache. Es ist einfach jeder Browser auf jedem Betriebssystem, auf das ich Zugriff habe, der dies tut.

[angus (Angus McLeod)]

Ok. Nur damit ich zu 100 % sicher bin. Wenn Sie haben

• Verifizierter funktionierender Kommentar-Webhook
• Kommentar-HTML-Cache aus
• AJAX-Laden aus
• kein CDN
• kein CloudFront
• kein WordPress-Caching-Plugin
• keine relevanten Warnungen oder Fehler in den PHP-Protokollen

sind Sie sicher, dass es nicht funktioniert?

Wenn es mit dieser Konfiguration nicht funktioniert, bin ich ohne genauere Untersuchung etwas ratlos und würde standardmäßig auf

• AJAX-Laden ein
• Ihre wp-discourse-cache-header-fix.php-Korrekturen

was ich vermute, für Sie funktioniert hat. Wenn dieser Weg funktioniert, sollten Sie diesen wählen.

[Lee_Ars]

@angus

Ok, nur damit ich 100% klar bin, wenn Sie haben:

• funktionierenden Kommentar-Webhook verifiziert
• Kommentar-HTML-Cache deaktiviert
• AJAX-Laden deaktiviert
• kein CDN
• kein Cloudfront
• kein WordPress-Caching-Plugin
• keine relevanten Warnungen oder Fehler in den PHP-Protokollen

Hier ist eine schnelle Imgur-Galerie mit Screenshots meiner aktuellen Plugin-Einstellungen als Referenz.

Bestätigen Sie kein CDN, kein Cloudfront oder Cloudflare, keine Caching-Plugins außer dem Nginx-Helfer (um WP beim Invalidieren des Nginx fast-cgi-Caches nach Bedarf zu unterstützen).

Bestätigen Sie auch, dass in den PHP-FPM- oder Nginx-Fehlerprotokollen nichts Relevantes vorhanden ist.

Sie sind sich sicher, dass es nicht funktioniert?

Gott, Mann, ich wünschte, es wäre so. Ich schlage mich jetzt seit etwa 30 Stunden damit herum, mit etwas Schlafpausen. Ich werde vielleicht ein wenig schielend, heh.

[angus (Angus McLeod)]

Ja, ich verstehe. Mach ruhig einen Tag Pause oder so. Ich werde versuchen, das Problem morgen zu reproduzieren, indem ich dein Setup kopiere.

[Lee_Ars]

Wenn ich mich nicht mit Händen und Füßen zu einer Lösung durchkämpfe, und wenn Sie möchten, gewähre ich gerne einen temporären lokalen Zugriff (auf den WP-Blog, den Diskurs und/oder die zugrunde liegenden Hosts) zur Fehlerbehebung. Ich versuche definitiv nicht, kostenlose Arbeit zu bekommen oder so. Ich würde gerne für Ihre Dienste bezahlen, wenn hier tatsächlich Zeit aufgewendet werden muss.

[angus (Angus McLeod)]

Ok, hier ist ein Video von mir, wie ich versuche (und scheitere), Ihr Problem zu reproduzieren:

Setting Up WordPress With Discourse Discussion Forum Software

Als Nächstes möchte ich, dass Sie diesen Filter ausprobieren.

@angus

wpdc_comment_sync_period

Legen Sie die Synchronisierungsperiode für Kommentare in Sekunden fest. Standard ist 600, d. h. 10 Minuten.

Beispiel

Legen Sie die Synchronisierungsperiode auf 5 Minuten fest.

function custom_comment_sync_period( $minutes, $post_id ) {
  return 300;
}
add_filter( 'wpdc_comment_sync_period', 'custom_comment_sync_period', 10, 2);

[Lee_Ars]

Danke, @angus – dass es nicht reproduzierbar ist, beruhigt mich sehr, denn das bedeutet, dass ich etwas falsch mache und nicht, dass tatsächlich etwas falsch ist

Ich werde diesen Filter heute hinzufügen, wenn ich Zeit zum Fehlerbeheben habe, und melde mich dann wieder

[Lee_Ars]

Einen Monat und etwas später antworte ich, um den Kreis zu schließen – ich erlebe immer noch einige seltsame Dinge bei der Bereitstellung in der vollständigen Produktion (Prod-Website, Beispiel-Prod-Website-Post mit Discourse-Einbettung, tatsächliches Discourse-Forum), aber es ist alles beherrschbar. Ich werde alle verbleibenden Latenz-/Verzögerungsprobleme auf die komplexe Schichttorte aus Wordpress + Discourse + Cloudflare und meine aggressive Caching-Strategie zurückführen, um all diese Dinge während Verkehrsspitzen, die sich aus tatsächlichen Stürmen ergeben, betriebsbereit zu halten.

Vielen Dank, dass Sie sich die Zeit genommen haben zu antworten, @angus <3

[Lee_Ars]

Entschuldigung, dass ich das schon wieder hochhole, aber ich wollte ein Update geben und berichten, dass ich die Ursache des Problems gefunden habe! Und es war wie üblich meine eigene verdammte Schuld.

Ganz kurz: Ich speichere gängige PHP-Standortblockdetails in einem Snippet unter /etc/nginx/snippets/, damit ich sie in mehreren vhost-Dateien einbinden kann, ohne sie jedes Mal duplizieren zu müssen. Es ist schon eine seeeehr lange Zeit (wahrscheinlich Jahre) her, seit ich dieses Snippet überprüft habe, und siehe da, da war ein überflüssiges add_header Cache-Control "public, max-age=7200"; darin, das auf alles angewendet wurde, was aus diesem Standortblock kam.

Also habe ich es entfernt, alle Cache-Ebenen geleert, und siehe da, das problematische Verhalten verschwand.

Vielen Dank nochmals, dass du dir die Zeit genommen hast, mit mir zusammenzuarbeiten, @angus, auch wenn sich dies wieder einmal als ein weiteres Discourse-Problem meinerseits herausstellte