[Bug / Feature Request] Cache wird trotz Preview-Mode geschrieben

[FloB]

Hi zusammen,

ein Problem, das mich schon seit langem nervt: Wenn man grade ein (bereits sichtbares) Inhaltselement in der Vorschau anschauen möchte, wird diese Ansicht im Cache gespeichert. Wenn ich also jetzt feststelle, dass ich noch ein paar kleine Korrekturen vornehmen muss, dann muss ich erst in die Systemwartung gehen, ehe ich die Änderungen wieder betrachten kann.

Das Problem entsteht in FrontendTemplate.php, Zeile 136 ff. (r302): BE_USER_LOGGED_IN ist false, wenn man den "einfachen" Preview-Mode (also "Versteckte Elemente anzeigen" deaktiviert) nutzt. Das sollte IMO nicht so sein. Warum werde ich im FE als nicht im BE angemeldet angezeigt, obwohl ich das klar bin (sonst könnte ich ja die Vorschau nicht nutzen)?

Sollte die Variable dennoch richtig gesetzt sein, bitte ich darum den Check zu erweitern, dass bei der Vorschau niemals im Cache gespeichert wird. Das erspart dann viele unspezifische (sprich: Radikal-)Löschungen des gesamten Cache.

Sollte ich mit meiner Bitte alleine dastehen, bitte gut argumentieren, warum es so bleiben sollte wie bisher . Zustimmung ist natürlich gern gesehen .

[FloB]

Ach ja, Index:utputFromCache() müsste natürlich auch angepasst werden. Interessanterweise scheint $_SESSION['TL_USER_LOGGED_IN'] beim Login ins Backend auf true gesetzt, bei der nächster Aktion im BE aber wieder zurückgesetzt zu werden.

[deerwood]

Hi FloB,

ich konnte zumindest das von Dir beschriebene Verhalten nachvollziehen und ja, ich finde das auch sehr blöd, es erschwert die Arbeit der Redakteure ungemein, vor allem bei längeren Cache-Zeiten als wenigen Sekunden..

Ich konnte allerdings die eigentliche Ursache dafür nicht herausfinden, insbesondere, warum wird nicht gecachet, wenn unveröffentlichte Elemente angezeigt werden, kommen dann eventuell POST-Daten mit?.

Ich bin nicht sicher, ob Dein Ansatz, dass in der Vorschau BE_USER_LOGGED_IN=true sein sollte, richtig ist. Könnte es nicht sein, dass dann die Frontend-Anzeige anders aussieht als normal, je nach Erweiterungen, die da so laufen? Das überblicke ich gerade nicht. Aber man könnte eventuell irgendwelche Dummy-Post-Daten mitschicken, damit nicht gecachet wird?

Nebenbei: bei langen Cachezeiten hilft ein reines "nicht-cachen" auch nicht wirklich weiter, weil durch Zugriffe normaler Benutzer der Cache ja schon da sein kann. Viel sinnvoller wäre meines Erachtens, dass via Vorschau die jeweilige Cache-Datei GELÖSCHT werden würde! An der geannten Stelle in FrontendTemplate.php wird der Cache-Dateiname ja berechnet, das Löschen dort sollte also einfachst möglich sein. Ich finde, das wäre ein echt tolles neues Feature in TYPOlight, gezieltes Löschen des Caches. Was denkst Du?

Was mich aber wundert, warum machst Du kein Ticket auf dafür? Leo könnte das doch am schnellsten klären? Oder sollten wir erstmal einen Patch implementieren, damit das Ticket bessere Chancen hat, akzeptiert zu werden?

LG, Georg

[FloB]

Also soweit ich das jetzt verstanden habe, bewirkt "Versteckte Objekte anzeigen" genau das Setzen von BE_USER_LOGGED_IN auf true (somit ist der Konstantenname etwas ungenau). Wenn wir den Code jetzt einfach umbiegen würden, dass BE_USER_LOGGED_IN immer true ist, wenn der Aufrufende im Backend angemeldet ist, würde das einige Nebeneffekte haben (es würde immer alles angezeigt werden). Das wollen wir ja nicht …

