9 Reaktionen zu “config.no_cache = 1 ist böse!”

Kommentare abonnieren (RSS) oder TrackBack URL

Oft möchten Entwickler ein pi1 gecacht haben aber nicht wenn ein Formular ausgefüllt wird.

Das Problem dabei ist, dass oft der cHash falsch gesetzt wird, dadurch setzt TYPO3 auf no_cache. Der cHash kann für ein Formular aber nicht richtig gesetzt werden, wenn dieses irgend eine individuelle eingabe zulässt.

Deswegen muss man dort mit einer TypoScript condition arbeiten, welche den Parameter abfragt und die Extension auf USER_INT setzt, wenn einer gesetzt ist. Sonst ist die Extension auf USER und damit im gesamtcache der Seite.

Beispielsweise ist felogin per default auf USER_INT, was den cache von vielen Seiten verlangsamt. Mit zwei drei Zeilen TypoScript kann man felogin aber perfekt als USER/vollgecachte ERweiterung einrichten, so dass im normalzustand (ohne eingabe) alles gecacht wird.

Das ist auch für static_file_cache wichtig.

Man sollte die alte Doku von Kaspar neu aufgreifen und komplett überarbeiten.

Hätte jemand lust? 😀

Jonas am 05. August 2009 um 12:50

Bei vielen Seiten hat man den Eindruck, dass no_cache=1 nur deswegen verwendet wird, da der cHash nicht richtig verstanden wurde. Ich habe dazu mal einen Artikel veröffentlicht: http://typo3-blog.net/tutorials/news/typo3-chash-usecachehash.html

Lina am 05. August 2009 um 14:19

Ich arbeite ganz gerne mit der Variante, den Cache auszuschalten wenn ich als BE User angemeldet bin:

[globalVar = TSFE : beUserLogin > 0]
config.no_cache = 1
[global]

Was hältst du davon?

paul am 18. August 2009 um 16:18

was soll das bringen außer probleme? dann sieht der redakteur ja erst recht wieder nicht so wie es der spätere User sieht und das ist ja der Sinn der Sache damit zu entwickeln – Fehler im Entstehen zu sehen und nicht danach

Georg Ringer am 18. August 2009 um 19:19

no_cache=1

Unter diesem Link wird ein Formular in 5 Schritten ausgefüllt. Über den internen „zurück“ Bottom komme ich auf die vorherige Seite ohne die Formulardaten zu verlieren.

Gehe ich über den Bottom „zurück“ des Browsers, verliere ich alle vorherigen Formulardaten.

Liegt das am no_cache=1 ????
Und wie kann ich das verhindern???

Martin am 30. August 2009 um 20:25

Ich schreibe nun schon seit einigen Jahren Erweiterungen für TYPO3 und hatte noch nicht ein einziges mal Probleme mit dem no_cache parameter. Warscheinlich hätte ich ohne diesen Parameter schon einen eingebrannten Mauszeiger über „Alle-Caches-Löschen“.
Wenn Ihr schon vor dem Parameter warnt, bitte ich doch um eine genauere Erklärung unter welchen TYPO3-Datenbank-Konstellationen diese „GBs pro Stunde Traffic“ entstehen sollen, wenn nicht „logging“ und/oder „debug“ im Install-Tool eingestellt ist.

mo am 10. Dezember 2010 um 11:13

Es lassen sich natürlich keine pauschalen Aussagen treffen, ab wann no_config=1 wirklich zum Verhängnis wird. In jedem Fall wird aber die Auslieferungszeit länger und je nach Aufwand für die Seitengenerierung und den Besucherzahlen das dauerhafte Nutzen des Parameters irgnedwann zum DoS.

Steffen Gebert am 10. Dezember 2010 um 12:50

@mo: es gibt USER_INT wenns nicht gecached werden darf.
ansonsten crasht die seite sofort wenn das drinnen ist und ein ansturm da ist. selber miterlebt auf nem guten hetzner-server bei einer kino-promotion seite. es soll nämlich wirklich seiten geben, die viel traffic haben 😉

@steffen: no_cache wird immer zum verhängnis sobald etwas traffic auf der seite ist, weils einfach spürbar langsamer wird. wenns eine 0815-seite ist mit 3 Besuchern im Monat, ist die Frage obs da überhaupt ein CMS oder TYPO3 braucht 😀

Georg Ringer am 10. Dezember 2010 um 13:01

config.no_cache = 1
Das war genau was ich gesucht hatte. Der ‚clear all cache‘ link im Backend hatte schon starke Abnutzungserscheinungen.
Teste gerade Typoscript Code für diverse Bilderelemente und stdWrap.wrap.override benimmt sich nicht so wie dokumentiert.

Gruß

Friedrich am 15. Februar 2014 um 23:03

Kategorien

Archiv