realURL: optimierte Multi-Domain-Konfiguration

Ausgangssituation

In einem Projekt waren in einer TYPO3-Instanz über den Seitenbaum mehrere Marken in verschiedenen Ländern mit jeweils eigenen (Teil-)Seitenbaum abgebildet. Die einzelnen Websites waren inhaltlich-strukturell sehr ähnlich, und es waren viele spezifische Plugins im Einsatz. Insgesamt entstand so für die rund 100 Einstiegseiten eine (via realURL-Autoconfiguration erzeugte) rund 4,5 MB große Konfiguration. Die war uns ein Dorn im Auge.

Weiterlesen»

Typolink + realurl in Scheduler-Tasks

Anforderung war, dass aus einem Scheduler-Task heraus korrekte sprechende URLs erzeugt werden. Der einfachste Weg hierfür ist eine der typolink-Methode des cObjects. Leider steht ein solches aber in Tasks von Haus aus nicht zur Verfügung. Anleitung, wie man sich ein solches erzeugen kann, finden sich im Internet viele – leider aber auch zahlreiche, die nicht (mehr) funktionieren oder riesen woodoo treiben. Nach einigen Recherchen und Tests kann ich nun einen Weg zur Problemlösung festhalten.

Weiterlesen»

TYPO3-Scheduler integrieren

Die Integration des integrierten Schedulers in TYPO3 ist denkbar einfach.

Zu allererst benötigt der Scheduler einen Benutzer, als der er seiner Aufgabe nachgehen kann. Der Benutzername ist hartcodiert und TYPO3-weit als

_cli_scheduler

vorgegeben. Dieser Benutzer braucht (in der Regel) keine besonderen Berechtigungen, er muss schlicht und ergreifend existieren (auch das vergebene Passwort ist dahingehend irrelevant). Er darf NICHT mit Administrator-Rechten arbeiten.

Ist der Benutzer angelegt, ist die TYPO3-seitige Arbeit schon erledigt. Was nun noch fehlt, ist der Cronjob selbst. Für Linux (ob und wie dies auch mit anderen Betriebssystemen realisierbar ist, gilt es zu prüfen) ist das Vorgehen zum Anlegen des Crons wie folgt:

Man öffnet die Konsole des Servers, auf dem die TYPO3-Installation läuft und wechselt zum entsprechenden Benutzer. Dies kann zum Beispiel folgendermaßen aussehen:

su -s /bin/bash - user32

Um herauszufinden, welcher Benutzer der Richtige ist, bietet es sich an, ins Wurzelverzeichnis der Seite, für die der Scheduler installiert werden soll, zu wechseln und sich dort über

ls -la

den Verzeichnisinhalt anzeigen zu lassen. Das Resultat dürfte dann in etwa folgendermaßen aussehen:

  4 drwxrwx---  2 vu2113   www-data   4096  2. Dez 12:21 backups
  4 drwxr-xr-x  2 user32   gruppe32   4096  2. Dez 12:21 cgi-bin
  4 drwxr-xr-x  3 www-data www-data   4096  2. Dez 12:21 disabled
  4 drwxrwxr-x  3 user32   gruppe32   4096  2. Dez 12:21 errors
  4 drwxrwxr-x 23 user32   gruppe32   4096 24. Apr 13:32 htdocs
  4 drwxrwx---  2 user32   www-data   4096  7. Mär 02:41 logs
120 drwxrwx---  2 user32   www-data 118784 24. Apr 13:32 phptmp
  4 drwxr-xr-x  5 user32   gruppe32   4096  5. Mär 13:23 relaunch

Die vierte Spalte ist von Interesse, in diesem Fall wäre daher der Benutzer „user32“ die Richtige Wahl.

Hat man nun die Rolle des richtigen Systembenutzers angenommen, ermittelt man, wo sich die PHP-Binary befindet. Dies ist am einfachsten über

which php

oder

which php5

herauszufinden.
In der Regel bekommt man hier etwas in der Form

/usr/bin/php5

zurück.
Nun öffnet man über

crontab -e

die Cronjob-Tabelle.

Jetzt geht es ans Eingemachte:
In die Crontab fügt man nun die folgende Zeile ein:

*/5   *    *    *    *    test -x ~/htdocs/typo3/cli_dispatch.phpsh && /usr/bin/php5 ~/htdocs/typo3/cli_dispatch.phpsh scheduler > /dev/null 2>&1

Zur Erklärung:
*/5 sagt dem Cron, er möge alle fünf Minuten laufen (in jeder Minute, die durch 5 ohne Rest teilbar ist, selbstverständlich kann man hier auch andere Intervalle definieren)
* jede Stunde
* jeden Tag des Monats
* jeden Monat
* jeden Tag der Woche

