Cronjob Cache löschen per dcaconfig.php deaktivieren

[okapi]

Weiß jemand, wie man den Cronjob für das tägliche Leeren des Cache-Verzeichnisses sytem/tmp in der Datei dcaconfig.php deaktiviert?
Mein Versuch mittels:

$GLOBALS['TL_CRON']['daily']['Automator']['purgeTempFolder'] = false;

hat keinen Erfolg gebracht, offensichtlich ist die Syntax falsch. Weiß jemand Rat?

Gruß
Michael

[Sebastian]

HI

aus welcher Datei hast du dir das denn abgeschaut?

Sebastian

[BugBuster]

aus /system/modules/backend/config/config.php
Original Inhalt ist:

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

Man müste also ein Eintrag des Arrays entfernen um zum Ziel zu kommen.

[leo]

foreach ($GLOBALS['TL_CRON']['daily'] as $k=>$v) {
   if ($v[1] == 'purgeTempFolder') {
    unset($GLOBALS['TL_CRON']['daily'][$k]);
  }
} 

[okapi]

Das ist doch etwas komplexer als ich gedacht habe!
Vielen Dank!

Gruß
Michael

[okapi]

foreach ($GLOBALS['TL_CRON']['daily'] as $k=>$v) {
   if ($v[1] == 'purgeTempFolder') {
    unset($GLOBALS['TL_CRON']['daily'][$k]);
  }
} 

Leider hat das nicht funktioniert. Ich hab den Code genau so in die dcaconfig.php geschrieben. Aber heute morgen wurden wieder alle Dateien im Cache-Verzeichnis system/tmp überschrieben.

Gruß
Michael

[deerwood]

Hi okapi,

Leider hat das nicht funktioniert. Ich hab den Code genau so in die dcaconfig.php geschrieben. Aber heute morgen wurden wieder alle Dateien im Cache-Verzeichnis system/tmp überschrieben.

Ich glaube, der Code müsste so aussehen:

foreach ($GLOBALS['TL_CRON']['daily'] as $callback) {
    if ($callback[1] == 'purgeTempFolder') {
        unset($GLOBALS['TL_CRON']['daily'][$callback]);
    }
} 

Habe ich aber nicht getestet, sondern nur den Code in cron.php angeschaut.

LG Georg

[okapi]

Hallo Georg,

danke für den Tipp, ich probier's mal aus!
Bin gespannt...

Gruß
Michael

[deerwood]

Oops, ich bin blöd! Kommando zurück!!! Leo weiß eben doch, was er tut. Mein Code führt zu einem Warning und löscht den Eintrag nicht aus dem Array, Leos Code funktioniert perfekt.

Sorry für die Konfusion,
LG, Georg

[okapi]

Wie gesagt, gestern hat Leos Code für mich nicht funktioniert, der Cache-Ordner wurde wieder geleert. Ich versuchs halt nochmal und warte auf morgen.

Gruß
Michael

[deerwood]

Hallo alle,

auf meiner TL 2.7.5 Test-Installation habe ich noch mal getestet (mit echo Debugging, nicht geeignet für ein laufendes System) und bin zu folgendem Schluss gekommen:

Leos Code in dcaconfig.php wirkt sich im Backend aus, aber NICHT wenn man cron.php aufruft! Dann scheint dcaconfig.php nicht gelesen zu werden.

Wenn ich Leos Code aber in localconfig.php unterbringe, dann wirkt er auch in cron.php. Ich habe den Code vor der Kommentarzeile "### INSTALL SCRIPT START ###" untergebracht und hoffe, das ist der richtige Platz dafür?

Wenn ich also richtig liege, müsste Leos for-Schleife in localconfig.php untergrbracht werden.

Vielleicht kann jemand nochmal etwas Licht auf die Bedeutung der Dateien in system/config werfen, welche sind updatesicher und wofür sind sie zuständig (Frontend/Backend)?

LG, Georg

[okapi]

Leos Code in dcaconfig.php wirkt sich im Backend aus, aber NICHT wenn man cron.php aufruft! Dann scheint dcaconfig.php nicht gelesen zu werden.

