Im heutigen Türchen möchte ich euch die Geschichte des CLI ein wenig nahe bringen, sodass ihr wisst wie ihr am besten Dinge in TYPO3 automatisieren könnt.

Einsteigen will ich bei der Version < 4.1. Bei dieser Version war ein Command Line Interface noch in einer eigenen Datei und es gab keine zentrale Registrierungsstelle für Scripte, die von der Kommandozeile ausgeführt werden sollten. Ähnlich wie ein Backend Modul bestand ein CLI Script aus einer conf.php in der wenige Konfigurationsvariablen gesetzt wurden und einer beliebigen PHP Dateien in der dann die Logik implementiert wurde. Der Code konnte dann hier mit unter gebracht werden (weitere Infos). Nachteil: Teils unstrukturiert, weil viele Leute keine Objekte benutzt haben und ggf. viele Cronjobs pro Installation. Doch das war einmal…

Ab der Version 4.1 gab es dann ein neues Interface. Dies besaß eine eigene Registrierungsstelle an der man seine eigenen Skripte registrieren konnte. In der ext_localconf.php einer Extension wurde über einen Hook eine neue CLI Klasse an TYPO3 registriert. Die Logik war dann in eine Klasse strukturiert, welche ein wenig mehr Übersicht verschafft hat (zudem gab es dann die Möglichkeit einen CLI zu XClassen). Ebenfalls wie bei der älteren Variante wird ein spezielle Backend benutze benötigt. Ausgeführt wurde das ganze dann über einen zentralen CLI Dispatcher (typo3/cli_dispatch.phpsh) wobei die Parameter dann bestimmte Tasks ausgeführt haben. Nachteil: Immer noch viele Cronjobs, wenn es viele verschiedene Tasks gibt. Doch das war einmal….

Ende der Version 4.1 bzw. Anfang der Version 4.2 wurde Gabriel langsam bekannt. Gabriel registrierte sich selbst an TYPO3’s CLI Schnittstelle und hat ein Backend Modul zu Verfügung gestellt über das man Aufgaben verwalten konnte. Extension hat nun die Möglichkeit Ihre aufgaben am Gabriel anzumelden und diese dann übersichtliche im Backend in einer GUI zu verwalteten. Es gab somit nur noch einen Cronjob der in kurzen Abständen durchgeführt wurde und Gabriel kümmerte sich darum, dass immer die richtigen Aufgaben durchgeführt wurden. Ein wirklich gute Idee. Nachteil: Keine hohe Akzeptanz, weil es nicht teil des Kernsystems ist. Doch das war einmal…

Seit der TYPO3 Version 4.3 haben wir nun den Scheduler. Er ist der „neue“ Gabriel bzw. die Kernversion dessen. Extensions haben nun die Möglichkeit Tasks am Scheduler zu registrieren. Durch die Integration in den Kern, hofft man auf große Akzeptanz. Ist auch eine Feine Sache. Nachteil: Weißt du wie es geht? Nein? Deshalb ließ weiter:

Beim Scheduler muss man einzelne Tasks über die ext_localconf.php an der System-Extension anmelden. Dies geschieht über einen einfachen Hook. Neben dem Extension Key, dem Titel und der Beschreibung hat man die Möglichkeit zusätzliche Felder über einen Provider zu Verfügung zu stellen. Dadurch kann man die einzelnen Tasks hinterher besser/genauer/speziell konfigurieren.

$TYPO3_CONF_VARS['SC_OPTIONS']['scheduler']['tasks']['tx_extkey_TaskName'] = array(
	'extension' => $_EXTKEY, // Selbsterklärend
	'title' => 'LLL:EXT:'.$_EXTKEY.'/locallang.xml:TaskName.name', // Der Titel der Aufgabe
	'description' => 'LLL:EXT:'.$_EXTKEY.'/locallang.xml:TaskName.description', // Die Beschreibung der Aufgabe
	// 'additionalFields' => 'tx_extkey_TaskName_AdditionalFieldProvider' // Zusätzliche Felder
);

Um die einzelnen Klassen dem System bekannt zu machen empfiehlt es sich, diese einfach in die ext_autoload.php einzutragen:

return array(
	'tx_extkey_TaskName' => t3lib_extMgm::extPath('extkey', 'scheduler/class.tx_extkey_TaskName.php')
);

Die eigentliche Aufgabe, welche dann den Code ausführt, muss zudem die Klasse „tx_scheduler_Task“ erweitern. Von dieser abstrakten Klasse muss mindestens die Methode „execute“ (Übersicht über alle Funkionen) überschrieben werden (return true/false nicht vergessen). Der Rest (zeitliche Konfiguration, kein paralleles ausführen etc.) erledigt man dann im Scheduler über die GUI des Backend Modul. Wenn man direkt welche der zusätzlichen Felder benutzen will, dann braucht man zudem eine weitere Klasse welche den AdditionalFieldProvider zu Verfügung stellt. Diese Klasse muss „tx_scheduler_AdditionalFieldProvider“ erweitern.

Ich hoffe diese kleine Historie gibt euch einen Anreiz den nächsten CLI Skript innerhalb von TYPO3 mit dem neuen Scheduler zu bauen. Viel Spaß dabei.