Wordpress Frontend Problem

[Nils Dornblut]

Die beschriebenen Deaktivbierungsmethoden sind aber nicht für dauerhaft brauchbar, weil damit auch der Browser Cache deaktiviert ist. Eigtl. reicht nach meiner Erfahrung die eine Anweisung aus, die Sie weiter oben nochmal angegeben haben. Das FAQ müsste da wohl noch überarbeitet werden.

Wir werden natürlich Erfahrungen einfließen lassen. Danke für den Hinweis. Insgesamt ist es natürlich abhängig davon was sie jeweils deaktivieren möchten.

Mit freundlichen Grüßen

Nils Dornblut

[ol9277]

Hallo zusammen,

Sinn und Zweck bzw. auch die Deaktivierung beschreiben wir nun hier in den FAQ:

https://www.df.eu/de/support/df-faq/64bit/neue-64-bit-tarife-bei-domainfactory/#c24136

Mit freundlichen Grüßen

Nils Dornblut

Die beschriebenen Deaktivbierungsmethoden sind aber nicht für dauerhaft brauchbar, weil damit auch der Browser Cache deaktiviert ist. Eigtl. reicht nach meiner Erfahrung die eine Anweisung aus, die Sie weiter oben nochmal angegeben haben. Das FAQ müsste da wohl noch überarbeitet werden.

[zero81]

Ok, hier ist plötzlich schon von zwei Dateien die Rede, die geändert werden müssen (user.ini + htaccess) und der Eintrag in der htaccess ist deutlich länger, als hier im Forum zuvor kommuniziert.
Also für mich wäre es optimal, wenn man das Caching einfach beim kompletten Tarif/Auftrag deaktivieren könnte, da ich sehr stark darauf angewiesen bin, dass Änderungen sofort sichtbar sind.

Nebenbei, hier fehlt wohl ein Wort: Zum Deaktivieren des OPcache ergänzen oder ändern Sie in...

[Nils Dornblut]

Hallo zusammen,

Sinn und Zweck bzw. auch die Deaktivierung beschreiben wir nun hier in den FAQ:

https://www.df.eu/de/support/df-faq/64bit/neue-64-bit-tarife-bei-domainfactory/#c24136

Mit freundlichen Grüßen

Nils Dornblut

[ol9277]

Hallo ol9277,
Sie können den Cache deaktivieren mit einer htaccess und folgendem Inhalt, wie Sie schon geschrieben haben:

Header always set Cache-Control: s-maxage=0

Nochmal eine Kurze Frage dazu. Dieser greift dann für alle Web-Ressourcen, richtig? Also sowohl Bilder, Videos, als auch HTML, CSS, JS etc.? Damit sollte ja das Browsercaching dann auch wieder sauber funktionieren. Mit der alten Anweisung war es ja dadurch auch deaktiviert. Aktuell haben wir gerade was an einer CSS machen müssen und warten gerde die 10 Minuten ab. Die Anweisung scheint ja dann wohl erst zu greifen, wenn die Cachedauer abgelaufen ist.

[Cangooou]

Ich würde gerne auf die neuen 64-Bit-Tarife umstellen, aber verstehe es noch nicht so ganz: Der Server speichert Seiten selbst zwischen. Jetzt habe ich eine Seite mit dem Text "Hallo Herr Meier" generiert und ausgeliefert, bekommt dann Herr Schneider, der sich kurz nach Herrn Meier einloggt, auch genau diese Seite zu sehen, weil sie unter der gleichen URL liegt?

[zero81]

Danke für die Rückmeldung. Ich habe auch mit diversen Hostingfirmen von Kunden zu tun, aber mir ist so eine Caching-Einstellung noch nie untergekommen. Bei der Arbeit mit Webseiten z.B. bei Änderungen kann ich mir nicht vorstellen, dass das irgendwie Sinn macht, da ich Änderungen natürlich sofort im Frontend sehen und kontrollieren möchte. Genauso wäre es bei den Kunden, die bislang selber Änderungen durchführen, Demnach müssten wir eine Menge htaccess Dateien anpassen, um beim gewohnten Verhalten zu bleiben. Naja, gut zu wissen, immerhin kann man es umgehen.

[Nils Dornblut]

