Die weite Verbreitung von TYPO3 ist für die Arbeit an Version 5 Segen und Fluch zugleich. Die geplante und notwendige Runderneurung des Systems bedeutet den Bruch mit der seit Jahren aktiv gepflegten Kompatibilität des Systems zu älteren Extensions und Inhalten. Außerdem fällt es mitunter schwer bei Null anzufangen, wenn man den Funktionsumfang und die Flexibilität von TYPO3 vor Augen hat.

Dennoch gibt es gute Gründe für eine fundamentale Erneuerung des Systems von innen heraus:

• Die Komplexität des TYPO3-Kernsystems sorgt für eine lange Einarbeitungszeit und die Architektur ist an einer Grenze angelangt, die die weitere Entwicklung erschwert.
• Das Datenmodell ist zu unflexibel und der direkte, SQL-zentrierte Zugriff verursacht zahlreiche Probleme
• Neue PHP-Versionen bieten wesentlich bessere Möglichkeiten um Objektorientierung umzusetzen, das Fehler-Handling zu verbessern und den Entwicklern durch saubere Schnittstellen Freude zu machen
• Die Nutzung neuer innovativer Techniken wird durch die notwendige Abwärtskompatibilität beschränkt
• Eine neue Architektur kann bessere Konnektivität mit Drittsystemen durch Einbindung von Standardprotokollen wie SOAP oder WebDAV bieten

All diese Gründe führten nach zahlreichen vorbereitenden Diskussionen zur Gründung eines Projekts [1], das die Entwicklung einer neuen TYPO3-Version verfolgt.

Um die weiteren Arbeiten aufeinander abstimmen zu können, wurde eine grundlegende Roadmap erarbeitet [2]. Die Meilensteine sind:

1. Datenzugriff und grundlegende Komponenten
2. Rechte, Internationalisierung, Lokalisierung
3. Das Frontend wird wieder geboren
4. Das Backend erhebt sich aus der Asche

In der Folge sind Preview-Releases geplant, in deren Umfeld weit verbreitete Extensions auf das neue System migriert und weitere Funktionen im Backend implementiert werden. Neben der Entwicklung angepasster Coding-Richtlinien stehen im ersten Schritt vor allem zwei Dinge im Mittelpunkt: die grundlegende Architektur des Systems und die Datenhaltung.

Auf dem Entwicklungs-Server [3] kann der Status der Arbeiten verfolgt werden, ebenso ist dort die aktuelle Code- und Projekt-Dokumentation verfügbar. Wie schnell sich der Status des Projekts verändert, ist momentan nicht abzusehen, daher enthält die Roadmap auch keine Zeitangaben. Mittelfristig ist eine direkte finanzielle Unterstützung der Entwicklung die beste Möglichkeit, die Arbeiten zu beschleunigen.

Mit dem Neuanfang wird es möglich, konsequent objektorientiert zu entwickeln, Fehler der Vergangenheit zu vermeiden und neue Technologien einzusetzen. Ein Beispiel hierfür ist die Behandlung unterschiedlicher Zeichensätze. Bisher kann man in TYPO3 entweder das „zur Sprache gehörige“ Encoding verwenden oder das Gesamtsystem auf ein Encoding festlegen. Damit ist auch die Nutzung von UTF-8 möglich, aufgrund fehlender Unterstützung durch PHP ist dies jedoch mit Problemen verbunden und führt noch nicht dazu, dass wirklich alle Daten im System in UTF-8 kodiert sind.

Mit PHP6 wird eine vollständige Unterstützung für Unicode eingeführt, womit sich auch für die Entwicklung von TYPO3 neue Möglichkeiten ergeben. Um diese Möglichkeiten von Beginn an nutzen zu können, wird PHP6 eine Grundvoraussetzung für den Betrieb von TYPO3 5.0 sein. Diese Entscheidung verzögert die weitere Entwicklung allerdings nicht, da bereits Ende dieses Jahres eine Preview-Version von PHP6 veröffentlicht werden soll.

