Zur alltäglichen Arbeit eines TYPO3-Administrators gehört der Umgang mit TypoScript. Für viele ist die Komplexität dieses mächtigen Konfigurationswerkzeugs eine Hürde für schnelles und effizientes Arbeiten. Mit steigenden Anforderungen an eine Website wachsen auch die Anforderungen an den Administrator, der den Überblick über viele 100 bis 1.000 Zeilen Code behalten muss. Der Aufwand lässt sich mit einem System zur eindeutigen Strukturierung der Konfigurationen für große, aber auch kleine TYPO3-Projekte entscheidend verringern.

Stündlich werden auf den TYPO3-Mailinglisten Fragen zu TypoScript gestellt und nicht selten schelten sich die Fragenden nach einer Antwort selber, Tomaten auf den Augen gehabt zu haben, wenn nach näherer Betrachtung der Fehler offensichtlich war. Wirft man einen Blick auf die geposteten Script-Schnipsel, ist die Ursache oft ein unaufgeräumtes und unübersichtliches Gewirr an TypoScript-Anweisungen, die es schwer machen, schon bei wenig Code den Überblick zu behalten.

Eine große Erleichterung bietet die Fähigkeit des TypoScript-Parsers, mehrere hierarchisch aufeinander aufbauende TypoScript-Templates miteinander zu kombinieren. Dadurch lässt sich die Konfiguration in verschiedene Templates aufteilen, die alle möglichen Websites in ein und dieselbe Grundstruktur aufteilen. So findet sich ein Administrator in allen von ihm betreuten Projekten schnell zurecht, selbst wenn er länger nicht an einer Website gearbeitet hat.

Ein hilfreicher Ansatz ist es, die verschiedenen Aspekte einer Website in ihrer Konfiguration strikt voneinander zu trennen. In einem TypoScript-Template, das Navigationselemente definiert, hat beispielsweise die Einbindung von CSS-Stylesheets nichts zu suchen, denn beide Bestandteile haben miteinander nichts zu tun. Damit orientiert sich dieser Ansatz grob am aspektorientierten Programmieren, dem Programmierparadigma, dem auch das kommende TYPO3 5.0 unterliegt.

TypoScript-Templates, die unterschiedliche Aspekte behandeln, werden im Basis-Template der Root-Page zusammengeführt.

Aspekte, die fast jede aktuelle Website besitzt, sind die Basiskonfiguration (config), sprachspezifische Einstellungen (languages), vermutlich Suchmaschinenoptimierung (seo), Navigationselemente (navigation) und diverse TYPO3-Erweiterungen.

Kombiniert werden diese Aspekte in einem separaten TypoScript-Template, das die Struktur des (X)HTML-Templates widerspiegelt (structure), und durch das einfache Einbinden der verschiedenen Templates in das Basis-Template der Root-Page. Dabei ist es egal, ob mit TemplaVoilà [1] oder Markern gearbeitet wird. Wichtig ist dagegen die Reihenfolge, mit der die verschiedenen Aspekte in das Basis-Template eingebunden werden. Denn die in einem TypoScript-Template hinterlegten Definitionen stehen nur in den, von oben nach unten betrachtet, nachfolgenden Templates zur Verfügung.

„config“ enthält Konfigurationselemente, die auf das gesamte Projekt anwendbar sind, zum Beispiel die Linkerzeugung, die Konfiguration des (X)HTML-Headers, das Einbinden von CSS und JavaScript sowie das Verhalten des Systems bei vorhandenen oder fehlenden Übersetzungen von Inhalten. Das Template „config“ muss als Erstes eingebunden werden. In „languages“ werden die verschiedenen Sprachen und deren IDs festgelegt.

# Hebrew
[globalVar = GP:L = 12]
language = il
locale_all = il_IL
sys_language_uid = 12
htmlTag_setParams = xml:lang="il" lang="il" dir="rtl"
[global]

Listing 1 ist ein Ausschnitt aus dem TypoScript-Template „languages“, das Bestandteil eines real existenten Projekts ist, in dessen Rahmen 19 Sprachen und verschiedene Inhalte für 66 Länder koordiniert werden. Auf die Konfiguration länderspezifischer Inhalte (countries) wird nicht weiter eingegangen, da diese im Kern eine Erweiterung von „languages“ darstellt.

