Im
vorliegenden Fall sollen TYPO3-Inhalte als HTML-Seiten exportiert und
auf einem Live-Server veröffentlicht werden, wobei Hyperlinks
leserlich und eindeutig benannt sein sollten. TYPO3-Erweiterungen,
die verschiedene Ansichten auf derselben Seite darstellen (z. B.
tt_news), werden zunächst außer Acht gelassen. Da im Extension Repository keine
entsprechende Lösung zu finden war, blieb nur die Alternative,
eine eigene TYPO3-Erweiterung mit der gewünschten Funktionalität
zu implementieren.

Für die
Anforderung an TYPO3, statische HTML-Seiten zu erzeugen, kann es eine
Vielzahl an Gründen geben. Die wichtigsten davon stellen sich
wie folgt dar:

• Hohe
  Serverlast bei stark frequentierten Websites
• TYPO3-Server
  nur innerhalb des Firmen-Netzwerks erreichbar
• PHP
  steht auf dem Live-Server nicht zur Verfügung
• Bessere
  Kontrolle über den Ablauf einer Veröffentlichung

Vor einer
Analyse der gestellten Anforderungen scheint es sinnvoll,
vergleichbare WCMS-Systeme und deren Lösungen zu betrachten:

• Imperia
  WCMS: Imperia kann Dateien erstellen und mittels der Protokolle
  HTTP, FTP, SSH und Webdav auf entfernte Server übertragen.
• Reddot
  CMS: Reddot kann erzeugte Dateien lediglich über das FTP
  Protokoll auf einen anderen Server übertragen.

Mit beiden
Produkten ist es möglich, auch ASP, JSP oder PHP-Dateien zu
generieren, um interaktive Elemente (z. B. E-Mail-Formulare) in den
veröffentlichten Dateien verwenden zu können.

Folgende
Punkte mussten bei der Realisation einer Veröffentlichungsfunktion
für TYPO3 berücksichtigt werden:

• Hyperlinks
  sollten eindeutig und einprägsam sein: Dank der
  TypoScript-Option „simulateStaticDocuments“ erfüllt TYPO3
  diese Voraussetzung von Haus aus. Ergänzend bringt die
  realURL-Extension die erzeugten Links in ein leserliches Format.
• HTML-Seiten
  sollen aus TYPO3 heraus erzeugt werden: Auch diese Anforderung
  erfüllt TYPO3 fast schon selbstständig. In der
  TYPO3-Konfigurations-Datei localconf.php gibt es die Möglichkeit,
  in der Direktive $TYPO3_CONF_VARS[‚FE‘][‚publish_dir‘] ein
  Verzeichnis anzugeben, in das HTML-Seiten exportiert werden können.
  Diese Variante hat aber leider einige Nachteile: So funktioniert das
  Anstoßen eines Exports beispielsweise ausschließlich mit
  Hilfe des Admin Panels im Frontend. Darüber hinaus kann immer
  nur die Seite, auf der man sich gerade im Frontend befindet,
  exportiert werden. Außerdem funktioniert diese Methode nur mit
  simulateStaticDocuments und nicht mit der realUrl-Erweiterung.
  Mangels einer passenden Erweiterung erfüllt TYPO3 die
  gestellten Anforderungen in diesem Punkt nicht.
• Übertragung
  erzeugter HTML-Seiten auf den Live-Server: Abermals war im Extension
  Repository keine passende Erweiterung zu finden, sodass TYPO3 auch
  in dieser Hinsicht die gestellten Anforderungen nicht erfüllt.

Nach dieser
Analyse steht fest, dass, zumindest für zwei der gestellten
Anforderungen, die erforderlichen Funktionsweisen komplett neu
entwickelt werden müssen.

Der Kern der
hier vorgestellten Lösung besteht aus den Backend-Modulen
„Static Publish“ und „Static Upload“. Eine andere
Erweiterung, „XML-Import“, stellt Static Publish verschiedene
Funktionalitäten zum Import von XML-Daten in die Datenbank zur
Verfügung. Static Upload wird als Submodul in das Modul „d.k.d
Werkzeuge“ eingehangen.

Während
der Installation der Erweiterung XML-Import, die nach erfolgter
Installation in den Abschnitt Web eingehangen wird, sollten im
Extension Manager folgende Einstellungen vorgenommen werden:

• Config
  File: Als Konfigurationsdatei wird eine PHP-Datei verwendet, welche
  ein Array $conf enthalten muss. Für die Zusammenarbeit mit
  Static Publish geben wir
  typo3conf/ext/dkd_staticpublish/res/config.php an.
• Log
  File: Zu jedem Import-Vorgang werden Daten in eine Log-Datei
  geschrieben. Sollen keine Logs geschrieben werden, kann diese
  Einstellung leer bleiben.