Wenn ich Leos Code aber in localconfig.php unterbringe, dann wirkt er auch in cron.php. Ich habe den Code vor der Kommentarzeile "### INSTALL SCRIPT START ###" untergebracht und hoffe, das ist der richtige Platz dafür?

Wenn ich also richtig liege, müsste Leos for-Schleife in localconfig.php untergrbracht werden.

Hallo Georg,

ich habe, deinen ersten Ausführungen gemäß, Leos Code sowohl in die dcaconfig.php als auch in die localconfig.php geschrieben. Das hat jedenfalls erstmals geklappt, der Cronjob wurde nicht ausgeführt, die Dateien im Cache-Ordner system/tmp sind unverändernd geblieben.
Versteh ich dich richtig, dass der Code in der dcaconfig.php gar nicht notwendig ist, um den Cronjob zu deaktivieren?

Gruß
Michael

[BugBuster]

Versteh ich dich richtig, dass der Code in der dcaconfig.php gar nicht notwendig ist, um den Cronjob zu deaktivieren?

Ja, denn
1. ist die dcaconfig, wie der Name vermuten läßt, nur fürs Backend denke ich
2. wird die localconfig.php immer eingelesen, egal ob Front- oder Backend.

[okapi]

Vielen Dank!
Der Hinweis, dass dieser Cronjob in der dcaconfig.php zu deaktivieren wäre, stammt übrigens von Leo selbst und war die Antwort auf ein (closed) Ticket vom Typ feature, das ich eröffnet hatte:

http://https://contao.org/issues/show/1214

Gruß
Michael

[deerwood]

Hallo alle,

danke BugBuster, ich glaube inzwischen auch, dass "dcaconfig.php" nur für das Backend gedacht ist. Alle dca-Dateien, die ich besichtigt habe, befassen sich praktisch ausschließlich mit der Konfiguration im Backend. Eine Ausnahme ist eventuell ['config']['ptable'], wo die Eltern-Tabelle zu der gerade konfigurierten Tabelle festgelegt wird .

Nebenbei kann ich aus dem Kürzel/Namen DCA/Data Container Array NICHT schließen, dass es sich um das Backend handelt, der Begriff wäre mir komplett unverständlich, wenn ich nicht zuvor schon mit Typo3 zu tun gehabt hätte. Würde nichts schaden, wenn in einem Kommentar in der Datei selbst darauf hingewiesen würde, dass Änderungen dort sich nur im Backend auswirken (falls es denn tatsächlich so ist). Dito wäre ein Kommentar in "localconfig.php" hilfreich, der darauf hinweist, dass sich diese Änderungen sowohl in Backend wie auch Frontend auswirken.

Michael, freut mich, dass es geklappt hat, berichtest Du bitte auch, ob es mit nur "localconfig.php" dann auch klappt, auch wenn Du Dich mehrfach im Backend anmeldest (beim Anmelden im BE wird cron.php nämlich auch aufgerufen)?

Ansonsten solltest Du unbedingt auch Leos Hinweis aus dem Ticket beachten, dass das Aufräumen von system/tmp seinen Grund hat und gelegentlich getan werden muss. Hier die wichtigsten Gründe:

• system/tmp ist das universelle Verzeichnis für alle Arten von temporären Dateien, auch solchen, die mit dem Seitencache nichts zu tun haben, z.B. bei Benutzung des safe mode hacks, beim Hochladen von Dateien usw. Der Core räumt diese im Normalfall selbst wieder auf, aber im Fehlerfall kann da schon mal eine Datei stehen bleiben. Und andere Erweiterungen werden sicher auch Gebrauch von system/tmp machen und ob die auch alle aufräumen kann ich natürlich garnicht überblicken.
• in den Dateinamen der Seitencaches geht die komplette URL einschließlich Domain und sämtlicher Parameter ein. Das ist auch richtig/wichtig z.B. für die Anzeige einer einzelnen News: immer die gleiche Seite (page id), aber für jede angezeigte News eine eigene Cache-Datei. Aber das betrifft eben auch beliebige weitere Parameter, selbst wenn diese manuell an die URL angehängt wurden und von TL gar nicht behandelt werden; TL kann/soll nicht entscheiden, ob diese zusätzlichen Parameter nicht doch für irgend eine Erweiterung wichtig sind.
• es kann also passieren, dass system/tmp vollläuft, wenn es niemals aufgeräumt wird.