Die bisherige Speicherung aller Daten in einer relationalen Datenbank ermöglicht zwar große Flexibilität für den Entwickler, wenn es um Abfragen geht. Erweiterungen des Datenmodells führen jedoch schnell zu Tabellenstrukturen, die durch zahlreiche Felder unübersichtlich, fehleranfällig und wenig performant werden. Beliebige Datenstrukturen alternativ als XML abzulegen ist allerdings auch nicht optimal: Die darin enthaltenen Daten können mit SQL nicht durchsucht werden. Kompatibilität ist ein weiteres Problem bei der Nutzung von SQL. Unterschiede zwischen Datenbanksystemen sind nur schwer auszugleichen, wenn das SQL dezentral und in einer Vielzahl von Stilen entwickelt wird.

So wurde bei der Suche nach neuen Methoden zur Datenspeicherung schnell klar, dass ein vollständig hierarchisches System aus Knoten und dazugehörigen Attributen (in der Form von B-Trees) die nötige Flexibilität bietet und zudem sehr leistungsfähig implementiert werden kann. Ein solches Content-Repository hat eine Reihe von Vorteilen:

1. Datenstrukturen sind flexibel und einfach erweiterbar
2. Sicherheit kann auf höherer Ebene sichergestellt werden
3. Daten sind zentral im Repository abgelegt (auch Dateien, Konfiguration etc.)
4. Datenquelle kann abstrahiert werden (bei Speicherung in einem relationalen DBMS ist die Nutzung produktspezifischer Funktionen möglich)

Für den Zugriff auf eine solche Hierarchie aus Knoten benötigt man eine Schnittstelle. Auf der Suche nach solchen Schnittstellen stößt man unweigerlich auf eine Spezifikation aus der Java-Welt: JSR-170 [4]. Diese beschreibt unabhängig von einer konkreten Implementierung eine API zum Zugriff auf Content-Repositories in Java und beinhaltet bereits Methoden zum Session Handling, für Transaktionen und Workspaces.

Da es nicht sinnvoll ist, das Rad immer neu zu erfinden, wird TYPO3 diese API nutzen, um auf das Content-Repository zuzugreifen. Um schnell zu Ergebnissen zu kommen, wird zunächst Apache Jackrabbit genutzt, eine vollständige Implementierung von JSR-170 in Java. Die PHP-Java-Bridge ermöglicht den Zugriff, der bereits grundlegend funktioniert.

Bis zur Veröffentlichung einer fertigen Version von TYPO3 5.0 wird ein solches Repository in PHP implementiert, so dass der Betrieb von TYPO3 auch ohne Java möglich sein wird – dem Datenaustausch mit der Java-Welt steht jedoch nichts mehr im Weg.

Ein Nebeneffekt dieser Entwicklung im Bereich PHP: Es wird eine Implementierung von JSR-170 geben, die auch andere PHP-Projekte nutzen können – eine Möglichkeit, den Datenautausch zwischen unterschiedlichen Systemen grundlegend zu vereinfachen.

Ein wichtiger Punkt bei der Programmierung von TYPO3 5.0 ist die Qualität. Eine saubere Architektur nützt wenig, wenn sie fehlerhaft implementiert ist. Daher wird eine der grundlegenden Regeln sein, für jede Komponente Unit-Tests zu schreiben, wenn möglich noch vor der Implementierung. Eine solche testgetriebene Entwicklung erhöht die Qualität von Software und ermöglicht auch nach größeren Veränderungen die schnelle Überprüfung des Codes.

Es ist zudem möglich, die Tests automatisiert auf dem Entwicklungsserver durchzuführen, so dass für Programmierer und Aussenstehende der aktuelle Status sichtbar wird. Auch ein Testlauf direkt nach jeder Änderung am Code auf dem Entwicklungsserver ist denkbar. Durch solche und weitere Maßnahmen soll sichergestellt werden, dass TYPO3 5.0 auch im Detail noch besser wird als Version 4.

Die Entwicklung von TYPO3 5.0 bedeutet nicht das Ende für Version 4. Da es eine Weile dauern wird, bis Version 5 für den Produktiveinsatz geeignet ist, wird Version 4 parallel weiterentwickelt. Dies sichert die bisherigen Investitionen von Entwicklern, Agenturen und Unternehmen. Die weiteren Änderungen an Version 4 werden neben Bugfixes vor allem Verbesserungen im Bereich der Usability sein. Die dabei erarbeiteten Konzepte kommen auch zukünftigen TYPO3-Versionen zugute.