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.
Option umgeschaltet, Transient-Killer entfernt. Keine Änderung des problematischen Verhaltens.
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.