Auf den ersten Blick zeigt Listing 1 einen Bruch mit dem Paradigma der aspektorientierten Konfiguration, denn die Anweisung „htmlTag_setParams“ gehört in die Basiskonfiguration (config), da sie die Auszeichnung des (X)HTML-Headers steuert. Das Beispiel zeigt allerdings auch, dass einzelne Bestandteile der Konfiguration mit unterschiedlichen Prioritäten dem einen oder anderen Aspekt zugeordnet werden müssen. Hier kann jeder TYPO3-Administrator seinen eigenen Vorlieben frönen. Die Erfahrung hat gezeigt, dass die Festlegung „alle sprachspezifischen Bestandteile der Basiskonfiguration werden in languages definiert“ von Vorteil ist. Damit wird die nicht eindeutige Zuordnung von Konfigurationsanweisungen zu einem Aspekt aufgehoben.

Das Template „seo“ enthält alle die Suchmaschinenoptimierung betreffenden Aspekte, zum Beispiel das manuelle Einbinden der Erweiterung „metatags“ [2]. Metatags haben sprachspezifische Werte und müssten demnach in „languages“ definiert werden, denn die Übersetzung des Inhalts impliziert auch die Übersetzung der zugehörigen Metatags. Anstatt diese für jede Sprache durch TypoScript zu realisieren, wird die Wertzuweisung für die Metatags vollständig aus dem TypoScript entfernt und über den Datensatz „Alternative Seitensprache“ festgelegt. Nur das Einbinden der Erweiterung wird durch TypoScript bewerkstelligt. Anweisungen, die durch die Objekte „page“ und „config“ ausgewiesen werden und sich auf SEO auswirken, gehören per Definition, sofern sie nicht sprachspezifisch sind, in das Template „config“, da sie sich auf das gesamte TYPO3-Projekt auswirken.

„navigation“ enthält ausschließlich Elemente, die der Navigation durch die Website dienen.

# HEADER DATA
page.headerData {
	999 >
	999 < plugin.meta
}
frameset.headerData.999 >
# HEADER
lib.header = COA
lib.header {
	# ts languages
	10 < temp.logo
	# folder snippets
	20 = RECORDS
	20 {
		tables = tt_content
		source = id
	}
	30 = TEXT
	30 {
		wrap = <h3>|</h3>
		data = page:subtitle
	}
	# ts navigation
	40 < temp.rootline
}
# LEFTBAR
lib.leftbar = COA
lib.leftbar {
	# ts navigation
	10 < temp.mainnav
}
# FOOTER
lib.footer = COA
lib.footer {
	# ts navigation
	10 < temp.footnav
	# ts tipafriendplus
	20 =< lib.tipafriend
}
# don't tip tip-a-friend
[globalVar = TSFE:id = id]
lib.footer.20 >
[global]

Listing 2 zeigt das TypoScript-Template „structure“, das ebenfalls dem bereits erwähnten Projekt entnommen ist.

In „structure“ werden verschiedene Aspekte zusammengeführt. Am vorliegenden Beispiel lässt sich zusätzlich zeigen, wie sich die Arbeit mit TypoScript durch den Aufbau der einzelnen Templates zusätzlich erleichtern lässt.

Zunächst fällt auf, dass mit „page.headerData“ nun ein offensichtlicher Bruch des Paradigmas der aspektorientierten Konfiguration begangen wird, denn das Objekt „page“ sollte bereits in „config“ behandelt werden. Viele Erweiterungen schreiben Ausgaben direkt in das headerData-Array. Sofern die Zuweisung über das statische Template einer Erweiterung geschieht, ist es jedoch empfehlenswert, die Zuweisungen gebündelt noch einmal manuell zu wiederholen. Dadurch wird verhindert, dass mehrmals Werte an den gleichen Index übergeben werden. Das beugt einer langen Ursachensuche vor, falls die Ausgabe einer Erweiterung nicht erfolgt, weil diese von einer anderen überschrieben wird.