• Write
  Backups: Wenn Sicherungen erstellt werden sollen, bevor neue Daten
  von XML-Import in die DB geschrieben werden, muss diese Einstellung
  ausgewählt sein. Für die Verwendung mit Static Publish ist
  sie jedoch nicht relevant.
• Backup
  Path: Sofern Sicherungen erstellt werden, wird mit dieser
  Einstellung ihre Ablageposition angegeben (s. o.: "Write
  Backups").

Alle
Pfadangaben, die in den oben genannten Einstellungen gemacht werden,
sind relativ zum Wurzelverzeichnis (DOCUMENT_ROOT) des Webservers.
Sollen absolute Pfade verwendet werden, muss ein „/“
vorangestellt werden.

Konfiguration der Erweiterung „XML-Import“ im Extension Manager.

Auch die
Erweiterung Static Publish kann während der Installation im
Extension Manager konfiguriert werden:

• Publish
  Dir: In dieser Einstellung wird das Verzeichnis festgelegt, in
  welches die HTML-Dateien beim Export-Prozess geschrieben werden.

Erneut sind
alle Pfadangaben relativ zum Wurzelverzeichnis des Webservers (s. o).

Konfiguration der Erweiterung „Static Publish“ im Extension Manager.

Um nun
HTML-Seiten exportieren (veröffentlichen) zu können, gehen
wir wie folgt vor: Auf der Startseite wählen wir im Klickmenü
den Eintrag „Unterseiten veröffentlichen (3 Ebenen)“. Per
PageTS lassen sich hier noch weitere Konfigurationen vorbereiten, die
das Menü erweitern.

Aufruf des Menüs und Auswahl einer Veröffentlichungstiefe von 3 Ebenen.

Wenn uns die Voreinstellungen im Abschnitt
„Einstellungen“ auf der nächsten Seite zusagen, klicken wir
am Ende der Seite im Abschnitt „Zum Export Modul springen“ auf
den Link „Diese Konfiguration benutzen“. Haben wir etwas an den
Voreinstellungen geändert, muss die neue Konfiguration noch
durch einen Haken in der Checkbox „Konfiguration des Exports
abgeschlossen“ bestätigt werden. Das Betätigen der
Schaltfläche „Send“ aktualisiert daraufhin die Vorschau des
zu publizierenden Seitenbaum-Bereichs und schreibt den Link „Diese
Konfiguration benutzen“ neu. Nach einem
Klick auf den Link „Diese Konfiguration benutzen“ kommen wir zum
nächsten Schritt, in dem die URLs der zu exportierenden Seiten
in die Datenbank geschrieben werden. Sobald die
Datenbank-Eintragungen durchgeführt wurden, bringt uns der Link
„Auswahl zurücksetzen“ zum nächsten Schritt.

Import der zu exportierenden Seiten in die Datenbank.

Hier wählen
wir aus dem Funktionsmenü den Eintrag „Export Dateien“.
Nachdem die Seite neu geladen wurde, wählen wir aus der
Drop-Down-Box im Abschnitt „Export: Datei(DB) -> HTML Datei“
den Eintrag Static Publish. Die Auswahl wird mit einem Klick auf die
Schaltfläche „Auswählen“ bestätigt. Nach erneutem
Laden der Seite mit der gewählten Konfiguration muss im
Abschnitt „Aktuelle Einstellungen für den Export“ ggf. noch
in der Drop-Down-Box „HTML-Dateien zu Datensätzen auf welcher
Seite exportieren“ der gewünschte Datensatz für die
Veröffentlichung ausgewählt werden. Auch diesmal wird die
zu verwendende Konfiguration mit einem Klick auf die Schaltfläche
„Auswählen“ bestätigt. Nachdem die Seite geladen wurde,
starten wir den Export-Prozess, in dem die HTML-Dateien in das zuvor
festgelegte Verzeichnis geschrieben werden, mit einem Klick auf die
Schaltfläche „Bestätigen“. Da vermutlich nicht alle
Seiten innerhalb von 30 Sekunden erzeugt werden können, wird die
Seite kurz vor Ablauf dieser Zeitspanne neu geladen und der Export
der Seiten durch einen Klick auf die Schaltfläche „Weiter“
fortgeführt. Dieser Vorgang muss so lange wiederholt werden, bis
die Meldung „Der Export von x HTML-Dateien basierend auf y
Datensätzen ist abgeschlossen“ erscheint.

Auswahl der Export Funktion.

Export der HTML-Dateien.

Ein Export
der Seiten kann zu einem beliebigen späteren Zeitpunkt durch
Auswahl des Backend-Moduls „XML-Import“ im Abschnitt „Web“
erfolgen. Dazu wählen wir „Export Dateien“ aus dem
Funktionsmenü der neu geladenen Seite und gehen vor wie soeben
beschrieben.

Eine Übersicht über
bisherige Veröffentlichungen erhalten wir, indem wir im
Abschnitt „Web“ das Backend-Modul „XML-Import“ auswählen
und auf der neu geladenen Seite im Funktionsmenü
„Veröffentlichungen Übersicht“ auswählen. Wir
haben hier die Möglichkeit, die Details jeder Veröffentlichung
anzusehen und nicht mehr benötigte Veröffentlichungen zu
löschen.

Nun müssen
die fertigen HTML-Seiten nur noch mit Hilfe des Backend-Moduls Static
Upload vom TYPO3-Server auf den Live-Server übertragen werden. Nachdem das Modul über den
Extension Manager installiert wurde, ist der Zugriff darauf im
Abschnitt „d.k.d Werkzeuge“ über den Eintrag Static Upload
möglich.

Beim ersten Aufruf des Moduls sehen
wir auf einer Übersichtsseite, welche Upload-Dienste auf dem
TYPO3-Server verfügbar sind. Wenn ein installierter
Upload-Dienst als nicht verfügbar markiert ist, kann das unter
anderem daran liegen, dass er für das verwendete Betriebssystem
nicht vorgesehen ist oder dass ein von dem Dienst benötigtes
Programm auf dem TYPO3-Server nicht gefunden wird.

Übersicht der installierten Upload Dienste.

Wählen
wir „Statischer Upload“ aus dem Funktionsmenü, so erhalten
wir eine Drop-Down-Box mit allen Domain-Einträgen unserer
TYPO3-Installation. Wenn wir jetzt einen der Einträge auswählen
und auf die Schaltfläche „Seiten übertragen“ klicken,
wird der Upload-Vorgang im Hintergrund ausgeführt. Sobald der
Vorgang beendet ist, erhalten wir darüber eine Benachrichtigung
per E-Mail.

Alle
Einstellungen für einen Upload-Vorgang werden mittels TypoScript
vorgenommen. Liegt für einen TYPO3-Domain-Eintrag keine
entsprechende TypoScript-Konfiguration vor, wird eine Fehlermeldung
angezeigt.

Die Verwendung von TypoScript für
die Konfiguration des Upload-Vorgangs hat den Vorteil, dass wir
flexibel auf die Konfiguration zukünftiger Upload-Dienste
reagieren können, ohne dass eine Zeile PHP geschrieben oder
geändert werden muss. Für den Upload-Dienst
„staticUpload: SCP“ könnte die TypoScript-Konfiguration in
etwa so aussehen:

0: service.staticUpload {
1: www_example_com {
2: server = www.example.com
3: username = root
4: path_to_php = /usr/bin
5: path_to_scp = /usr/bin
6: options = -i /var/lib/wwwrun/.ssh/www.example.com_dsa
7: local_dir = /srv/www.local.example.com/htdocs/publish/*
/srv/www.local.example.com/htdocs/fileadmin
/srv/www.local.example.com/htdocs/uploads
/srv/www.local.example.com/htdocs/typo3temp
8: remote_dir = /srv/www.example.com/htdocs
9: logfile_dir = /tmp
10: service = scp
11: email = john.doe@example.com
12: }
13: }

Gerade bei
der Verwendung von TypoScript zu Konfigurationszwecken sind wir auf
einige Schwierigkeiten gestoßen, die an dieser Stelle noch
gesondert behandelt werden sollen, zumal ähnliche
Fragestellungen des Öfteren auf diversen TYPO3-Mailinglisten
auftauchen. Besonders wichtig ist darunter die Einbindung der
richtigen PHP-Klassen:

1: // DEFAULT initialization of a module [BEGIN]
2: unset($MCONF);
3: require ('conf.php');
4: require ($BACK_PATH.'init.php');
5: // DEFAULT initialization of a module [END]
6:
7: require_once( t3lib_extMgm::extPath('dkd_staticupload') .
'mod1/class.tx_dkdstaticupload_module1.php' );
8:
9: // TimeTrack'ing is needed e.g. by t3lib_TStemplate
10: require_once(PATH_t3lib.'class.t3lib_timetrack.php');
11:
12: $TT = new t3lib_timeTrack;
13: $TT->start();
14: $TT->push('','Script start (dkd_staticupload/mod1)');
15:
16:
$GLOBALS['LANG']->includeLLFile('EXT:dkd_staticupload/mod1/locallang.php');
17:
18: // Make instance:
19: $SOBE = t3lib_div::makeInstance('tx_dkdstaticupload_module1');
20: $SOBE->init();
21: $SOBE->main();
22: $SOBE->printContent();
23:
24: $TT->pull();

In der Datei „class.tx_dkdstaticupload_module1.php“ haben wir
folgende Klassen eingebunden:

1: require_once ($BACK_PATH.'template.php');
2:
3: require_once (PATH_t3lib.'class.t3lib_scbase.php');
4: require_once (PATH_t3lib.'class.t3lib_tstemplate.php');
5: require_once (PATH_t3lib.'class.t3lib_page.php');

Das funktioniert soweit ganz gut, erzeugt aber PHP-Warnungen, die
besagen, dass einer Array-Funktion nicht der richtige Variablentyp
übergeben wird:

1: {main}()
2: tx_dkdstaticupload_module1->init()
3: t3lib_TStemplate->start()
4: t3lib_TStemplate->matching()
5: t3lib_matchCondition->match()
6: reset()

Dieser Fehler
lässt sich zu der Variablen „$this->altRootLine“
zurückverfolgen, die immer vom Typ Array sein sollte. In unserem
Fall wird besagte Variable in Zeile 4 des Stack Trace in eine leere
Variable vom Typ String umgewandelt. Eine Lösung wäre, an
dieser Stelle in Zeile 5 zu prüfen, ob „$this->altRootLine”
vom Typ Array ist und – sollte dies nicht der Fall sein – die
Variable erneut mit dem richtigen Typ zu generieren:

1: if ( !is_array( $this->altRootLine ) ) {
2: $this->altRootLine = array();
3: }

Mit der
aktuellen Version von TYPO3 tritt dieses Problem nicht mehr auf, da
die in diesem Zusammenhang vorgeschlagene Lösung Bestandteil des
TYPO3core geworden ist.

Eine andere Schwierigkeit, die bei der
Entwicklung der Upload-Dienste aufkam, bestand darin, eine geeignete
Lösung zum Umgehen der bekannten Probleme mit der PHP-Direktive
„max_execution_time“ zu finden. Aufgrund der potentiell höheren
Upload-Datenmenge konnten wir hier die bei Static Publish genutzte
Methodik der Start- und Stop-Punkte nicht verwenden. Stattdessen
hatten wir beschlossen, den eigentlichen Upload-Vorgang als Prozess
im Hintergrund ablaufen zu lassen und über seine Beendigung per
E-Mail zu benachrichtigen. Auf Win32-Systemen gestaltete sich dies
allerdings etwas schwieriger, weshalb die entsprechenden Techniken
hier noch einmal dargestellt werden:

Linux:
1: $cmd= sprintf( '%sphp "%scli/exec_bg_cli.php" "%s" 2>&1 &',
$conf['path_to_php'], t3lib_extMgm::extPath( $this->extKey ),
base64_encode( serialize($conf) ) );
2: exec( $cmd );

Win32:
1: $cmd= sprintf( '%sphp -q "%scli/exec_bg_cli.php" "%s"',
$conf['path_to_php'], t3lib_extMgm::extPath( $this->extKey ),
base64_encode( serialize($conf) ) );
2: // Initialize COM object to run the script as background process
3: $wsh = new COM("WScript.Shell");
4: $wsh->Run( $cmd, 7, false);
5: $wsh = null;

Da wir in den
Upload-Diensten die CLI API von TYPO3 verwenden, ist darauf zu
achten, dass ein Backend-Benutzer mit dem Namen „_cli_staticupload“
angelegt sein muss, da nur dieser es den Upload-Diensten ermöglicht,
auf die CLI API von TYPO3 zuzugreifen.

Wie bereits
auf der Tycon3 2005 angekündigt, hat die d.k.d Internet Service
GmbH die in diesem Artikel beschriebenen TYPO3-Erweiterungen
veröffentlicht. Im TYPO3 Extension Repository und im CVS
Repository von TYPO3xdev sind zurzeit die Erweiterungen dkd_tools,
dkd_staticupload, dkd_staticuploadscp und dkd_staticuploadwinscp zu
finden, während dkd_xmlimport und dkd_staticpublish bislang nur
über das CVS Repository von TYPO3xdev erhältlich sind.

Die vorgestellten Extensions sind
sicherlich nicht perfekt, erfüllen jedoch die Anforderungen,
nach denen sie entwickelt wurden. Verbesserungen daran führen
wir gerne mit Hilfe der TYPO3-Community durch. Über Anregungen
und Ideen an die E-Mail-Adresse typo3@dkd.de freuen wir uns sehr.

Der Autor

Andreas Otto arbeitet als TYPO3- und Web-Entwickler für die d.k.d Internet Service GmbH in Frankfurt am Main. Neben seiner Arbeit für die d.k.d Internet Service GmbH kümmert er sich für die TYPO3-Community um die Verwaltung der Schreibberechtigungen auf die CVS Repositories der Projekte TYPO3 und TYPO3xdev bei SF.net.