Quelltext der Seite Cron-Bundle

Automatisierung von Batch Programmen mittels Zeitsteuerung
* Automatische zeitgesteuerte Ausführung von PHP Skripten, Symfony Routen oder URLs.
* 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.
{{ExtInfo
| Dev=Glen Langer ([[User:BugBuster|BugBuster]])
| DevSite=http://contao.ninja
| ExtVersion=1.3.2
| Version=ab 4.4
| ERLink=https://packagist.org/packages/bugbuster/contao-cron-bundle
| DonateLink=http://www.amazon.de/wishlist/26HHEJOU03G76
| TrackerLink=https://github.com/BugBuster1701/contao-cron-bundle/issues
| VCSLink=https://github.com/BugBuster1701/contao-cron-bundle
| Comment=1.3.0 ist da.
}}
[[Kategorie:Extensions]]


=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 [http://de.contaowiki.org/Cron hier] zu finden.

=Forum=
Fragen zur Cron Erweiterung werden im Forum beantwortet: [https://community.contao.org/de/forumdisplay.php?119 Forum - Sonstige-Erweiterungen]
<br />
Fehler und Wünsche können im [https://github.com/BugBuster1701/contao-cron-bundle/issues Tracking System] gemeldet werden.

=Installation=
Installation erfolgt über Composer bzw- Contao Manager.
==Contao Manager==
Paket "bugbuster/contao-cron-bundle" suchen und installieren.
==Composer==
<source lang="bash">
composer require bugbuster/contao-cron-bundle
</source>

=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.
<source lang="bash">
* * * * * wget -t 1 -O - http://www.example.com/bbcron/startjobs >/dev/null 2>&1
</source>

=Cron-Jobs definieren=
Über Backend - System - Scheduler sieht man zunächst die Übersicht bereits eingerichteter Cron-Jobs.

Als Beispiel hier der mitgelieferte Demo Job zum löschen der Einträge im System-Log.

[[Datei:Cron-bundle-job-uebersicht.jpg]]

Der Job zum löschen der System-Log Einträge im Detail:

[[Datei:Cron-bundle-job-einstellungen.jpg]]

Ab Version 1.1.0 sind neben PHP Scripte auch Symfony Routen und URLs möglich im Feld Job.<br >
Alle drei Beispiele:
* '''mein/job/in/meinem/relativem/pfad/job.php'''<br />Erkannt als Datei Job, wird relativ zum Installationsverzeichnis per "include" geladen 
* '''/BackupDB/autobackup'''<br />Erkannt als Route, wird per Request aufgerufen
* '''<nowiki>http://meine.seite/</nowiki>'''<br />Erkannt als URL, wird per Request aufgerufen

Ab Version 1.3.1 sind Parameter in alten Stil möglich, hier am Beispiel für BackupDB:
* '''/BackupDB/autobackup?geheim'''<br />Erkannt als Route, wird per Request aufgerufen inkl. Parameter

=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.<br>
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.<br>
Dieser Parameter kann nur gelesen werden, eine Änderung hat keine Auswirkung.

===$cronJob['title']===

Titel des Jobs.<br>
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.<br>
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.<br>
Dieser Parameter kann nur gelesen werden, eine Änderung hat keine Auswirkung.

===$cronJob['runonce']===

"true": der Job wird nach komplettem Durchlauf deaktiviert.<br>
Das kann im Job selbst geändert werden:<br>
* 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.<br>
"false": nur Fehler werden protokolliert, so sollte der Job im Normalfall eingestellt sein.<br>
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.
<br>
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

<source lang="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();
</source>

=Funktion bei htpasswd geschützter Domain=
Wenn man neue Webseiten online unter einer htaccess-geschützten Subdomain aufsetzt, muss das Cron-Bundle davon auch erfahren und die Login Daten mitsenden.

Ab Version 1.3.2 wurde die Möglichkeit geschaffen, dass über die config.yml bzw. config_dev.yml zu steuern. Das Cron-Bundle bringt im eigenem config Verzeichnis eine Beispiel config_dev.yml gleich mit. Diese greift automatisch wenn die Domain mit app_dev.php aufgerufen wird.

Datei ist zu finden im Verzeichnis: vendor/bugbuster/contao-cron-bundle/src/Resources/config

Man kann die Login Daten überschreiben in dem man die config_dev.yml ins das Verzeichnis /apps/config kopiert bzw. mit einer vorhandenen kombiniert. Soll das im normalen Modus sein, dann entsprechend als config.yml.

----
----[[Benutzer:BugBuster|BugBuster]] ([[Benutzer Diskussion:BugBuster|Diskussion]]) 22:23, 5. Okt. 2018 (CEST)