Das Gleiche gilt für eigene Wertzuweisungen in „page.headerData“, über die man schnell den Überblick verlieren kann, wenn diese an verschiedenen Orten der Konfiguration stattfinden. Da „headerData“ also Bestandteile enthält, die im (X)HTML-Header ausgegeben werden, und diese Bestandteile erst feststehen, nachdem zuvor alle Erweiterungen in TypoScript-Templates konfiguriert wurden (siehe Grafik auf der vorherigen Seite), hat die geordnete, manuelle Definition von „page.headerData“ in „structure“ durchaus Vorteile.

Listing 2 enthält verschiedene kurze Kommentare. Zum einen werden die verschiedenen Bereiche der Seitenstruktur hervorgehoben. Das erleichtert das Zurechtfinden in einem langen Template erheblich. Zum anderen wird jede Zuweisung mit einem Hinweis auf den Ort der tatsächlichen Definition versehen. Der Kommentar „#ts languages“ über der Zeile „10 < temp.logo“ sagt also aus, dass die Auswahl des Logos sprachspezifisch ist und im Template „languages“ erfolgt.

Direkt im Anschluss wird durch das Objekt (cObject) „RECORDS“ ein Content-Element eingebunden. Der Kommentar darüber lautet „# folder snippets“ und weist auf eine weitere Möglichkeit hin, TypoScript-Templates schlank zu halten. Die Aufgabenstellung des hier beschriebenen Projekts umfasst die Vorgabe, Besuchern aus verschiedenen Ländern unter einer Domain Inhalte in einer landesspezifischen Standardsprache zu präsentieren. Abhängig von der für einen Besucher geltenden Standardsprache, werden ausgewählte Übersetzungen angeboten, sodass nicht jeder Besucher aus allen dem System bekannten Übersetzungen auswählen kann.

Die Sprachnavigation wird durch die Erweiterung „sr_language_menu“ [3] realisiert. Diese kann sowohl durch TypoScript als auch als Content-Element eingebunden werden. Die Einbindung durch TypoScript müsste entsprechend der aspektorientierten Konfiguration im Template „languages“ stattfinden, da für jede mögliche Sprache verschiedene Sprach-UIDs als alternative Übersetzungen ausgewählt werden müssten. Dementsprechend würde „sr_language_menu“ 19-mal eingebunden und konfiguriert werden. Alternativ könnte die Erweiterung im Template „srlanguagemenu“ durch die Abfrage der Bedingung „[globalVar = GP:L = id]“ für jede Sprache konfiguriert werden. Das wäre allerdings wieder ein Bruch mit dem Paradigma der aspektorientierten Konfiguration. Dieser Bruch und der damit verbundene Overhead lassen sich vermeiden.

Das Verhalten der Erweiterung wird in einem TypoScript-Template einmalig konfiguriert. Ein Systemordner „snippets“, Englisch für „Schnipsel“, dient als Datensammlung. In diesem Ordner wird die Sprachnavigation als Content-Element angelegt und in alle alternativen Seitensprachen übersetzt. Jede Übersetzung kann ihre eigenen alternativen Sprachen selbstständig verwalten. Damit werden drei Fliegen mit einer Klappe geschlagen:

1. Das TypoScript-Template „languages“ wird kurz gehalten.
2. Die Sprachnavigation muss nur ein Mal in „structures“ eingebunden werden.
3. Bei Bedarf können eine oder mehrere Übersetzungen der Sprachnavigation in die Verantwortung eines Redakteurs übergeben werden.

Das Einbinden kleiner funktionaler Einheiten als snippets kann auf vielfältige Art und Weise genutzt werden. Warum nicht die Footer-Navigation (z. B. Startseite, AGB, Datenschutz und Impressum) als Sitemap realisieren? Vorausgesetzt, alle Sprachen liegen in einem Seitenbaum, müsste diese auch für viele alternative Seitensprachen nur ein Mal angelegt werden, da sich die einzelnen Navigationspunkte quasi selbst übersetzen. Wurde die Quelltextgenerierung der Sitemap zuvor in „config“ über „tt_content.menu.20.2“ (einen Überblick über die möglichen Parameter gibt der TypoScript Object Browser) als ungeordnete Liste konfiguriert, muss der Webdesigner diese nur noch mit CSS stylen. Fertig ist die selbstorganisierende, selbstübersetzende Footer-Navigation, die gerade einmal fünf Zeilen TypoScript kostet.