Zur näheren Erläuterung möglicher Interval-Einstellungen siehe bspw. http://wiki.ubuntuusers.de/Cron

Die vorangestellte Prüfung

test -x ~/htdocs/typo3/cli_dispatch.phpsh

stellt sicher, dass das aufzurufende Skript existiert und über CLI ausführbar ist. Nur bei positiver Prüfung wird das Script mit

/usr/bin/php5 ~/htdocs/typo3/cli_dispatch.phpsh scheduler

gestartet. Mit

> /dev/null 2>&1

leiten wir sämtliche Ausgaben nach /dev/null um (so stellt man sicher, dass Fehler im Cron keine Mailflut verursachen).

Wichtig: Vor dem Abspeichern der geänderten Crontab muss sichergestellt sein, dass die Datei mit einer leeren Zeile endet.

Damit wäre der Scheduler eingerichtet und bereit. Neuere TYPO3-Versionen von TYPO3 bringen bereits einen Task „Update Extension List (em)“ mit. Mit diesem kann man die Funktionstüchtigkeit des Crons testen.

Wer es eilig hat, kann auch gerne mal die Extension „ml_autoinstall_scheduler“ (verfügbar übers TER) ausprobieren. Diese versucht, die selben Schritte automatisiert auszuführen.

TYPO3 Autoload

Seit TYPO3 4.3 können Klassen automatisch beim Laden einer Extension eingebunden werden (z.B. rund um die Scheduler Tasks nützlich). Eigentlich kein Hexenwerk, aber als kleine Gedankenstütze trotzdem ein paar Zeilen Code und die Rahmenbedingungen:

ext_autoload.php:

<?php
$extensionPath = t3lib_extMgm::extPath('myext');
return array(
	'tx_myext_myclass' => $extensionPath .
		'Classes/class.tx_myext_myclass.php',
);
?>

Rahmenbedingungen

  • der Key muss immer kleingeschrieben sein, auch wenn die Klasse im CamelCase-Stil benamt ist
  • der Key muss mit tx_ (oder ux_) beginnen bzw. derart sein, dass mittels t3lib_extMgm::getExtensionKeyByPrefix($prefix) der Extension-Key ermittelbar ist ($prefix ist hierbei der Substring des Keys bis zum zweiten Unterstrich)
  • die Datei ext_autoload.php liegt im Hauptverzeichnis der Extension (neben ext_tables.sql usw.)
  • die Extension muss nur geladen werden, TYPO3 bzw. der Autoloader finden sich dann selbst zurecht

Anschaulicher erklärt das Ganze Christian in seinem Tagebuch

Quellen:

Scheduler in eigenen Extensions nutzen

Benni (Release Manager, TYPO3 4.4) hat in seinem Blog einen Artikel verfasst, um uns allen das Erstellen von Tasks für den neuen Scheduler (seit TYPO3 4.3) zu ermöglichen. Damit sollten irgendwelche händischen Cronjobs und vielleicht auch CLI-Skripte der Vergangenheit angehören.
Update 2012-04-26: Der Artikel von Benni existiert leider nicht mehr, jedoch findet sich auch bei Stefan im Blog ein Tutorial.

Achtung!

Der Scheduler (bzw. genauer der Autoloader) scheint Probleme zu haben, wenn sich eine Extension im user_-Namespace befindet (obgleich das Extensions tun sollten, wenn sie nur für eine einzelne Installation erstellt sind).

CSH – Context Sensitive Help für additionalFields

Um die eigenen Felder etwas verständlicher zu machen, lassen sich Details via CSH einbinden. Hierzu sind zwei Schritte nötig:

locallang_csh*.xml anlegen

Zum Beispiel für das Feld example

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3locallang>
    <meta type="array">
        <description>Contents of scheduler csh</description>
        <type>CSH</type>
        <csh_table>_MOD_tools_txschedulerM1</csh_table>
        <fileId>EXT:scheduler/mod1/locallang_csh_scheduler.xml</fileId>
        <labelContext type="array"></labelContext>
    </meta>
    <data type="array">
        <languageKey index="default" type="array">
            <label index="example.alttitle">Title</label>
            <label index="example.description">Short Description</label>
            <label index="example.details">Details</label>
        </languageKey>
    </data>
</T3locallang>

In ext_tables.php die Datei bekanntgeben:

t3lib_extMgm::addLLrefForTCAdescr('_MOD_tools_txschedulerM1', 'EXT:' . $_EXTKEY . '/locallang_csh.xml');

Links

Edit: Aufruf des Schedulers in der crontab ergaenzt.

# crontab -l -u [WEB BENUTZER]
# m h  dom mon dow   command

*/2 * * * *	/var/www/[PFAD ZUM WEB]/htdocs/typo3/cli_dispatch.phpsh scheduler 2>/dev/null >/dev/null