Ich rate also dazu, den cron-job mindestens wöchentlich ausführen zu lassen.

Theoretisch könnte ich mir eine Erweiterung vorstellen, die system/tmp gezielt aufräumt, so dass nur Seitencache-Dateien gelöscht werden, die abgelaufen sind, aber alle anderen Dateien löscht.

Konzept/Idee:

• an den Dateinamen können Seitencache-Dateien nicht erkannt werden, alle Dateienamen, die der TL-Core dort erzeugt, sind MD5 verschlüsselt
• aber am Anfang der Seitencache-Dateien steht immer ein kurzer Schnipsel PHP Code "<?php $expire = 1259628975; ?>" mit dem Verfallszeitpunkt dieser Datei
• die Erweiterung könnte jede Datei in system/tmp untersuchen, ob sie am Anfang dieses Stückchen PHP Code enthält
• falls nicht, ist es kein Seitencache und wird gelöscht
• falls ja und die aktuelle Zeit ist > als die Verfallszeit, wird die Datei ebenfalls gelöscht
• ansonsten wird die Datei nicht angetastet
• die Erweiterung müsste regelmäßig aufgerufen werden

Das Problem mit diesem Ansatz ist, dass es SEHR viel länger dauert, jede Datei in system/tmp erst zu öffnen, um sie prüfen zu können, anstatt einfach den kompletten Inhalt von system/tmp zu löschen. Damit scheidet es aus, diese Erweiterung als normalen Job in cron.php auszuführen. Besucher der Seite würden zu lange eine Sanduhr sehen (abhängig vom Browser), aber vor allem könnte die maximale Laufzeit von PHP-Scripten überschritten werden. Vor allem dann, wenn man den Job so programmiert, dass er schwache Server nicht "total platt macht", der Job also jeweils nach Aufräumen von X Dateien eine Pause macht, bevor er weiter arbeitet.

Sinnvoll wäre eine solche Erweiterung also nur für TL Installationen, die einen echten CRON haben ... wahrscheinlich die wenigsten.

EDIT: Beim Lesen zur Kontrolle kam ich noch auf diese Idee:

Dateien in system/tmp, deren "last creation/modification/access time" älter ist, als die aktuelle Zeit minus eines einstellbaren Zeitraums (in der zu schreibenden Erweiterung) könnten im Vorfeld gelöscht werden, ohne sie inspizieren zu müssen. Das könnte den Job eventuell deutlich beschleunigen, wenn er selten aufgerufen wird?

LG, Georg

[leo]

Der Hinweis, dass dieser Cronjob in der dcaconfig.php zu deaktivieren wäre, stammt übrigens von Leo selbst

Mein Fehler Ich meinte die localconfig.php (hab es im Ticket ebenfalls korrigiert).

[okapi]

Ich rate also dazu, den cron-job mindestens wöchentlich ausführen zu lassen.

Hallo Georg,
heißt das, dass in diesem Fall

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

in die localconfig.php zu schreiben ist?

Gruß
Michael

[xchs]

Hallo Georg,

wäre es in diesem Fall nicht besser zusätzlich zum tmp-Verzeichnis ein eigenes Verzeichnis NUR für den TL-Cache einzuführen, d.h.

/system/tmp
/system/cache

Der tmp-Ordner könnte dann wie bisher täglich vom "Poor-Man's"-Cron-Job aufgeräumt werden, der Cache-Ordner hingegen nur bei entsprechenden Änderungen der Inhalte im Backend bzw. nach Ablauf der eingestellten Cache-Zeit.

[deerwood]

Hallo alle,

Michael: ja, so sollte das wöchentliche Löschen funktionieren.

xchs:ja, ein eigenes Verzeichnis für die Cachedateien könnte schon helfen, aber würde ja Core-Änderungen erfordern. Mein Konzept oben ist gedacht für einen unveränderten Core.