Kurze, für sich stehende Anweisungen können direkt in „structures“ getätigt werden. Im Bereich des Seitenkopfs soll sprachabhängig ein kurzer Einzeiler eingeblendet werden. Dafür wird der Untertitel (subtitle) der Root-Page verwendet. Der Untertitel wird durch die alternativen Seitensprachen übersetzt. Also ist es absolut ausreichend, das Feld einmal als Textobjekt (lib.header.30) in die HTML-Ausgabe zu übernehmen.

Am Ende von Listing 2 wird mit „20 =< lib.tipafriend“ die Erweiterung „tipafriend_plus“ [4] in „structures“ integriert. Drei Besonderheiten lassen sich an dieser unscheinbaren Zeile feststellen:

1. Obwohl es sich um eine Erweiterung handelt, die als Content-Element anlegbar ist, wird diese nicht als „snippet“ eingebunden.
2. Die Erweiterung wird in „lib.“ und nicht in „temp.“ konfiguriert, wie die restlichen TypoScript-Elemente.
3. Die Funktionalität wird als Referenz eingebunden, nicht als echte Kopie.

lib.tipafriend = USER
lib.tipafriend {
	userFunc = tx_tipafriendplus_pi1->main
	templateFile = fileadmin/templates/extensions/tipafriendplus.html
	code = TIPLINK
	typolink.parameter = 18
	htmlMail = 0		
	_LOCAL_LANG.de.link = Weiterempfehlen
	_LOCAL_LANG.en.link = Tip a friend
}

„tipafriend_plus“ kann nach der Installation durch den Extension-Manager direkt verwendet werden. Allerdings muss man dann mit dem vorgegebenen (X)HTML-Template arbeiten. Möchte man ein eigenes (X)HTML-Template einsetzen, muss dieses durch die Konfiguration der Erweiterung in TypoScript erfolgen, denn das Content-Element bietet keine Möglichkeit, ein eigenes (X)HTML-Template auszuwählen. Da man also auf die Konfiguration der Erweiterung durch TypoScript nicht verzichten kann und deren Verhalten glücklicherweise vollständig durch TypoScript steuerbar ist, bietet es sich an, auf den Einsatz des Content-Elements zu verzichten.

Eine weitere Überlegung führt zu der Entscheidung, die Erweiterung in „lib.“ anstatt in „temp.“ zu konfigurieren. Das TypoScript-Template soll in möglichst vielen Projekten einsetzbar sein, ohne dass es jedes Mal neu definiert werden muss. Kopieren, einfügen und Link-Parameter anpassen, muss genügen. Darüber hinaus soll die Konfiguration sowohl in TypoScript-Templates verwendet werden können als auch direkt in TemplaVoilà-Datenstrukturen integrierbar sein. Das kann zum Beispiel hilfreich sein, wenn der Link Bestandteil eines flexiblen Content-Elements sein muss. Ein klassisches Beispiel sind so genannte „tabbed pages“, die den Besucher auf einer Einzelseite durch verschiedene Informationen browsen lassen, ohne dass dieser von einer URL zur nächsten springt. Das Design sieht vor, dass der Link zum Weiterempfehlen in die Leiste der Reiter, die zum Umschalten dienen, integriert ist.

Hinter dem Link „Produkt weiterempfehlen“ versteckt sich die Erweiterung „tipafriend_plus“.

Zu Beginn des Renderings einer Seite fügt der TypoScript-Parser alle vorhandenen TypoScript-Templates zu einer Gesamtkonfiguration zusammen. Anschließend wird „temp.“ gelöscht und danach das Ergebnis im Cache abgelegt. Erst jetzt greift TYPO3 auf das TypoScript zu und stellt die Seiteninhalte zusammen. Wäre „tipafriend_plus“ in „temp.“ konfiguriert, stünde die Erweiterung zum Zeitpunkt der Seitengenerierung nicht mehr zur Verfügung.

