Pflichtenhefte offenbaren oft viele Überraschungen. Im vorliegenden Beispiel lag eine der größten Herausforderungen darin, TYPO3 mit Oracle als Datenbank zu betreiben. Neben dieser Anbindung fanden sich viele kleine und große Wünsche für Änderungen an TYPO3, seinen Erweiterungen oder für neue Erweiterungen. Nach Projektabschluss kamen so knapp 100 reine Kern- oder Extensionpatches, ein Dutzend neue Erweiterungen und eine komplette Überarbeitung des DBAL (Datenbank-Abstraktionslayer) sowie des Workspacesystems zusammen.

Die TYPO3-Featureliste und diverse Publikationen suggerieren, dass TYPO3 praktisch mit jeder Datenbank funktionieren kann. Hierfür existiert der DBAL von Karsten Dambekalns, der als Bindeglied zwischen TYPO3 und anderen Datenbankwelten fungieren soll.

Um keine falsche Kritik aufkommen zu lassen: Betrachtet man die Applikationsstruktur des derzeitigen TYPO3 bleibt praktisch nur der DBAL, um fremde Datenbanken an TYPO3 anzudocken. Das bringt in seiner aktuellen Ausbaustufe allerdings noch viele Probleme mit sich. Das gilt zum Beispiel, wenn die Datenbank (wie eben Oracle) nicht größtmöglich kompatibel mit dem MySQL-Sprachschatz ist oder komplexere Anfragen benötigt werden. Oracle wird vom DBAL laut Spezifikation zwar unterstützt, dennoch scheitert ein Versuch, TYPO3 mit Oracle zu verbinden spätestens dann, wenn Standarderweiterungen wie TemplaVoila, die Mediendatenbank oder „tt_news“ eingesetzt werden sollen.

Nach dem Entfernen verschiedenster Fehler und der Beachtung einer großen Anzahl von Oracle-Besonderheiten wurde schnell klar, dass die überarbeitete Version des DBAL zukünftig nur noch für Oracle sinnvoll nutzbar sein wird. Neben dem DBAL musste weiterhin praktisch jede Erweiterung ausführlich auf mögliche Inkompatibilitäten hin geprüft werden. Sehr oft wurden dann Datenbankanfragen generalisiert oder konkret auf Oracle umgeschrieben.

Die Nutzung des DBAL bedeutet grundsätzlich einen Performanceverlust, da jede Anfrage durch ein Zwischensystem geleitet und dort bearbeitet wird. Dieser Verlust wurde auf zwei Arten minimiert. Zum einen wurde der PHP-Beschleuniger „eAccelerator“ [1] eingesetzt und zum anderen dem DBAL ein Zwischenspeichermodul spendiert, damit ein großer Teil der Anfragen nicht neu berechnet werden muss.

Der Hauptverlust an Performance tritt jedoch interessanterweise bei jedem Aufruf im PHP-Oracle-Treiber auf, was sich durch Profiling schnell nachweisen lässt. Hier sind die Möglichkeiten der Einflussnahme gering bis gar nicht vorhanden.

Ein guter Weg, um der Seitenausgabe von TYPO3 in dieser Konstellation noch Geschwindigkeit abzuringen, ist die Nutzung von separaten Frontend-Caches (auf Ausgabe- oder Datenbankbasis). Schließlich bedeutet jede Anfrage, die nicht an die Datenbank gestellt wird, einen Geschwindigkeitsvorteil. Aufgrund des statischen Exports war dies für dieses Projekt jedoch nicht nötig. Es wäre im Umkehrschluss sogar hinderlich gewesen. Im Backend macht das Zwischenspeichern von Seiten oder Daten wiederum nur wenig Sinn, denn der Redakteur will die aktuellen Inhalte sehen.

Im Rückblick bleibt zu sagen: Dieses Projekt hat den Beweis angetreten, dass man mit den aktuellen Techniken ein stabiles TYPO3 mit einer Oracle-Datenbank als Datenquelle aufsetzen kann. Allerdings ist die Geschwindigkeit selbst eines optimierten Systems nicht mit dem eines MySQL-TYPO3 vergleichbar.

Nächster zu bearbeitender Punkt: Das TYPO3-Freigabesystem überzeugt aus Sicht eines Redakteurs nicht unbedingt durch seine übersichtliche und einfache Bedienung. Im Projektverlauf stellte sich dies sehr schnell als Handicap heraus. Aus diesem Grund sollte das Modul einer „Schönheitskur“ unterzogen werden.

Im Gegensatz zu den ursprünglichen Workspaces wurde die Übersichtsdarstellung stark vereinfacht – weniger ist eben oft mehr. Das Freischalten von ganzen Seitenbäumen statt nur einzelner Elemente stand als nächstes Feature auf der Tagesordnung. Berechtigungen des Redakteurs spiegeln sich in der Ansicht nun ebenfalls wieder. Das Workflowsystem für den Freigabeprozess musste auch abspecken, wurde jedoch parallel um eine verfeinerte Eingabemaske für Informationen an den „Chefredakteur“ erweitert. Die Vorschau von Seiten aus dem Workspace erfuhr eine Vereinfachung und erhielt eine intuitivere Lösung für das Freischalten. Nebenbei kann der Redakteur in der Voransicht nun zwischen „Splitscreen“ und „Vollansicht“ wählen.