Wenn man den Core ändern würde (auch wegen des gezielten Löschens einiger Cache-Dateien bei Änderungen im Backend) dann wäre mein Konzept anders. In Kürze:

• beim Schreiben einer Cache-Datei würde in einer neuen DB-Tabelle (tl_cache) eingetragen: die Seiten-Id, der Cache-Dateiname, die Verfallszeit.
• die Cachedatei würde in ein eigenes Unterverzeichnis (z.B. system/tmp/cache) geschrieben, das nur dafür benutzt wird
• die Verfallszeit würde nach wie vor auch an den Anfang der Cachedatei geschrieben, damit index.php ohne DB-Zugriff entscheiden kann, ob sie noch gültig ist
• das Backend könnte bei Änderungen an Seite/Artikel/Inhaltselement über die Seiten-Id in tl_cache alle betroffenen Cachedateien finden und löschen und die entsprechenden Datensätze aus tl_cache entfernen
• der neue Job Automator->purgeTempFolder würde via tl_cache.Verfallszeit alle abgelaufenen Cachedateien schnell ermitteln können, nur genau diese aus system/tmp/cache löschen, die Datensätze der gelöschten aus tl_cache entfernen und alle Dateien direkt in system/tmp unbesehen löschen

Das soltte nicht wesentlich länger dauern, als der jetzige cron job. Es wäre nicht mehr nötig, jede Cachedatei zu inspizieren, weil die abgelaufenen mit einem einzigen SQL Query aus tl_cache ermittelt werden können.

Dies Konzept würde allerdings immer noch nicht den Fall von dynamischen Inhalten (News usw.) auf jeder / vielen Seiten berücksichtigen. Wenn man also jeden Tag 4 News/Blog-Einträge schreibt, die auf vielen Seiten gezeigt werden, dann macht es keinen Sinn 7 Tage zu cachen! Dazu müsste das Cache-Konzept noch anders aussehen, siehe auch dies Ticket.

LG, Georg

[klaus_tkm]

Hallo !

Habe hier alle Beiträge aufmerksam verfolgt und hätte dazu eine Frage.

Ich habe den Code von Leo bei mir eingebaut und lösche via FTP nun manuell cache files die älter als 2 Tage sind. Da sich der Inhalt meiner Seite global nur alle 2-3 Wochen ändert, ist die cache Zeit auf 12 Std eingestellt.

Leider kann ich kaum php....würde aber den code von Leo gerne so erweitern, dass eben täglich der Job zwar läuft, aber eben nur ältere (Dateidatum) cache files gelöscht werden.

Würde das gehen ?

Wenn ja, wie müsste der code aussehen ?

Wo liegen die Nachteile ?

lg Klaus

[klaus_tkm]

Hallo !

Vorweg..keine PHP Ahnung, aber ich habe mich etwas damit befasst und würde gerne das was ich derzeit manuell mache (= Dateien die älter als 12 std sind via ftp löschen) automatisieren.

Habe mich als php laie mal ins handbuch eingelesen und mir das zusammengereimt:

 /**
 *Löschen von Dateien im system/tmp nach bestimmten Zeitraum
 */
 
 if ($handle = opendir('tmp')) {

  foreach (glob("tmp/*.*") as $filename) {
    if (filemtime($filename) + 43200 < time()) {
      @unlink($filename);
    }
  }

  }

So...und jetzt weis ich nicht weiter.....und bitte um Hilfe...bzw will ich da echt auch etwas dazulernen...

Wo müsste man das einbauen, dass dies täglich ausgeführt wird ?

stimmt der verzeichnisaufruf überhaupt ,oder muß das ein absoluter serverpfad sein ?

ist der code oben ok ?

und da hat sich auch noch eine frage ergeben: file erstelldatum oder änderungsdatum ?

filectime

oder

filemtime

?

jeder fängt mal neu an

Danke und LG Klaus

ps: das ist schon in der localconfig eingebaut und klappt...

[deerwood]

Moin Klaus,

ich will Dich nicht von eigenen Experimenten abhalten, Dein Ansatz mit filemtime() ist schon richtig. filectime() ist nebenbei NICHT die "Creation time", jedenfalls nicht auf UNIX Systemen. Ansonsten sollte man in TL weder opendir() noch glob() verwenden, sondern das TL Framework. Und der Pfad muss absolut sein, sowas wie TL_ROOT . '/system/tmp/' . $filename ...