Durch die Verwendung von „lib.“ wird eine Funktionalität also global definiert und kann jederzeit eingesetzt werden. Eine Zuweisung durch den „<“-Operator legt eine echte Kopie des auf der rechten Seite des Operators stehenden Objekts an und weist diese dem auf der linken Seite des Operators stehenden Objekt zu. So entstehen zwei identische Instanzen eines Objekts. Dagegen ist eine Referenz nicht mehr als ein Zeiger auf ein Objekt. Auf das Beispiel in Listing 2 angewendet, heißt das, dass in „lib.footer.20“ ein Hinweis hinterlegt wird, der sagt: „Wenn Du wissen willst, was an dieser Stelle geschehen soll, schau in „lib.tipafriend“ nach“.

Werden große Objekte in einem Projekt mehrmals mit identischer Konfiguration verwendet, ist es empfehlenswert, nach Möglichkeit mit Referenzen zu arbeiten. Der Kopiervorgang ist für den Webserver wesentlich aufwändiger als das Anlegen eines Zeigers auf ein schon vorhandenes Objekt. Ein Objekt ist eine komplexe Datenstruktur. Ein Zeiger ist, vereinfacht ausgedrückt, nicht mehr als eine Zahl. Referenzen sparen im Vergleich zu Kopien also Speicherplatz und Prozessorlast. Die Verwendung von Referenzen kann verwirrend sein, solange man ihre Eigenarten nicht kennt. Vor dem Einsatz empfiehlt sich daher die eingehende Lektüre des Kapitels „1.8 Content Objects (cObjects)“ der TYPO3-Core-Documentation [5].

Im Rahmen der aspektorientierten Konfiguration wird jede Erweiterung als ein eigener Aspekt betrachtet und dementsprechend in einem eigenen TypoScript-Template konfiguriert. Da das zuvor besprochene Template „languages“ nur Elemente der Basiskonfiguration steuert, also sprachabhängige Varianten der in „config“ enthaltenen Anweisungen spezifiziert, stellt die sprachabhängige Konfiguration von Erweiterungen in eigenen Templates keinen Bruch mit dem Paradigma dar. Aus Gründen der Übersichtlichkeit ist es allerdings sinnvoll, im TypoScript von Erweiterungen nicht für jede Sprache die Bedingung „[globalVar = GP:L = id]“ abfragen zu müssen.

Dies ermöglicht die Fähigkeit von TYPO3, sprachspezifische Ausgaben von Erweiterungen durch Lokalisierung zu steuern. Dadurch müssen Texte in den zugehörigen (X)HTML-Templates nicht fest kodiert werden, sondern können durch „###MARKER###“ gesetzt werden. Der eingesetzte Text wird aus der Datei „locallang.xml“ gelesen, die Übersetzungen für jede benötigte Sprache enthalten kann.

Übersetzungen könnten also direkt in dieser Datei stattfinden. Das ist meist der Fall, wenn man die Übersetzung von Erweiterungen über den Extension Manager lädt. Möchte man eigene Übersetzungen verwenden oder ist eine Erweiterung nicht in den benötigten alternativen Sprachen verfügbar, wären Manipulationen der Datei „locallang.xml“ nach einem Update allerdings verloren. Glücklicherweise können die durch Erweiterungen ausgegebenen Texte auch durch TypoScript übersetzt werden, siehe Listing 3.

Mit „_LOCAL_LANG.languageKey.label“ teilt man TYPO3 mit, für welche Sprache man welchen Text definieren möchte. „languageKey“ steht dabei für die jeweilige Sprache. Für „label“ muss der Index des Labels aus der Datei „locallang.xml“ eingesetzt werden. Auf diese Weise kann man Texte für alle Marker definieren, die durch die Erweiterung berücksichtigt werden.

Der Vorteil dieser Methode liegt auf der Hand: Auf die Abfrage der Bedingung „[globalVar = GP:L = id]“ kann verzichtet werden. Zusätzlich muss nicht für jede Sprache ein (X)HTML-Template gepflegt werden, was fehleranfällig und aufwändig wäre.

