search

contao / core

Contao 3 → see contao/contao for Contao 4
GNU Lesser General Public License v3.0
490 stars 213 forks source link

cron weekly - purgeTempFolder fehlt #3605

Closed BugBuster1701 closed 12 years ago

BugBuster1701 commented 13 years ago

Ich hatte gerade folgenden Fall. 0:07 Uhr - weekly löscht die css und generiert diese neu. Man behalte im Hinterkopf, der Dateiname der kombinierten css Datei neu dabei ist. 0:14 Uhr - daily leert das tmp Verzeichnis und somit die gecachten Seiten.

Um 0:10 Uhr (also genau dazwischen) rief ich über die noch geöffnete Vorschau einer Seite auf die noch im Cache lag und bekam diese natürlich mit einem link auf eine css Datei die gar nicht mehr existierte.

Es bedarf also 2 Zugriffe auf die Seite bis alles wieder stimmt (wenn weekly startet beim ersten), wobei man beim zweiten Zugriff vorübergehend Müll sieht.

Ich schlage also vor einen dritten weekly Job zu definieren, nach updateStyleSheets:

$GLOBALS['TL_CRON']['weekly'][]  = array('Automator', 'purgeTempFolder');

--- Originally created on November 7th, 2011, at 12:40am (ID 3605)

BugBuster1701 commented 13 years ago

Nachtrag: dadurch wird zwar purgeTempFolder zweimal ausgeführt, aber besser das als einmal zuwenig.

--- Originally created on November 7th, 2011, at 12:43am

leofeyer commented 13 years ago

Generiert der Combiner nicht immer denselben Key wenn sich die Dateien nicht geändert haben?

--- Originally created on November 8th, 2011, at 08:32pm

BugBuster1701 commented 13 years ago

Hmm, laut Quelltext ja. Ich versuche das mal zu reproduzieren.

--- Originally created on November 10th, 2011, at 03:58pm

BugBuster1701 commented 13 years ago

Ich habe das nochmal nachgestellt: Eine Seite im Frontend aufgerufen. 5 Minuten gewartet. cron_weekly eine Woche zurückgestellt. Zur Zeit existiert Datei: 87116cb35c96.css Seite im Fontend aufgerufen. css wurde gelöscht durch weekly, keine kombinierte css wurde neu angelegt. Browser bekommt Seite mit link zu 87116cb35c96.css. Warum der Browser (mit abgeschaltetem Cache) die Seite trotzdem richtig anzeigt, ist mir hier grad ein Rätsel. Noch ein Frontend Aufruf: Nun erst wird die Datei 87116cb35c96.css angelegt.

Also, ja der Dateiname bleibt gleich, aber für einen Aufruf ist die kombinierte css nicht vorhanden. Führt nicht immer zu Problemen, kann aber passieren.

Irgendwie zeigt ein extra für die Aktion "cron start" anderer gestarteter Browser trotzdem die Seite OK an, obwohl die Datei system/scripts/87116cb35c96.css nicht existiert. Merkwürdig. Fordere ich die direkt an, kommt 404.

Edit: Jetzt wird mir das klar: Der Cron wird ja durch JS leicht verzögert aufgerufen, wenn der Browser schnell ist (ich teste lokal) bekommt er die css noch bevor der cron die löscht.

Ist der cron schneller mit seinem request als der der request der css, kommt es zu meinem ursprünglichem Problem. Ich konnte es zwar nicht nachstellen, aber logisch möglich ist es, und einmal sah ich es auch.

leo-unglaub commented 12 years ago

Ich kann das Problem bestätigen. Ich hatte jetzt auch des öfteren den Fall, dass meine gecachten (im contao cache) html seiten auf eine CSS Datei verwiesen haben, welche nicht mehr existiert.

BugBuster1701 commented 12 years ago

Ich hatte vorhin wieder den Fall, dass die CSS auf der Homepage OK waren, in den anderen Seiten (eigenes Layout) nicht. No active page for page ID "system", host "contao.glen-langer.de" and languages "de, en" (contao.glen-langer.de/system/scripts/e5e2cbb28a60.css)

Das könnte damit zusammenhängen: Die css Dateien werden auch gelöscht und die css neu angelegt (ohne die kombinierten), wenn man im Backend auf Einstellungen geht und ohne was zu ändern auf Save. (genau das hatte ich getan, mich ausgeloggt und meine FE Seiten kontrolliert)

Ausgelöst wird das durch den save_callback vom field debugMode. In der Methode regenerateScripts steht zwar "Regenerate the CSS scripts when the debug mode changes ", ist aber immer der Fall.

Die obige fehlende combinierte css ist die vom zweiten Layout. Also ich das alles nochmal nachstellte, wurde die beim Aufruf der entsprechende Seite angelegt. Die kombinierte css wird also erst angelegt, wenn nötig so scheint es. Richtig so?

Kann es sein, dass der combiner das ab und zu nicht tut, bzw. das nicht erkannt wird, das dies nötig ist ?

fbender commented 12 years ago

Zur ersten Vermutung / JS-Verzögerung: Ich würde vorschlagen, einfach ein sleep(1); (oder länger) zusätzlich beim Cron einzubauen, dass die Chance besteht, dass der Client die Daten noch bekommt, bevor sie gelöscht werden.

BugBuster1701 commented 12 years ago

Ob das was damit zu tun hat? Gibt ja noch ähnliche Fälle

3676#issuecomment-3282505

leofeyer commented 12 years ago

Behoben in 76d98b439d4db8ae8fa951b416e54d88a5dd7d66. Das Problem war, dass die Methode updateStyleSheets() auch die kombinierten CSS-Dateien entfernt hat, diese aber nicht wieder generiert wurden, wenn die Seite aus dem Cache geladen wird.

In Contao 3 würde ich vorschlagen, dass wir Assets (JS, CSS, Bilder) grundsätzlich mit Inserttag einfügen und diese nicht cachen. Auf diese Weise würden diese Dateien immer generiert wenn sie nicht vorhanden sind, auch wenn Seiten aus dem Cache geladen werden.

leofeyer commented 12 years ago

Als zusätzliche "Sicherheit" habe ich in der neuen Routine das tägliche Leeren des temporären Verzeichnis entfernt und eine monatliche Routine hinzugefügt, die alle drei Ordner (system/scripts, system/html und system/tmp) auf einmal löscht.