Aber ich sitze seit vorgestern in meiner Freizeit an einer kleinen Erweiterung [purge_old], die das vernünftig macht. Sie ersetzt automatisch den normalen Cronjob Automator :: purgeTempFolder() mit einer Variante, die nur "alte" Dateien aus system/tmp löscht. Was als "alt" anzusehen ist, kann in localconfig.php eingestellt werden (default ist 24 Stunden). Sie ersetzt auch NUR den Cronjob, im Backend kann man nach wie vor ausdrücklich alle Dateien aus system/tmp löschen.

Die Erweiterung ist weitestgehend fertig, ich schreibe gerade eine kleine Doku und mache nochmal einen Abschluss-Test.

LG, Georg

[klaus_tkm]

Hallo Georg !
Naja...beim experimentieren lernt man ja am Meisten.... aber recht herzlichen Dank mal für die Erklärungen...habe da mal gleich wieder etwas gelernt.

Finde es echt toll, dass Du dieses Thema aufgegriffen hast und an einer Erweiterung arbeitest. Ich denke, dass wird vielen Usern helfen.

Ich habe ein paar Testumgebungen (nicht produktiv laufen) , wenn du möchtest kann ich das Modul gerne vorab (mit)testen, würde dir dann auch Backendzugriff geben, damit du in den Logfiles nachsehen kannst.

lg Klaus

[BugBuster]

Aber ich sitze seit vorgestern in meiner Freizeit an einer kleinen Erweiterung [purge_old], die das vernünftig macht.

Hallo Georg,
ich schreib grad etwas ähnliches, aber bei mir gehts um den Ordner /system/html.
Ich will bestimmte Bilder löschen ab ein gewisses Alter.
Dabei habe ich mich an den Cron / Automator orientiert und gesehen, das selbst dort nicht alles SMH kompatibel ist. Aber vielleicht auch nicht braucht...

Jedenfalls nutze ich auch "filemtime", da gibts kein äquivalent in der class File, oder hab ich was übersehen?

[FloB]

Jedenfalls nutze ich auch "filemtime", da gibts kein äquivalent in der class File, oder hab ich was übersehen?

mtime (u. a.) gibt es AFAIK in der Fileklasse als Eigenschaft. Einfach aufrufen, __get() sollte sich drum kümmern.

[BugBuster]

Aja, gefunden, macht dann auch ein filemtime draus. :-)
Gibt aber nichts passendes in der FTP Klasse dazu, also brauch ich nicht über File(s) zu gehen.
Wobei, das unlink könnte ich damit dann auch gleich durch delete ersetzen.
Muss ich mal durchprobieren.

[FloB]

Generell immer das Framework benutzen, wenn es geht. Dass es keine entsprechende Eigenschaft in der FTP-Klasse gibt, ist kein Grund, die Fileklasse nicht zu benutzen. Nicht etwas Falsches angewöhnen und redundanten Code erzeugen!

[deerwood]

hallu BugBuster, alle,

Dabei habe ich mich an den Cron / Automator orientiert und gesehen, das selbst dort nicht alles SMH kompatibel ist. Aber vielleicht auch nicht braucht...

Das wird nicht gebraucht, siehe Konstruktor von .../libraries/FTP.php, system/tmp, system/html und system/logs sind die 3 Verzeichnisse, die mit SMH chmod 777 haben.

Ich denke auch, dass für das reine Löschen filemtime()/unlink() gut genug sind ... der Cronjob soll ja möglichst schnell sein und der stat() call (der letzlich hinter filemtime() steht) ist schon teuer genug. IMHO braucht es die Verwendung der Klasse File dafür nicht.

Ich werde dann nacher mal meine Erweiterung, zur manuellen Installation, hier hochladen.

LG, Georg

[deerwood]

Moin alle,

in der Anlage meine alpha Erweiterung, wie versprochen. Muss manuell installiert werden. Bitte auch die Doku (in purge_old/doc) lesen. Ich hoffe, das funktioniert auch für Euch.