Die Schulungen nach Projektabschluss zeigten schnell, dass die Änderungen am Freigabemodul bei den Redakteuren gut aufgenommen wurden. Konkret heißt das, dass das System ohne größere Nachfragen einfach genutzt wurde.

Eine andere Herausforderung war das Mediendatenbank-Modul von TYPO3. Es ist zwar eine großartige Möglichkeit, größere Medienmengen zu verwalten. Allerdings sind die Möglichkeiten zur Rechtevergabe nur rudimentär und beschränken sich auf die Kategorien. Aus diesem Manko ergab sich der Wunsch nach einstellbaren Backend-Berechtigungen für jedes einzelne Medium.

Die Grundidee des Systems lehnt sich am TYPO3-Berechtigungssystem an. Hierzu wurde das vorhandene DAM-Modul um die Berechtigungen Lesen, Schreiben und Löschen pro Medium erweitert. Ein spezielles Untermodul sorgt für eine komfortable Verwaltung der Rechte. Doch damit noch nicht genug: Es wurde ein DAM-Administrator eingeführt: Dieser darf alle Medien verwalten, während der normale Redakteur nur Medien nutzen kann, auf die er auch Zugriff hat. Die Berechtigungen ziehen sich bis in die Dateiliste des Rich-Text-Editors durch. Nachträglich wurde das Prinzip zusätzlich auf die DAM-Verzeichnisse ausgedehnt.

Mit dem Backend-Berechtigungssystem für Medien erhielt die Mediendatenbank eines der wenigen wirklich noch fehlenden Features. In der Praxis muss sich jedoch jeder Betreiber einer TYPO3-Installation die Frage stellen, ob der durch Medienberechtigungen erzeugte Zusatzaufwand wirklich in einer sinnvollen Relation zum Nutzen steht.

Im Laufe von längeren Projekten wie diesem wird in der Regel viel Wissen generiert. Im günstigsten Fall wird dieses Wissen schon während der Umsetzung konserviert. Neben dem Wissen, wie etwas funktioniert, zählen vor allem auch konkrete Lösungsansätze zu den Informationen, die auch nach Projektende zum Beispiel für den Kunden verfügbar gehalten werden sollten.

Insbesondere bei umfangreichen Änderungen am TYPO3-Kern und parallel an vielen Erweiterungen ist die Nutzung eines Versionsverwaltungssystems für das gesamte Projekt (auch den Kern) unabdingbar. Spätere Upgrades werden damit erleichtert und vor allem Änderungen und Fehlerkorrekturen nachvollziehbar gemacht. Erklärungen zu komplizierteren Zusammenhängen sind in Wikis gut aufgehoben. Damit dieser Wissenspool nicht zur Einbahnstraße wird, sollte auch im stressigen Agenturalltag auf die Rückführung nicht nur geachtet, sondern diese bestenfalls in den normalen Arbeitsablauf eingebettet werden.

Neu erzeugte Erweiterungen an die TYPO3-Gemeinschaft zu geben, gehört ebenfalls zu den Tugenden von TYPO3-Agenturen. Insbesondere die Erweiterung zur Zugriffsberechtigung der DAM sowie den hier noch nicht genannten DAM-Stichwortmanager wird man in Kürze auf typo3.org finden. Selbiges erfolgt auch beim Oracle-DBAL. Hier steht jedoch vorher noch ein gründliches Aufräumen des Sourcecodes an.

Letzte Herausforderung: Um vorhandene Berechtigungsmechanismen und (so außergewöhnlich es klingen mag) altgediente SSI-Mechanismen weiter nutzen zu können, sollten alle Seiten statisch exportiert werden. Als Nebeneffekt wurde dadurch eine hohe Performance der Seitenausgabe gesichert.

Für den Export standen vorhandene TYPO3-Erweiterungen für statische Exports Pate: „crawler“ und „staticpub“. Dennoch waren die Anforderungen so konkret, dass eine Neuimplementierung als TYPO3-Kommandozeilen-Programm nötig wurde.

Im Grunde sollte das Programm einfach alle Seiten auslesen, Pfade modifizieren, Module wie Newssysteme beachten und das Ergebnis in einem Verzeichnis ablegen. Erschwerend kamen jedoch die geplante hohe Anzahl von Seiten (mehrere tausend) und der Wunsch eines Exports möglichst in Echtzeit dazu. Deshalb wurde ein intelligenter Mechanismus notwendig, der die zu exportierenden Seiten erkennen kann und dann dem Robot konkrete Seiten zum Verarbeiten gibt.

Bestimmte Änderungen an Seiten ziehen leider den Export von weiteren Seiten mit sich: So müssen beispielsweise beim Update des Seitentitels einer Seite automatisch auch alle Seiten geändert werden, die in direktem Bezug zu dieser Seite stehen (zum Beispiel Inhalt und Navigation). Hierfür gab es den Ansatz, mit TYPO3-Hooks zu arbeiten, die erkennen, welche Seiten tatsächlich exportiert werden müssen. Allerdings entschied sich der Auftraggeber für eine andere Lösung, die er selbst implementierte: Die Datenbank selbst sollte über komplexe Triggeranweisungen erkennen, welche Seiten tatsächlich exportiert werden müssen. Neben den einfachen Seiten werden vom Exportsystem auch News, Start- und Stoppzeiten sowie Sprachen berücksichtigt. Erst die Intelligenz hinter dem Robot sorgt dafür, dass auch bei einer tausende Seiten großen TYPO3-Installation einzelnen Seiten oder Bereiche gefahrlos separat exportiert werden können.