Typo3 Command Line Interface (CLI)

Weiterführendes

Podcast zum Scheduler: http://castor.t3o.punkt.de/files/scheduler.mp4

Zu Historie des CLI und neuen Techniken: http://typo3blogger.de/vom-standalone-cli-zum-scheduler/

Die lowlevel Extensions bringt bereits einige Tasks mit

Von Tim Lochmüller im Adventskalender 2009

Vom Stand-Alone CLI zum Scheduler – Türchen 5

Tim Lochmüller in Dev, Extension, TYPO3, Tutorial

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 http://www.typo3-tutorials.org/tutorials/entwicklung/cli-shell-scripte.html). 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: http://www.typo3-unleashed.net/typo3apidocs/latest/db/daa/classtx__scheduler__Task.html) ü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.

Von Tim Lochmüller im Adventskalender 2008

Heute im Türchen 15 möchte ich Euch die Verwendung des Command Line Interface (CLI) von TYPO3 näher bringen. Das CLI bietet sich immer an, wenn man Prozesse automatisieren möchte. Dies gilt z.B. für tägliche Erinnerungsmails, welche jeden morgen um 9 Uhr versendet werden sollen. Genau an diesem Beispiel möchte ich Euch nun zeigen, wie sowas geht:

Es sind nur 5 einfach Schritte nötig:

1. Backend User

Wir benötigen einen Backend-User, welcher für die Ausführung benötigt wird. Dieser sollte mit "_cli_" beginnen. Wir nennen ihn mal "_cli_myext", das Passwort ist eigentlich egal, da das CLI sich nicht ins Backend einloggt, jedoch könnte dieser User bei einem schwachen Passwort böswillig verwendet werden. Aus diesem Grund sollten ein sehr kryptisches Passwort gewählt werden.

Anmerkung Steff: _cli_ user können sich nicht ins Backend einloggen, Passwort ist also egal. (getestet mit TYPO3 Version 4.2)

2. Registrierung des CLI Scripts

Um das CLI nutzen zu können, müssen wir nun unser Script registrieren, dazu ist folgender Eintrag in der Datei ext_localconf.php notwendig:

if (TYPO3_MODE=='BE') {

 $TYPO3_CONF_VARS['SC_OPTIONS']['GLOBAL']['cliKeys'][$_EXTKEY] = array(
   'EXT:'.$_EXTKEY.'/class.tx_myext_cli.php',
   '_cli_myext'
 );

}

Hierbei ist zu beachten, dass der Backend-User mit angeben wird.

3. Das CLI Script selbst

Als nächstes benötigen wir das CLI Script selbst:

<?php
if (!defined('TYPO3_cliMode'))  die('You cannot run this script directly, only from the command line!');
 
require_once(PATH_t3lib.'class.t3lib_cli.php'); 
 
class tx_myext_cli extends t3lib_cli {
    function tx_myext_cli() {
      parent::t3lib_cli();
      $this->cli_help['name'] = 'Reminder-Mailings';
      $this->cli_help['synopsis'] = '###OPTIONS###';
      $this->cli_help['description'] = 'send reminder mailings';
      $this->cli_help['examples'] = '/.../cli_dispatch.phpsh myext sendMails';
      $this->cli_help['author'] = 'Frank Nägler, (c) 2008';
    }
 
    function cli_main($args) {
      // extract task
      $task = (string) $this->cli_args['_DEFAULT'][1];
      switch ($task) {
        case 'sendMails':
            $this->sendMails();
        break;
        default:
          $this->cli_validateArgs();
          $this->cli_help();
          exit;
        break;
      }
    }
 
    function sendMails() {
    	// send some mails
    }
}
 
// Call the functionality
$cliObj = t3lib_div::makeInstance('tx_myext_cli');
$cliObj->cli_main($_SERVER['argv']);
 
?>

4. Der Aufruf

Möchte man das CLI jetzt testen, dann brauchen wir nur die folgende Zeile in einer Shell aufrufen:

/path/to/typo3/cli_dispatch.phpsh myext sendMails

5. Der cronJob

Da wir die Mails ja jeden morgen um 9 Uhr versenden möchte, brauchen wir noch einen Eintrag in der cronTab:

0 9 * * * /path/to/typo3/cli_dispatch.phpsh myext sendMails

Das war es schon, die Möglichkeiten sind quasi unerschöpflich. Viel Spaß und viel Erfolg mit dem nächsten cronJob