Netto 1 Zeile zusätzlicher Code (Prüfung der Änderungszeit) ... aber sooooo viel Zeugs drumherum, bis das für "Endverbraucher" benutzbar wird.

Edit: Neue Version hochgeladen.

LG, Georg

[klaus_tkm]

Hallo !

Hast Du die ganze Nacht durchgearbeitet ? So spät (früh) ne Erweiterung reinstellen.... lobenswert !

Habe die Erweiterung auf Testseite 2.8.0 mal eingebaut.
Was mir aufgefallen ist:

Ursprung: Backend
Kategorie: CRON
Benutzer: t*******
Details: Purged temporary directory
Funktion: Automator purgeTempFolder()

Kommt nach der Installation gleich mehrmals...was löst eigentlich das Löschen aus ? Ein Login im BE ?

Werde es mal weiter beobachten und berichten.

Danke mal für Deine Leistung.


LG Klaus

PS: OK, habe es gefunden > Speichern und Schließen von "Einstellungen" löst das Löschen aus....daher gleich mehrmals im LOG....

[deerwood]

Moin Klaus, alle,

ich habe eben eine neue Version hochgeladen. Es hatte sich noch ein Fehler eingeschlichen:

Falls man die for-Schleife von Leo (siehe oben im Thread) schon in "localconfig.php" stehen hatte, dann wurde [purge_old] nicht als Cronjob eingetragen.

Das könnte Dich, Klaus, ja wohl betreffen?! Es reicht, wenn Du .../purge_old/config/config.php gegen die neue Version austauschst, alle anderen Dateien sind unverändert.

LG, Georg

[klaus_tkm]

Falls man die for-Schleife von Leo (siehe oben im Thread) schon in "localconfig.php" stehen hatte, dann wurde [purge_old] nicht als Cronjob eingetragen.

Hallo !

Kann ...oder besser soll diese Schleife drinnen bleiben ?

Auf dem derzeitigen webspace hatte ich die noch nicht drinnen.....

lg Klaus

[deerwood]

Hi Klaus,

Kann ...oder besser soll diese Schleife drinnen bleiben ?

Sie kann, mit dem Fix, zwar drinbleiben, aber besser ist es, sie nicht in localconfig.php zu haben: das, was der manuelle Eingriff macht, wird nämlich in .../purge_old/config/config.php gemacht. Deaktiviert oder deinstalliert man [purge_old] und hat vergessen, dass man die Schleife noch drin hat, dann wird nämlich system/tmp garnicht mehr aufgeräumt! Ich werde mal die Doku ergänzen.

LG, Georg

[klaus_tkm]

Hallo !

Habe mir heute die LOG Datei angesehen (die vom Testwebspace)...

Mir ist aufgefallen, dass KEIN automatischer cron job abgelaufen ist...dieser wurde erst durch das Login im BE ausgelöst...dann wurden aber alle alten files gelöscht.

Sollte das nicht auch klappen, wenn sich keiner am BE anmeldet ?

Beobachte aber noch weiter...

LG Klaus

[BugBuster]

Der erste Zugriff pro Tag, egal FE oder BE löst den "daily" Cron aus.

[klaus_tkm]

Der erste Zugriff pro Tag, egal FE oder BE löst den "daily" Cron aus.

OK alles klar...da ja versteckte Testwebseite ohne traffic...hatte ich natürlich auch keine Zugriffe !

Danke......dachte es läuft zeitabhängig ! Und wieder was dazugelernt ! :-)


lg Klaus

[deerwood]

Hi Klaus, alle,

wie BugBuster schon angedeutet hat: in TL haben wir es ja mit einem 'poor mans cron' zu tun (siehe auch Wikipedia Anacron), weil viele Hoster keine echten Cronjobs in den preiswerten Paketen anbieten. Aufgerufen wird das TL cron.php durch das Laden eines winzigen Bildchens auf jeder Seite im Frontend und beim Anmelden am Backend.

cron.php prüft dann, ob es etwas zu tun gibt, tut das dann nötigenfalls und merkt sich die Zeit, zu der es getan wurde in localconfig.php und liefert zum Schluss das Bild.

