Wordpress Frontend Problem

[apophis82]

Hallo Leute!

Habe für eine Bekannte eine Wordpress Installation auf einem Basic df.eu Webhost erstellt und habe nun folgendes Problem. Wenn ich im Backend eine Seite oder einen Beitrag speichere funktioniert dies ohne Problem. Im Frontend wird mir der geänderte Inhalt erst nach 2 Minuten angezeigt, im Backend sofort. Hat dies irgendwas mit dem OPcache zu tun oder was kann ich hier tun? Plugins sind so gut wie keine installiert, und überhaupt keine Cache Plugins. Getestet habe ich es auch mit allen Plugins auf deaktiviert und mit dem WP Standard Theme. PHP Version 7.3 und 7.4. Wenn ich eine PHP Datei rauflade, dauert es auch 2 Minuten bis sich der Inhalt ändert, außer sie ist ganz neu. Kann mich wer aufklären?

Vielen Dank
LG

[Nils Dornblut]

Hallo apophis82,

das ist sehr seltsam. Es spricht für einen Cache. Wie ist das mit der PHP-Datei gemeint? Ist das bei jeder PHP-Datei reproduzierbar auch außerhalb von Wordpress?

Mit freundlichen Grüßen

Nils Dornblut

[horwie]

Hallo apophis82,

hast du den Tarif neu gebucht?

@DF: in den FAQ steht:

Dem Apache-Webserver ist eine nginx als Proxy und Caching-System vorgeschaltet. Dies bedeutet eine bessere Performance Ihrer Webseite. Bis Änderungen an Ihrer Webseite sichtbar werden, kann wegen des Cachings etwas mehr Zeit vergehen als in unseren 32-Bit-Tarifen.

Könnte das der Grund sein?

Gruß, horwie

[apophis82]

Ja danke, genau das ist es, sie hat den Tarif neu gebucht, habe das leider nicht gefunden. Ok, jetzt muss ich ihr das nur erklären

lg

[zero81]

Kann man das Caching-System deaktivieren? Stelle ich mir sehr nervig vor, wenn man immer einige Minuten warten muss.

[horwie]

Die 64-Bit Plattform ist neu bei DF und ich hoffe das dieser Effekt eher Bug denn Feature ist. Einige Minuten auf eine Änderung warten geht bei manchen Projekten gar nicht ...

[zero81]

Ja, das wäre auch bei uns nicht akzeptabel, falls wir den Tarif umstellen, wo wir nahezu täglich Änderungen auf Webseiten durchführen müssen.

[Nils Dornblut]

Ja, das wäre auch bei uns nicht akzeptabel, falls wir den Tarif umstellen, wo wir nahezu täglich Änderungen auf Webseiten durchführen müssen.

Ich lasse die Zusammenhänge einmal prüfen und wir melden uns dazu.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Hallo zusammen,

es ist richtig, dass dies durch den NGINX Cache verursacht wird. Dieser lässt sich aktuell noch nicht beeinflussen. Wir schauen aber, dass wir hierfür zukünftig eine Einstellmöglichkeit bereitstellen.

Das sind die aktuellen Werte:

HTTP Statuscode	Cachedauer
200/302	10 Minuten
404	1 Minute
301	5 Minuten

Mit freundlichen Grüßen

Nils Dornblut

[Funbug]

Das sollte dringend konfigurierbar sein. Bei unseren Kunden drehen ja sonst alle Redakteure am Rad, wenn die Änderungen nicht gleich sichtbar wäre. Contao 4.9 hat ein eingebautes Caching. Da brauche ich nicht noch einen NGINX-Cache davor.

[horwie]

Das muss konfigurierbar sein, denn 10 Min für Status 200 sind ewig ...

[masterframe]

Das muss konfigurierbar sein, denn 10 Min für Status 200 sind ewig ...

Laut Dokumentation sollte es für jeden selbst und individuell konfigurierbar sein ohne dass dF etwas machen müsste.

Parameters of caching can also be set directly in the response header. This has higher priority than setting of caching time using the directive.

• The “X-Accel-Expires” header field sets caching time of a response in seconds. The zero value disables caching for a response. If the value starts with the @ prefix, it sets an absolute time in seconds since Epoch, up to which the response may be cached.
• If the header does not include the “X-Accel-Expires” field, parameters of caching may be set in the header fields “Expires” or “Cache-Control”.
• If the header includes the “Set-Cookie” field, such a response will not be cached.
• If the header includes the “Vary” field with the special value “*”, such a response will not be cached (1.7.7). If the header includes the “Vary” field with another value, such a response will be cached taking into account the corresponding request header fields (1.7.7).

Processing of one or more of these response header fields can be disabled using the proxy_ignore_headers directive.

Siehe: https://nginx.org/en/docs/http/ngx_h...xy_cache_valid

[Nils Dornblut]

Das sollte dringend konfigurierbar sein. Bei unseren Kunden drehen ja sonst alle Redakteure am Rad, wenn die Änderungen nicht gleich sichtbar wäre. Contao 4.9 hat ein eingebautes Caching. Da brauche ich nicht noch einen NGINX-Cache davor.

Wir haben das vor konfigurierbar zu gestalten , da verrate ich sicher nicht zu viel. Es war aber kein Feature für die erste Iteration der Tarife. Wir bleiben da aber agil dran und reichen Änderungen nach.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Laut Dokumentation sollte es für jeden selbst und individuell konfigurierbar sein ohne dass dF etwas machen müsste.



Siehe: https://nginx.org/en/docs/http/ngx_h...xy_cache_valid

Soweit ich weiß geht das aktuell nicht. Wir müssen da noch Änderungen vornehmen, damit etwas beeinflussbar wird. Wie wir es genau machen, steht noch nicht fest, da gibt es mehrere Möglichkeiten.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Nachtrag: Ich habe die Meinungen bezüglich Konfigurierbarkeit NGINX auch noch intern einmal weitergegeben!