Intranet und Internet mit TYPO3 und ORACLE-Datenbank

Für die Berliner Agentur Pinuts media + science realisierte Netresearch die Anbindung der umfangreichen Intranet- und Internetseiten eines Berliner Forschungsinstitutes an die ORACLE-Datenbank. Weitere Anforderungen waren ein intelligenter statischer Seitenexport, eine verbesserte Mediendatenbank und eine stark vereinfachte Nutzung von Live- und Entwurfsumgebung über TYPO3 Workspaces.

Neben der wesentlichen Herausforderung, der Anbindung von TYPO3 an ORACLE, standen von Kundenseite viele kleine und große Wünsche für Änderungen an TYPO3, seinen Erweiterungen oder für neue Erweiterungen im Lastenheft. Die Implementierung dieser Anforderungen brachte für Netresearch zahlreiche Herausforderungen mit sich, die weniger aus den Kundenwünschen als aus dem System an sich resultierten. Nach Projektabschluß
konnten knapp 100 reine Kern- oder Extensionpatches, ein Dutzend neue Erweiterungen und
eine komplette Überarbeitung des DBAL sowie Workspacesystems gezählt werden.

TYPO3 mit ORACLE

Um TYPO3 mit ORACLE zu verknüpfen, wurde nach Betrachtung der Applikationsstruktur des derzeitigen TYPO3 auf den DBAL (Datenbank-Abstraktionslayer) als Bindeglied zwischen TYPO3 und anderen Datenbankwelten zurückgegriffen. Obwohl ORACLE vom DBAL laut Spezifikation unterstützt wird, scheiterte zunächst ein Versuch TYPO3 mit ORACLE zu verbinden, als Standarderweiterungen wie TemplaVoila, die Mediendatenbank oder TT_News eingesetzt werden sollten. Nach dem Entfernen verschiedenster Fehler und der Beachtung einer großen Anzahl von ORACLE Besonderheiten wurde klar, daß die überarbeitete Version des DBAL zukünftig nur noch für ORACLE sinnvoll nutzbar sein wird. Neben dem DBAL mußte weiterhin praktisch jede Erweiterung ausführlich auf mögliche Inkompatibilitäten hin geprüft werden.

ORACLE Geschwindigkeit

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. Zu einen wurde ein PHP Beschleuniger eingesetzt und zum anderen dem
DBAL ein Zwischenspeichermodul spendiert, welches das Neuberechnen eines großen Teils von Anfragen überflüssig machte. Ein guter Weg um der Seitenausgabe von TYPO3 in dieser Konstellation noch Geschwindigkeit abzuringen, war 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.

Intelligenter statischer Export

Um vorhandene Berechtigungsmechanismen und altgediente SSI Mechanismen weiter nutzen zu können, sollten alle Seiten statisch exportiert werden. Als Nebeneffekt wurde dadurch eine hohe Performance der Seitenausgabe gesichert. Die Anforderungen machten hier eine Neuimplementierung als TYPO3 Kommandozeilen-Programm nötig. Das Programm sollte alle Seiten auslesen, Pfade modifizieren, Module wie Newssysteme beachten und das Ergebnis in einem Verzeichnis ablegen. Erschwerend kam die geplante hohe Anzahl von mehreren tausend Seiten sowie der Wunsch eines Exports in Echtzeit dazu. Das Ziel war die Entwicklung einen intelligenten Mechanismus, der die zu exportierenden Seiten erkennen kann und dann dem Robot konkrete Seiten zum verarbeiten gibt.

Da bestimmte Änderungen an Seiten auch den Export von anderen Seiten mit sich bringen,
wurde der Ansatz favorisiert, 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: über komplexe Triggeranweisungen sollte die Datenbank selbst 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 jedoch dafür, daß auch bei einem Tausende Seiten großen TYPO3 einzelne Seiten oder Bereiche gefahrlos separat exportiert werden können.

Berechtigungen fürs Medienmanagement

Bezüglich des Mediendatenbank Moduls von TYPO3 bestand der Wunsch, die nur rudimentär
vorhandenen Möglichkeiten zur Rechtevergabe zu optimieren und einstellbare Backend-
Berechtigungen für jedes einzelne Medium zu schaffen. Hierzu wurde das vorhandene DAM
Modul um die Berechtigungen Lesen, Schreiben und Löschen pro Medium erweitert. Ein
spezielles Submodul sorgt nun für eine komfortable Verwaltung der Rechte. Doch damit nicht
genug: Es wurde auch ein DAM Administrator eingeführt, welcher alle Medien verwalten darf,
während der normale Redakteur nur Medien nutzen kann, auf die er auch Zugriff hat. Mit dem
Backend-Berechtigungssystem für Medien erhielt die Mediendatenbank eines der wenigen
wirklich noch fehlenden Features.

Ein Freigabesystem für jedermann

Da das TYPO3 Freigabesystem, aus Sicht eines Redakteurs betrachtet, nicht unbedingt durch seine übersichtliche und intuitive Bedienung überzeugt, musste das Modul einer
„Schönheitskur“ unterzogen werden. Hierfür wurden die originalen Workspaces stark
vereinfacht. Das Workflowssystem für den Freigabeprozess musste ebenfalls abspecken,
wurde jedoch parallel um eine verfeinerte Eingabemaske für Informationen an den
„Chefredakteur“ erweitert. Auch die Vorschau von Seiten aus dem Workspace erhielt eine
intuitivere Lösung für das Freischalten. Nebenbei kann der Redakteur in der Voransicht nun
zwischen „Splitscreen“ und Vollansicht wählen. Nur einige der Verbesserungen, die von den
Redakteuren gut aufgenommen wurde, wie sich bei Schulungen nach Projektabschluss schnell zeigte - das System wurde nun ohne größere Nachfragen einfach „genutzt“.