Damit die Definition von Textausgaben durch eine Erweiterung mit TypoScript funktioniert, muss diese entsprechend programmiert sein. Wird der Mechanismus, der die Inhalte aus der Datei „locallang.xml“ einliest, nicht angesprochen, werden auch die Definitionen im TypoScript nicht berücksichtigt.

In den TYPO3 Coding Guidelines [6] ist die Behandlung von Sprachen fest definiert. Leider halten sich viele Entwickler von Erweiterungen nicht an diese Vorgaben oder bieten nicht für alle Textausgaben Marker an. Streng genommen dürften solche Erweiterungen nicht als „stable“ markiert im TER zur Verfügung gestellt werden. Da auch diese Vorgabe oft nicht eingehalten wird, muss vor dem Einsatz einer Erweiterung also festgestellt werden, ob die Lokalisierung korrekt und vollständig Verwendung findet. Im Zweifelsfall bleibt leider doch nur der Umweg über die Pflege von (X)HTML-Templates für jede Sprache. Das beugt zumindest dem Verlust eigener Übersetzungen durch das Update der Erweiterung vor.

Die meisten Erweiterungen sind nach der Installation direkt einsetzbar. In der Regel ist jedoch ein individueller Einsatz erwünscht, weshalb die Konfiguration von Erweiterungen ein wesentlicher Bestandteil der Administration von TYPO3 ist.

Die Einarbeitung in umfangreiche Konfigurationsskripte kann mit einem erheblichen Zeitaufwand verbunden sein, den viele scheuen. Herumprobieren führt nicht immer zum gewünschten Ergebnis und so sieht man nicht wenige TYPO3-Installationen, für deren Konfiguration das TypoScript von Erweiterungen „der Sicherheit halber“ vollständig in ein eigenes TypoScript-Template kopiert wurde. Das verringert den tatsächlich anfallenden Aufwand jedoch nur selten, denn eine umfangreiche Konfiguration reduziert sich mit dieser Methode nicht und bleibt unübersichtlich. Wer effizient mit TypoScript arbeiten möchte, kommt um die Aufgabe, sich in die Konfiguration von Erweiterungen einzuarbeiten, nicht herum. Drückt man sich vor dieser Arbeit, kommt die Frage „Wie geht’s, wo steht’s?“ spätestens dann wieder auf, wenn man nach einer Pause wieder Hand an die Konfiguration legen muss.

Eine gute Erweiterung liefert ein streng nach Constants und Setup aufgeteiltes TypoScript. Der Sinn und Zweck dieser Trennung ist, die Zuweisung von Werten für Variablen und funktionale Anweisungen voneinander zu unterscheiden. Die Festlegung der maximalen Breite einer durch eine Erweiterung ausgegebenen Grafik gehört in die Constants. Durch welchen Quelltext diese Grafik gewrapped wird, ist eine Frage, die im Setup beantwortet werden sollte. Die in den Constants festgelegten Werte müssen im Setup an die Konfiguration der Erweiterung übergeben werden, wodurch der Umfang des notwendigen TypoScripts wieder wächst. Diese Zuweisung sollte durch die Entwickler im „static template“ der Erweiterung bewerkstelligt werden, sodass sich der Anwender nicht darum kümmern muss.

Der Aufwand zur Konfiguration einer Erweiterung lässt sich also durch die Trennung von Constants und Setup stark reduzieren. Des Weiteren sollte nicht mehr TypoScript in das eigene Template übernommen werden, als für den Einsatz einer Erweiterung im Rahmen eines Projekts notwendig ist. In aufgeräumten, übersichtlichen TypoScript-Templates lassen sich Fehler sehr viel schneller entdecken und beheben.

Die aspektorientierte Konfiguration von TYPO3 ist ein Ansatz, die Arbeit mit TypoScript für Administratoren zu erleichtern. Die in diesem Artikel vorgestellte Methode ist sicherlich nur eine von vielen möglichen Interpretationen dieses Paradigmas. In der Praxis hat sich gezeigt, dass die vorgestellte Umsetzung vielfältig einsetzbar ist. Dadurch wird nicht nur die Administration von individuellen Websites erleichtert, sondern gleichzeitig eine Vereinheitlichung der Arbeit über viele verschiedene Projekte hinweg erreicht.