Deswegen müsste da wohl ein zusätzlicher Check rein. Da bin ich eben über das $_SESSION['TL_USER_LOGGED_IN'] gestolpert, das allerdings auch eher inkonsistent auf true gesetzt wird. Somit fällt das auch erstmal raus, es sei denn, man ändert das Verhalten dieser Variablen. Auch mit $_POST kommen wir hier nicht weiter (das wird höchstens bei Formularen geschickt, sonst sind es normale GET-Requests).

Du hast Recht – "nicht in den Cache schreiben" allein hilft nicht, deswegen mein Zusatz im zweiten Post: Die index.php muss auch angepasst werden.
Ein prinzipielles Löschen der in der Vorschau angesehenen Seiten ist zwar eine nette Idee, halte ich aber für ein wenig zu breit gefächert. Du willst ja auch nicht immer alle Seiten aus dem Cache werfen, die du in der Vorschau ansiehst – vielleicht navigierst du ja einfach durch deine Seite und willst ein paar Sachen nachschauen (oder überhaupt erst zur problematischen Seite gelangen). Interessanter wäre IMO ein neuer Button, mit dem man den Cache-Eintrag der aktuell in der Vorschau angesehenen Seite löschen kann. Damit hat man die Kontrolle darüber, was gelöscht werden soll.
Eine Implementierung in FrontendTemplate.php ist vielleicht nicht die beste Idee, da diese Datei bei normalen Seitenaufrufen ebenfalls benutzt wird.

Da kommt mir grad noch eine Idee: Man könnte ein neues Cookie einführen (à la "TL_NOCACHE"), das das Caching umgehen lässt (ob das auch für normale FE-Nutzer zugelassen sein soll, müsste man überlegen). In der Preview-Leiste gibt es dann eine neue Checkbox / Selectbox, in der man auswählen kann, dass Caching deaktiviert werden soll.

[chris]

Also einen "Cache leeren" Button für die in der Vorschau betrachtete Seite fände ich ja mal echt richtig geil
Nicht nur dass man sich den Umweg über die Systemwartung und all die benötigten Erklärungen an Redakteure dazu ersparen könnte, sondern auch weil man nicht gleich das gesamte tmp Verzeichnis wegballern muss.

[deerwood]

Hallo FloB, chris,

Nur kurz: ja, AUSDRÜCKLICHES Löschen der Cache-Dateien per Button ist besser ... es sei denn, es gäbe einen einfachen Weg herauszufinden, ob die Vorschau-Seite (und/oder deren Artikel oder CE's) gerade geändert worden ist/sind. Dann würde ein Durchblättern in der Vorschau nicht unnötig Cache-Dateien löschen.

Ich brauche jetzt aber erstmal Zeit zum Verstehen des existierenden Codes.

LG, Georg

[FloB]

Selbst wenn wir einen Button zum expliziten Löschen einführen, würde es die Ausgangssituation dieses Threads nicht unbedingt verbessern: Es werden weiterhin Seiten in den Cache geschrieben, und bei jeder Änderung (und wenn ein Besucher auf der selben Seite landet, die ich bearbeite) muss ich nochmal den Button klicken, um den Cache zu löschen – nicht sonderlich bedienerfreundlich. Außerdem setzt man ja manchmal (ich zumindest ) darauf, dass eine Seite noch ein wenig im Cache verbleibt, bis der Besucher die neue Seite zu Gesicht bekommt – da kann man dann nochmal schnell ein paar Fehler ausmerzen.

[…] es sei denn, es gäbe einen einfachen Weg herauszufinden, ob die Vorschau-Seite (und/oder deren Artikel oder CE's) gerade geändert worden ist/sind. Dann würde ein Durchblättern in der Vorschau nicht unnötig Cache-Dateien löschen.

Kriegst du nicht vernünftig 'raus, dafür müsstest du die Datenbank nach allen Inhalten abfragen, da kannst du gleich das Caching sein lassen .