Damit Du zum Testen von [purge_old] nicht immer 24 Stunden warten musst, kannst Du auf einer Test-Installation mit 12 oder mehr Seiten so vorgehen:

• in Deiner Root-Seite die Cache-Zeit auf 1800 Sekunden = 1/2 Stunde einstellen. Kind-Seiten erben das, sofern dort nichts anderes eingestellt ist.
• die Zeit für "alte" Temp Dateien in den Einstellungen ebenfalls auf 1800 Sekunden stellen.
• alle Dateien in system/tmp löschen (FTP oder Backend).
• Vom Backend abmelden.
• etwa alle 5 Minuten genau 1 Seite (aber immer eine andere) im Frontend aufrufen. In system/tmp wird dann für jeden Aufruf eine neue cache-Datei erzeugt mit unterschiedlichen Zeitstempeln.
• nach etwa 1 Stunde die localconfig.php vom Server herunterladen, darin die ganze Zeile $GLOBALS['TL_CONFIG']['cron_daily'] = xyz; löschen und die Datei wieder hochladen.
• der nächste Zugriff auf eine Seite im Frontend (ungechacht oder abgelaufen, falls der Browsercache auch aktiv ist) löst den täglichen Cronjob und damit [purge_old] aus. Es sollten jetzt etwa die Hälfte Deiner Cache-Dateien gelöscht worden sein.

LG, Georg

[klaus_tkm]

Hallo Georg !

Also ich habe jetzt mit TL 2.7.6 und 2.8.1 getestet...klappt wunderbar !!

Id: 35636
Datum: 03.03.2010 06:27
Ursprung: Frontend
Kategorie: CRON
Benutzer:
Details: Purged 165 of 389 files in temporary directory
Funktion: PurgeOld purgeOnlyOldTempFiles()

Muß jetzt noch die optimalen Zeitspannen abstimmen, aber ich kann nur sagen: TOLLE LEISTUNG , keine Fehlermeldungen !!
Denke du kannst das ins ER stellen...

lg klaus

[deerwood]

Moin Klaus,

vielen Dank für Deine Tests!

Denke du kannst das ins ER stellen...

Das habe ich dann mal gemacht. Link zur Erweiterung im Repository, Support gibt es hier.

Magst Du noch einen weiteren Test für mich machen? Dann:

• die manuell installierte Version vom Server löschen
• die 1.0.0. rc1 via Erweiterungsverwaltung im Backend installieren, dort wird sie z.B. unter "Cron" angezeigt
• testen
• im Support-Zweig berichten, damit ich ein Indiz habe, ob ich von rc1 auf stable gehen kann

An der Funktionalität hat sich nichts geändert, es gibt aber etwas mehr Doku und Sprachanpassungen.

Danke und LG, Georg

[Mecintosch]

Wie kann ich unter Contao 4.9 das Leeren des system/tmp Ordners auf wöchentlich statt täglich ändern?

Sollte mit einer DCA Anpassung funktionieren oder?

$GLOBALS['TL_CRON'] = array
(
    'monthly' => array(),
    'weekly' => array(),
    'daily' => array
    (
        'purgeTempFolder' => array(Automator::class, 'purgeTempFolder'),
        'generateSitemap' => array(Automator::class, 'generateSitemap'),
        'purgeRegistrations' => array(Automator::class, 'purgeRegistrations'),
        'purgeOptInTokens' => array(Automator::class, 'purgeOptInTokens')
    ),
    'hourly' => array(),
    'minutely' => array()
); 

möchte also folgendes erreichen:

$GLOBALS['TL_CRON'] = array
(
    'monthly' => array(),
    'weekly' => array
    (
        'purgeTempFolder' => array(Automator::class, 'purgeTempFolder')
    ),
    'daily' => array
    (
        'generateSitemap' => array(Automator::class, 'generateSitemap'),
        'purgeRegistrations' => array(Automator::class, 'purgeRegistrations'),
        'purgeOptInTokens' => array(Automator::class, 'purgeOptInTokens')
    ),
    'hourly' => array(),
    'minutely' => array()
); 

Danke für die Hilfe.