Cron-Bundle
Aus Contao Community Documentation
Automatisierung von Batch Programmen mittels Zeitsteuerung
- Automatische zeitgesteuerte Ausführung von PHP Skripten.
- Zeitsteuerungs-Syntax von UNIX cron/crontab.
- Benötigt kein “richtiges” cron, wird bei Backend Seitenaufrufen ausgeführt
- Frontend Auslösung mittels Frontend Modul möglich
- Alternative Auslösung mittels “echtem” cron möglich.
Erweiterungs-Übersicht | |
---|---|
Name des Entwicklers | Glen Langer (BugBuster) |
Entwickler Webseite | http://contao.ninja |
Version der Erweiterung | 1.0.0 |
Kompatibilität mit Contao Version | ab 4.4 |
Link zum Extension Repository | https://packagist.org/packages/bugbuster/contao-cron-bundle |
Den Entwickler unterstützen | http://www.amazon.de/wishlist/26HHEJOU03G76 |
Link zum Tracker | https://github.com/BugBuster1701/contao-cron-bundle/issues |
Link zum VCS | https://github.com/BugBuster1701/contao-cron-bundle |
Anmerkung | In Kürze verfügbar |
Inhaltsverzeichnis
Vorwort
Die Beschreibung hier bezieht sich nur auf die Cron Bundle Version ab 1.0.0. für Contao 4. Für Contao 3 ist die Beschreibung hier zu finden.
Forum
Fragen zur Cron Erweiterung werden im Forum beantwortet: Forum - Sonstige-Erweiterungen
Fehler und Wünsche können im Tracking System gemeldet werden.
Installation
Installation erfolgt über Composer bzw- Contao Manager.
Contao Manager
Paket "bugbuster/contao-cron-bundle" suchen und installieren.
Composer
composer require bugbuster/contao-cron-bundle
Auslösen des Schedulers
Backend
Standardmäßig wird der Scheduler bei jeder Backend Seitenaktualisierung ausgelöst.
Frontend
Über ein Frontend Modul "Scheduler", welches aber keine Ausgabe erzeugt und somit das Layout nicht stört, ist die Auslösung auch über Seitenaufrufe des Frontends möglich. Bei Jobs die längere Zeit benötigen ist diese Art der Auslösung ungeeignet.
Luxus Lösung mit realem Cron
Hat man einen Server zur Verfügung in dem Cron-Jobs eingerichtet werden können, kann man diesen System Cron nutzen um die Cron Bundle Erweiterung darüber auszulösen. Der Vorteil ist, dass der Cron-Job genau zur geplanten Zeit gestartet wird, auch wenn niemand auf die Website zugreift. Auch bei Seiten mit sehr hohem Traffic, wird diese Art der Auslösung die Webserver Last etwas senken. (im Vergleich zur FE-Modul Auslösung)
Folgende Zeile in die crontab eintragen, vorher anpassen mit der eigenen Domain natürlich.
* * * * * wget -t 1 -O - http://www.example.com/bbcron/startjobs >/dev/null 2>&1
Cron-Jobs definieren
Über Backend - System - Scheduler sieht man zunächst die Übersicht bereits eingerichteter Cron-Jobs.
Benutzerdefinierte Cron-Job Scripte
Die Erweiterung bringt ein Beispielskript "PurgeLog.php" mit im Verzeichnis "web/bundles/bugbustercron/". Hier kann man schon einiges erkennen wie es läuft. Weiter unten folgt ein weiteres kleines Beispiel.
Allgemeine Überlegungen
Generell sollte man versuchen, kleine Jobs wann immer möglich zu schaffen, die nicht lange laufen. Zum Beispiel statt der Schaffung eines großen Jobs, das 3 Dinge tut, ist es besser, 3 kleinere Jobs zu schaffen. Auf diese Weise kann die Last in 3 verschiedenen Seitenaufrufe vom Scheduler verteilt werden.
Die Laufzeit eines Jobs sollte kurz bleiben, weil der Benutzer eine Sanduhr so lange zu sehen bekommt bis dieser fertig ist. Wenn es zu lange dauert wird man denken, es gibt ein Problem mit der Website oder mit dem Computer und bricht die Anfrage ab oder schließt gar den Browser.
Das globale Array $cronJob
Es gibt eine globales Array $cronjob die einem hilft den Job in sinnvolle Stücke aufzuteilen, und einige Informationen und Kontrolle bietet:
$cronJob['id']
ID in der Job Table tl_crontab.
Dieser Parameter kann nur gelesen werden, eine Änderung hat keine Auswirkung.
$cronJob['title']
Titel des Jobs.
Dieser Parameter kann nur gelesen werden, eine Änderung hat keine Auswirkung.
$cronJob['lastrun']
Zeitstempel der letzten Ausführung. Der Wert ist 0 wenn unbekannt bzw. noch nie ein Start erfolgte.
Dieser Parameter kann nur gelesen werden, eine Änderung hat keine Auswirkung.
$cronJob['endtime']
Ab dieser Zeit sollt der Job stoppen, z.B. in dem keine neuen Aktionen mehr ausgeführt werden.
Dieser Parameter kann nur gelesen werden, eine Änderung hat keine Auswirkung.
$cronJob['runonce']
"true": der Job wird nach komplettem Durchlauf deaktiviert.
Das kann im Job selbst geändert werden:
- Setzen auf "true" : der Job wird nach komplettem Durchlauf deaktiviert..
- Setzen auf "false": der Job wird nach komplettem Durchlauf nicht deaktiviert.
Setzt man $cronJob['completed'] auf "false", wird der Job nicht deaktiviert auch wenn $cronJob['runonce'] auf "true" gesetzt ist.
$cronJob['logging']
"true": die Protokollierung des Jobs ist eingeschaltet, für Testzwecke gedacht.
"false": nur Fehler werden protokolliert, so sollte der Job im Normalfall eingestellt sein.
Dieser Wert kann vom Job geändert werden, führt aber eventuell zur Verwirrung der Nutzer:
- Setzen auf "true" : die Protokollierung des Jobs ist eingeschaltet.
- Setzen auf "false": die Protokollierung des Jobs ist abgeschaltet, bis auf Fehlermeldungen.
$cronJob['completed']
Dieser Status ist per Default "true" und bedeutet, wenn der Job fertig ist wird dieser als erledigt markiert und wird neu geplant.
Benötigt der Job zu viel Zeit und man hat die Möglichkeit diesen abzubrechen und beim nächsten Aufruf an der Stelle weiter zu machen, setzt man diesen Status auf "false" und beendet den Job. Dadurch wird der alte Zeitplan beibehalten und beim nächsten Scheduler Aufruf der Job wieder gestartet, um die Arbeit abzuschließen.
Beispiel Script
Script liegt hier unter web/bundles/bugbustercron/PurgeLog.php
<?php use Psr\Log\LogLevel; use Contao\CoreBundle\Monolog\ContaoContext; /** * Contao Open Source CMS, Copyright (C) 2005-2017 Leo Feyer * * Contao Module "Cron Scheduler" * Sample PHP script to execute by cron: Purges the system log * Job: web/bundles/bugbustercron/PurgeLog.php * * @copyright Glen Langer 2018 <http://contao.ninja> * @author Glen Langer (BugBuster) * @package Cron * @license LGPL * @filesource * @see https://github.com/BugBuster1701/contao-cron-bundle */ /** * Initialize the system */ if (!defined('TL_MODE')) { define('TL_MODE', 'BE'); $dir = __DIR__; while ($dir != '.' && $dir != '/' && !is_file($dir . '/system/initialize.php')) { $dir = dirname($dir); } if (!is_file($dir . '/system/initialize.php')) { echo 'Could not find initialize.php!'; exit(1); } require($dir . '/system/initialize.php'); } /** * Class PurgeLog * * @copyright Glen Langer 2012..2018 <http://contao.ninja> * @author Glen Langer (BugBuster) * @package Cron */ class PurgeLog extends Backend { /** * Initialize the controller */ public function __construct() { parent::__construct(); } // __construct /** * Implement the commands to run by this batch program */ public function run() { global $cronJob; // from BugBuster\Cron\ContaoBackendController Class //no directly call if (!is_array($cronJob)) { die('You can not access this file directly!'); } //At this time the job should be defered, //no new actions should be started after this time. if (time() >= $cronJob['endtime']) { $cronJob['completed'] = false; return; } \Database::getInstance()->prepare("DELETE FROM `tl_log`")->execute(); if ($cronJob['logging']) { \System::getContainer() ->get('monolog.logger.contao') ->log(LogLevel::INFO, 'System log purged by cron job.', array('contao' => new ContaoContext('PurgeLog run()', TL_GENERAL))); } } // run } // class PurgeLog /** * Instantiate log purger */ $objPurge = new PurgeLog(); $objPurge->run();
--BugBuster (Diskussion) 00:02, 16. Feb. 2018 (CET)