Naja, für mich ist eigentlich jede Sekunde zu viel, die ich warten muss, bis sich eine Seite nach Änderungen aktualisiert. Ich hatte auch schon mit einigen anderen Hostinganbietern von Kunden zu tun, aber noch noch nie mit einem solchen NGINX-Cache oder ähnlichem.
D.h. diese Cache lässt sich nicht allgemein für einen ganzen Auftrag/Server deaktivieren?

Die von uns hier gewählten Einstellungen sind durchaus Standard und bieten an vielen Stellen Vorteile gerade bei hohen Aufrufzahlen von Webseiten. Generelle Deaktivierung ist so nicht möglich technisch bedingt. Es sollte jeweils bewusst entschieden werden, wenn man das machen möchte. Dies dann jeweils per htaccess. Natürlich beobachten wir den Einsatz bei unseren Kunden und Anpassungen für die Zukunft sind nicht ausgeschlossen. Dies mag auch generelle Konfigurationen beinhalten, die im Kundenmenü getroffen werden können.

Mit freundlichen Grüßen

Nils Dornblut

[zero81]

Naja, für mich ist eigentlich jede Sekunde zu viel, die ich warten muss, bis sich eine Seite nach Änderungen aktualisiert. Ich hatte auch schon mit einigen anderen Hostinganbietern von Kunden zu tun, aber noch noch nie mit einem solchen NGINX-Cache oder ähnlichem.
D.h. diese Cache lässt sich nicht allgemein für einen ganzen Auftrag/Server deaktivieren?

[Nils Dornblut]

Tritt dieses Caching Problem bei allen neuen Server-Tarifen auf (z.B. Reseller Dedicated L7) bzw. heißt das, ich muss bei allen Webseiten diesen Eintrag in der htaccess vornehmen, um das Caching zu deaktivieren?

Eigentlich ist das eher ein Feature um die Geschwindigkeit der Seiten zu erhöhen und sollte im Regelfall auch transparent sein, da sich der Content nach kurzer Zeit jeweils aktualisiert. Wenn Sie das nicht möchten, braucht es eine entsprechende Anweisung, das ist richtig.

Mit freundlichen Grüßen

Nils Dornblut

[zero81]

Tritt dieses Caching Problem bei allen neuen Server-Tarifen auf (z.B. Reseller Dedicated L7) bzw. heißt das, ich muss bei allen Webseiten diesen Eintrag in der htaccess vornehmen, um das Caching zu deaktivieren?

[Nils Dornblut]

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

Siehe mein Posting vorab, das kann mittlerweile beeinflusst werden.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Hallo ol9277,

in den Tarifen läuft aus Performancegründen ein NGINX Cache mit folgenden Standardwerten:

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

Sie können den Cache deaktivieren mit einer htaccess und folgendem Inhalt, wie Sie schon geschrieben haben:

Header always set Cache-Control: s-maxage=0

Dann ist den NGINX Cache deaktiviert.
Sie sollten allerdings schauen, dass sonst keine Header Cache-Control gesetzt ist, die das wieder überschreiben oder diesen an die erste Stelle setzten. Ich vermute, dass ist der Fall in dem Sinne aus Ihrem ersten Posting hier, da Sie damit das Caching beeinflussen und wenn Sie sagen, dass die Inhalte erst dann ablaufen, dann hält sich das System auch daran.

Mit freundlichen Grüßen

Nils Dornblut

[ol9277]

Gerde die Rückmeldung vom Support bekommen. Kann man via .htaccess erstmal beeinflussen:

Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"

Elemente fallen wohl jetzt bei Status 200 nach 2 Mi9nutne aus dem Cache, wenn diese nicht in dem Zeitraum aufgerufen worden.

[ol9277]

Gibt es hier neue Infos dazu?
Wir haben seit dem Wechsel nun ein ähnliches Problem mit einem Typo3 System. Es werden keinerlei Änderungen im Web wiedergespiegelt.
Die 10 Minuten Caching scheinen auch nicht zu stimmen, da diese vorbei sind aber immer noch im Response-Header: "x-cache-status: HIT" gemeldet wird.
Kann es sein das der Cache erst abläuft wenn das Expires Datum erreicht wird? Das steht zurzeit auf Oktober...