TYPO3 v12 LTS: Neue Möglichkeiten

Mit Version 12 hat TYPO3 im Oktober 2022 einen neuen Major-Zyklus gestartet, der über die Sprint-Releases v12.1 bis v12.3 inzwischen eine sehr klare Linie zeichnet. Im Oktober 2023 wird daraus das nächste Long-Term-Support-Release, und die Plattform damit für die nächsten drei Jahre festgezurrt. In diesem Beitrag fasse ich zusammen, was sich strukturell ändert, was wir bei unseren Kunden bereits jetzt vorbereiten und wo die Migration von v11 LTS aus typischerweise hakt.

PHP 8.1 als neue Untergrenze

Die wichtigste Hürde für die Migration ist die angehobene PHP-Mindestversion. v11 lief noch ab PHP 7.4, v12 setzt PHP 8.1 voraus und ist ab Tag eins für PHP 8.2 vorbereitet. Damit fällt für viele bestehende Installationen nicht nur eine TYPO3-Migration an, sondern auch ein PHP-Sprung über zwei Major-Versionen. Drittanbieter-Extensions, die wir in unseren Setups führen, müssen entsprechend auf PHP-8-Kompatibilität geprüft werden — und ein Teil von ihnen ist in der bisherigen Form nicht mehr nutzbar.

Praktisch ist das selten ein Drama, aber konsequent zu adressieren. Wir nutzen für die Prüfung Rector mit den TYPO3-spezifischen Rule-Sets in Kombination mit PHPStan. Diese Pipeline läuft seit den ersten v12-Sprint-Releases auf jeder Kundenplattform mit, sodass wir nicht zum Oktober-LTS in einen Marathon laufen, sondern den Lock-Step kontinuierlich halten.

Content Blocks: ein interessanter PoC im Extension-Ökosystem

Eine der spannenderen Entwicklungen rund um v12 sitzt nicht im Core, sondern im Extension-Ökosystem als Proof-of-Concept: Content Blocks. Das Konzept ist schlank — eine YAML-Definition, ein Twig- oder Fluid-Template, eine optionale Asset-Datei in einem zusammenhängenden Verzeichnis. Was bisher TCA-Konfiguration, Fluid-Partials, TypoScript-Mapping und ein eigener PHP-Provider war, läge damit gebündelt vor.

In meiner Bewertung ist das im April 2023 erkennbar früh: noch kein stabiles 1.0, eine überschaubare Beispielsammlung, eine API, die sich zwischen den letzten Sprint-Releases noch bewegt hat. Wir evaluieren Content Blocks parallel zu unserer bestehenden Custom-Content-Element-Pipeline auf einer internen Sandbox-Site, nicht in Kundenprojekten. Wenn das Konzept sich über die nächsten v12-Sprint-Releases stabilisiert, ist das ein klarer Kandidat für unsere Standard-Pipeline. Bis dahin bleibt es eine spannende Beobachtung.

Modernisiertes Backend

Das Backend von v12 ist auf den ersten Blick eine UI-Auffrischung mit besserer Lesbarkeit und einer überarbeiteten Sidebar. Auf den zweiten Blick steckt mehr dahinter: Eine neue Module-API erlaubt es Extensions, Backend-Module über PSR-15-Middlewares anzubinden statt über die alten ext_tables-Mechaniken. Das macht Backend-Erweiterungen testbarer und sauberer im Routing.

Für unsere Kunden bedeutet das in der Praxis: Custom-Module, die wir für interne Workflows bauen — etwa ein Redakteurs-Dashboard für freigabepflichtige Inhalte — bekommen ein moderneres Fundament. Migrationen bestehender Custom-Module sind überschaubar, aber kein Drop-in.

Composer-first in der Praxis

v12 setzt den Composer-first-Pfad konsequent fort, den TYPO3 mit v11 begonnen hat. Klassische Installationen, die noch über das TYPO3 Extension Repository ohne composer.json gelaufen sind, sind ab v12 schwer haltbar. Für uns ist das ohnehin Standard — alle Projekte laufen seit Jahren ausschließlich Composer-basiert, mit eingefrorenem composer.lock und einem expliziten Update-Pfad über Renovate.

Was sich mit v12 ändert: TYPO3 selbst lässt sich nun noch granularer aus den Einzelpaketen zusammenstellen. Wer nur Backend-Editorial braucht, kann auf Frontend-Pakete verzichten; wer eine Headless-Architektur betreibt, lässt das klassische Rendering weg. Wir nutzen diese Granularität, um die Angriffsfläche zu verkleinern und Update-Zyklen zu beschleunigen.

Migration von v11 LTS auf v12 LTS — unser Vorgehen

Die Migration von v11 LTS auf v12 LTS ist kein Patch-Update, sondern eine Major-Migration mit PHP-Sprung. Wir gehen sie in vier Schritten an:

1. PHP-Vorbereitung. Die Anwendung wird zuerst auf PHP 8.1 (noch unter TYPO3 v11) gehoben. Das entkoppelt zwei große Risikoklassen voneinander.
2. Extension-Audit. Jede Drittanbieter-Extension wird geprüft: existiert eine v12-kompatible Version, oder muss eine eigene Anpassung her? Eigene Extensions laufen durch Rector mit den TYPO3-12-Rule-Sets.
3. v12-Sprint-Upgrade. Wir spielen v12.3 (oder zum Migrationszeitpunkt v12.4) auf eine Staging-Umgebung ein. Erst wenn der Build dort grün ist und ein voller Regressionstest sauber durchläuft, kommt die Produktion dran.
4. LTS-Übergang. Mit dem Oktober-LTS wird die Staging-Umgebung auf v12 LTS gehoben und nach einer kurzen Karenzzeit in die Produktion ausgerollt.

Der Aufwand für eine durchschnittliche Mittelstand-Plattform liegt bei drei bis fünf Personentagen, je nach Extension-Tiefe. Ein Setup mit eigenen, gut gepflegten Extensions ist günstiger als ein Setup, das über die Jahre mit zwei Dutzend Drittanbieter-Erweiterungen gewachsen ist.

Was wir bis Oktober 2023 vorbereiten

In unseren Setups laufen seit v12.0 zwei Schienen parallel: die produktive v11-LTS-Plattform für den Kunden, und eine v12-Sprint-Plattform im Staging-Modus, die wir bei jedem Sprint-Release nachziehen. Damit haben wir bis zum Oktober-LTS jede einzelne Inkompatibilität bereits einmal angefasst — und müssen am LTS-Tag nicht hoffen, dass alles passt.

Wir empfehlen Kunden, die heute noch auf v11 LTS sitzen, in der zweiten Jahreshälfte 2023 eine Migrationsplanung zu starten. v11 LTS ist bis Oktober 2024 mit Standard-Support versorgt und danach gegen Aufpreis erweitert, aber jede zusätzliche v11-Saison verschiebt das Problem nur. Wer einmal mit v12 angekommen ist, profitiert direkt von der modernisierten Backend-Module-API und der granulareren Composer-Struktur — und ist nahe an Experimenten wie Content Blocks, sobald die sich stabilisieren.

Fazit

v12 LTS ist kein revolutionärer Bruch zur v11, sondern eine konsequente Modernisierung. Wer den Composer-first-Pfad und PHP 8.1+ bereits lebt, hat den schwierigsten Teil schon hinter sich. Wer ihn noch vor sich hat, sollte ihn in diesem Jahr angehen — nicht weil v11 LTS akut bricht, sondern weil sich das ganze Ökosystem rundherum auf v12 sortiert.