TYPO3-Versionen und ihre größten Sprünge: Von 4.x bis 14.x
Kein kontinuierlicher Ausbau — mehrere Schnitte
TYPO3 gilt als stabiles, langlebiges CMS. Das stimmt — aber nur halb. Stabilität bedeutet hier nicht Stillstand, sondern das Gegenteil: Die Plattform hat sich mehrfach grundlegend verändert, nicht schrittweise, sondern in erkennbaren Brüchen. Wer das System noch aus der 4.x-Ära kennt, arbeitet heute in einer anderen Architektur, mit anderen Konzepten und anderen Abhängigkeiten.
Die Version 4.5 aus dem Jahr 2011 war die erste LTS-Version überhaupt — ein Signal, dass das Projekt Verlässlichkeit anstrebte. Die Architektur zu dieser Zeit: kein PHP-Namespacing, TemplaVoilà als dominantes Layout-Werkzeug, PHP 5.3 als Basis. Viele Installationen aus dieser Ära laufen noch heute in produktiven Umgebungen. Das ist das eigentliche Problem.
Die wichtigsten Versionssprünge im Überblick
6.2 (2014): Der erste große Schnitt
Mit 6.2 begann eine neue Phase. PHP Namespaces zogen ein, der File Abstraction Layer (FAL) ersetzte die direkte Dateiverwaltung, Extbase und Fluid wurden zur kanonischen Basis für Extension-Entwicklung. Das war Fortschritt — aber für Extensions aus der 4.x-Ära bedeutete es: Neuschreiben oder aufgeben. Kompatibilität war die Ausnahme, nicht die Regel.
7.6 (2015): Symfony zieht ein
Die Symfony-Komponenten kamen, zunächst partiell: Dependency Injection, PSR-konformes Logging. Das Backend erhielt ein Redesign auf Bootstrap-Basis, die PHP-7-Kompatibilität wurde eingeführt. Performance-Gewinne auf der einen Seite, erneuter Anpassungsbedarf auf der anderen.
8.7 (2017): Symfony vollständig, Doctrine statt direktem DB-Zugriff
Mit 8.7 war Symfony vollständig integriert. Wichtiger noch: Doctrine DBAL ersetzte den direkten Datenbankzugriff, der zuvor verbreitet war. Das Site-Package-Konzept etablierte sich als Standard für Theme-Entwicklung. Wer bis dahin eigene DB-Abfragen in Extensions gepflegt hatte, musste umsteigen.
9.5 (2018): URL-Routing
Die Site Configuration kam — und damit sauberes URL-Routing, das zuvor über TypoScript-Konstrukte und externe Extensions wie realurl abgebildet werden musste. Fluid Styled Content wurde modernisiert. Für Integratoren, die komplexe URL-Strukturen manuell gepflegt hatten, bedeutete das Umgewöhnung bei gleichzeitigem Gewinn an Klarheit.
10.4 und 11.5 (2020/2021): PHP 7.2+, PHP 8.0+, neue Oberfläche
Zwei Versionen, zwei PHP-Generationswechsel. 10.4 brachte PSR-konforme Middleware und eine überarbeitete Extbase-Basis. 11.5 setzte auf PHP 8.0 und lieferte eine neue Backend-Benutzeroberfläche. Wer auf PHP-7.1-kompatiblen Extensions aufsaß, spürte das deutlich.
12.4 (2023) und 13.4 (2024/2025): ContentBlocks und neue Architektur
Der aktuelle Doppelschritt. PHP 8.1 und 8.2, ContentBlocks als offizieller Ansatz für strukturierte Inhalte, Site Sets als neues Konfigurationskonzept. In 13.4 kam nativer WebP-Support hinzu, die Backend-Architektur wurde erneut überarbeitet. Für Entwickler, die heute neu einsteigen, ist das die Normalität — für bestehende Installationen ist es der nächste Migrationspunkt.
14.3 (2026): Fluid 5 und das aufgeräumte Fundament
Mit Version 14 räumte das Projekt unter der Haube auf: Die Template-Engine Fluid ging in Version 5 an den Start, die neue System Resource API vereinheitlicht den Zugriff auf Ressourcen, und Extbase verlor die Abhängigkeit von doctrine/annotations — die technischen Details haben wir in unserer Analyse zu TYPO3 v14.0 beschrieben. Im Backend wurden die Hauptmodule umbenannt: Aus „Web" wurde „Content", aus „Files" wurde „Media". Redakteure finden sich damit schneller zurecht; Anleitungen aus älteren Versionen stimmen dafür nicht mehr wörtlich. Den LTS-Status erreichte die Reihe am 21. April 2026 mit Version 14.3 — Bugfixes bis Ende 2027, Sicherheits-Updates bis Mitte 2029, mit ELTS bis 2032. Die PHP-Basis reicht von 8.2 bis 8.5. Wir betreiben unsere eigene Plattform produktiv auf der 14er-Reihe, mit PHP 8.4 — der Umstieg von 13.4 war der bisher unspektakulärste Versionssprung dieser Chronik.
| Version | Jahr | PHP | Wichtigste Änderung |
|---|---|---|---|
| 4.5 | 2011 | 5.3 | Erste LTS, TemplaVoilà, kein Namespacing |
| 6.2 | 2014 | 5.4+ | FAL, PHP Namespaces, Extbase/Fluid |
| 7.6 | 2015 | 7.0 | Symfony-Einstieg, Bootstrap-Backend |
| 8.7 | 2017 | 7.0+ | Symfony vollständig, Doctrine DBAL |
| 9.5 | 2018 | 7.2+ | URL-Routing, Site Configuration |
| 10.4 | 2020 | 7.2+ | PSR-Middleware, Extbase-Reform |
| 11.5 | 2021 | 8.0+ | PHP 8, neues Backend |
| 12.4 | 2023 | 8.1+ | ContentBlocks (Grundlage), Site Sets |
| 13.4 | 2024/25 | 8.2+ | ContentBlocks offiziell, WebP nativ |
| 14.3 | 2026 | 8.2+ | Fluid 5, System Resource API, LTS seit April 2026 |
Warum Legacy-Migrationen so aufwändig sind
Wer heute eine TYPO3-Installation von 4.5 oder 6.2 migrieren muss, steht nicht vor einer Aktualisierung, sondern vor einer Neuentwicklung in Teilen. Das System hat sich nicht linear weiterentwickelt, sondern in Schichten: Jede LTS-Version steht auf einer anderen Basis.
Die größten Brüche lassen sich konkret benennen.
4.x auf 6.2: FAL bedeutet, dass alle Dateireferenzen neu verknüpft werden müssen. Extensions, die direkt auf uploads/-Verzeichnisse zugriffen, funktionieren ohne Umbau nicht mehr.
6.2 auf 8.7: Symfony und Doctrine DBAL. Wer eigene Datenbankklassen gebaut hat, schreibt sie neu, da der direkte DB-Zugriff in der bisherigen Form schlicht nicht mehr funktioniert.
8.7 auf 9.5: URL-Routing per Site Configuration. Bestehende TypoScript-realurl-Konfigurationen sind inkompatibel. Wer komplexe URL-Strukturen hatte, plant hier von vorn.
12.4/13.4 und folgende: ContentBlocks verändern, wie Redakteure Inhalte strukturieren. Bestehende Fluid-Lösungen laufen zunächst parallel — aber der Migrationsdruck steigt mit jeder Major-Version.
Das bedeutet konkret: Eine Migration von 4.5 auf 14.3 ist nicht eine Migration, sondern mindestens vier bis fünf konzeptionelle Übergänge. Jeder davon erfordert eine Bestandsaufnahme: Welche Extensions sind betroffen? Welche Code-Stellen greifen direkt auf DB-Tabellen zu? Welche Templates wurden noch mit TemplaVoilà gebaut?
Der häufigste Fehler bei Legacy-Migrationen ist die Annahme, eine Extension-Update-Liste abzuarbeiten reiche aus. Tatsächlich ändert sich mit jeder Major-Version auch das konzeptionelle Fundament. FAL-Migration, Symfony-Integration, URL-Routing, ContentBlocks: Das sind keine Updates, das sind Architekturentscheidungen, die einmal getroffen und dann konsequent umgesetzt werden müssen.
Planung auf Basis der offiziellen Dokumentation
TYPO3 dokumentiert Breaking Changes für jede Major-Version im offiziellen Changelog unter docs.typo3.org, inklusive Code-Beispielen und Hinweisen auf Deprecation-Warnings, die in den Vorgängerversionen bereits gesetzt wurden. Wer diese Warnings einer Version ernst nimmt, arbeitet sich nicht unvorbereitet in den nächsten Schnitt.
Die Roadmap des Projekts zeigt, wohin sich ContentBlocks und die neue Backend-Architektur weiterentwickeln. Wer das liest, plant — statt abzuwarten.
Eine realistische Einschätzung, was die Migration Ihrer Installation tatsächlich bedeutet, lässt sich nur auf Basis einer Bestandsaufnahme treffen: welche TYPO3-Version, welche Extensions, welche Custom-Entwicklungen. Gerne schauen wir uns das gemeinsam an.
