Zum Inhalt springen

TYPO3 14 LTS: Was die Version bringt und was das Update verlangt

TYPO3 14 LTS ist seit dem 21. April 2026 als Version 14.3.0 verfügbar. Drei Sprint-Releases zwischen November 2025 und März 2026 haben das Tragwerk vorbereitet, mit 14.3 wurde es festgeschrieben. Was das für Bestandsprojekte bedeutet, hängt weniger an den neuen Funktionen als an zwei Daten im Kalender.

TL;DR

TYPO3 14 LTS steht, der kostenlose Support für Version 12 ist beendet. Wer jetzt plant, plant mit klaren Fristen statt unter Druck.

Für wen oder was? Für Betreiber bestehender TYPO3-Installationen und für alle, die ein Neuprojekt aufsetzen.

Support: Kostenlose Bugfixes bis Ende 2027, kostenlose Sicherheitsupdates bis 30. Juni 2029, kostenpflichtiger Extended Support bis 30. Juni 2032.

Handlungsdruck: Nur für Version 12. Deren kostenloser Support endete am 30. April 2026. Version 13 hat bis Ende 2027 Zeit.

Systemanforderungen: PHP 8.2 bis 8.5. Nicht 8.4 — die Angabe zirkuliert falsch.

Für Entwickler: Symfony Validators in Extbase, neue Attribute für Zugriff und Rate-Limiting, Extbase-Annotations entfallen.

Was Arbeit macht: Nicht der Core. Die Extensions, die Templates und die Eigenentwicklungen.

 

Die Fristen

Für Version 14 gilt: kostenlose Wartungs-Bugfixes bis Ende Dezember 2027, kostenlose Sicherheitsupdates bis zum 30. Juni 2029. Danach greift Extended Long Term Support, kostenpflichtig, bis zum 30. Juni 2032. TYPO3 selbst rechnet das als sieben Jahre Support pro Version: drei Jahre kostenlos, vier Jahre kostenpflichtig.

Version 13 bleibt bis Ende 2027 kostenlos versorgt, mit Extended Support bis Ende 2030. TYPO3 kennzeichnet Version 14 als Empfehlung für neue Projekte und Version 13 als Version für bestehende Projekte. Wer auf 13 sitzt, hat also keinen Grund zur Eile — aber ein Ablaufdatum.

Version 12 hat den kostenlosen Support am 30. April 2026 verloren. Extended Support läuft bis zum 30. April 2030. Wer dort steht, hat zwei Optionen: migrieren oder zahlen. Aussitzen ist keine dritte.

Das Backend

Der sichtbarste Teil des Releases. Die Oberfläche wurde grundlegend überarbeitet, und die Änderungen betreffen den Redaktionsalltag, nicht die Optik.

Ein neues Context Panel hält die Bearbeitung von Inhalten am Inhalt, statt Redakteure durch getrennte Masken zu schicken. Ein geführter Assistent für die Seitenanlage hält alle relevanten Felder sichtbar, bis der Vorgang abgeschlossen ist. Für Scheduler-Tasks gibt es dasselbe Prinzip: kategorisierte Auswahl mit Suche statt Dropdown-Raten. Bookmarks — vormals Shortcuts, jetzt auch im Code so benannt — haben eine zentrale Verwaltung bekommen. Eigene Gruppen, Umsortieren per Drag-and-drop, Umbenennen direkt in der Liste, Mehrfachauswahl zum Verschieben und Löschen. Administratoren können globale Bookmarks für alle Backend-Benutzer hinterlegen. In großen Installationen mit tiefen Seitenbäumen ist das kein Komfortthema, sondern gesparte Klickwege bei jeder Routineaufgabe.

Neu ist außerdem Camino: ein einsatzfertiges Frontend-Theme im Lieferumfang des Core, in vier Farbvarianten. Für kleine Sites ein Startpunkt, für Enterprise-Projekte eine Referenzimplementierung.

QR-Codes und Kurz-URLs

Version 14 bringt zwei neue Backend-Module, beide unter „Link Management" neben den Redirects. QR-Codes kamen mit 14.1, Kurz-URLs mit 14.2.

Der praktische Wert liegt in der Trennung von Code und Ziel. Jeder QR-Code trägt eine permanente URL, deren Ziel sich jederzeit ändern lässt. Ein gedruckter Code auf Flyer, Plakat oder Messewand bleibt gültig, auch wenn die Landingpage umzieht. Downloads gibt es als PNG oder SVG in wählbarer Größe.

Technisch bauen beide Module auf dem Redirect-System auf. Daraus folgt ein Nebeneffekt, der oft übersehen wird: Hit-Counter, erzwungenes SSL und Ablaufdaten stehen automatisch zur Verfügung. Wer die Redirect-Statistik aktiviert hat, bekommt die Auswertung von Scans ohne weitere Konfiguration. Kurz-URLs liegen als eigener Datensatztyp in derselben Tabelle; der Pfad lässt sich manuell setzen oder als achtstelliger Zufallspfad erzeugen, mit serverseitiger Kollisionsprüfung.

Eine Voraussetzung, die man kennen sollte: Ohne aktivierte Systemextension für Redirects kein QR-Modul.

Dazu kommt ein QR-Button neben der Vorschau-Schaltfläche in vielen Modulen. In Workspaces enthält der Code eine Preview-URL, die ohne Backend-Anmeldung funktioniert — praktisch, um einen Entwurf am Telefon zu prüfen oder einem Kunden zu zeigen.

Details zum QR-Modul haben wir bereits bei Erscheinen des Sprint-Releases beschrieben.

Mehrsprachigkeit

Der überarbeitete Übersetzungs-Workflow führt schrittweise durch den Vorgang, statt Inhaltselemente einzeln kopieren und übersetzen zu lassen. Redakteure wählen aus, was übersetzt wird, und der Assistent weist auf Elemente hin, die sonst durchrutschen.

Wer mehrsprachige Sites pflegt, kennt das eigentliche Problem: nicht die Übersetzung selbst, sondern die vergessene.

Das Form Framework

Der Abschnitt des Releases mit dem größten Alltagsnutzen für Redaktionen.

Dateiuploads lassen sich jetzt als Mehrfach-Upload in einem einzigen Feld konfigurieren — statt eine feste Anzahl Upload-Elemente vorzuhalten. Für Bewerbungsformulare und Veranstaltungsanmeldungen ist das der Unterschied zwischen brauchbar und behelfsmäßig.

Textbereiche unterstützen CKEditor 5. Redakteure formatieren in Formularen mit demselben Werkzeug wie im übrigen Backend. Benachrichtigungs-Mails lassen sich direkt im Backend anpassen, ohne HTML oder Fluid.

Strukturell wichtiger: Die dateibasierte Speicherung von Formulardefinitionen ist als veraltet markiert. Der Weg führt zu einem datenbankgestützten Speicheradapter. Wer Formulare heute per YAML im Sitepackage pflegt, sollte das auf dem Zettel haben — nicht als Notfall, aber als Richtungsentscheidung.

Unter der Haube

Die Template-Engine Fluid liegt in Version 5 vor. Das ist der Punkt, an dem ein Upgrade Arbeit verursacht — Templates müssen geprüft werden, nicht nur der Core.

Die Systemanforderungen sind moderater als vielfach behauptet: PHP 8.2, 8.3, 8.4 oder 8.5. Als Datenbank MariaDB ab 10.4.3, MySQL ab 8.0.17, PostgreSQL ab 10.0 oder SQLite ab 3.8.3. Mehrere deutschsprachige Quellen nennen PHP 8.4 als Mindestversion. Das ist falsch. Bemerkenswerter noch: Es sind exakt dieselben Anforderungen wie für Version 13. Wer von dort kommt, muss an der Infrastruktur nichts anfassen.

Für Entwickler und Integratoren

Die Extension-Schicht rückt weiter in Richtung Symfony-Konsistenz.

In Extbase lassen sich jetzt Symfony Validators direkt nutzen. Die TYPO3-eigene Validierungsschicht muss nicht mehr parallel gepflegt werden. Im Gegenzug ist die Unterstützung für Extbase-Annotations entfallen — ein Breaking Change, der Bestandscode betrifft. Wer noch mit Annotations statt PHP-Attributen arbeitet, hat hier Arbeit.

Zwei neue Attribute kommen hinzu. #[Authorize] deklariert Zugriffsanforderungen direkt an der Controller-Action: angemeldeter Frontend-Benutzer, Gruppenzugehörigkeit, eigene Logik. Extbase prüft vor dem Aufruf. #[RateLimit] begrenzt, wie häufig eine Action innerhalb eines Zeitfensters aufgerufen werden darf — auf Basis der Client-IP, über Symfonys RateLimiter-Komponente und das TYPO3-Caching-Framework. Ab 14.2 laufen alle Rate-Limiter über eine zentrale Factory, deren Einstellungen sich per Konfiguration überschreiben lassen, ohne Code anzufassen.

Datenbankabfragen sind ausdrucksstärker geworden: Extbase unterstützt SQL-Funktionsausdrücke in ORDER-BY-Klauseln über eine Fluent-API mit orderBy(), addOrderBy(), concat(), trim() und coalesce().

Auf der Deprecation-Liste stehen mehrere Utility-Methoden, die ohne expliziten Request arbeiten: GeneralUtility::getIndpEnv(), sanitizeLocalUrl(), isOnCurrentHost() und locationHeaderUrl(). Das Muster ist erkennbar — der Core zieht implizite Umgebungszugriffe konsequent auf PSR-7-Requests um. Wer Eigenentwicklungen pflegt, hat damit einen klaren Cleanup-Pfad, der sich über statische Analyse abarbeiten lässt.

Zwei weitere Punkte, die beim Upgrade auffallen: Die TYPO3-eigene HTTP-Response-Kompression für Frontend und Backend ist entfallen. Und das Datenbank-Speicherformat für Scheduler-Tasks hat sich geändert — bestehende Tasks sollten nach dem Upgrade geprüft werden.

Was das Update verlangt

Der Core ist das kleinste Problem. Die Arbeit liegt in dem, was darauf aufsetzt.

Der Extension-Bestand. Jede installierte Extension braucht eine kompatible Version oder einen Ersatz. Das ist der erste Schritt, nicht der letzte — ein einziges nicht migriertes Paket blockiert das gesamte Upgrade. Extensions, die noch Extbase-Annotations statt PHP-Attribute nutzen, brechen mit Version 14, weil die Unterstützung entfallen ist.

Die Eigenentwicklungen. Wer getIndpEnv() oder verwandte Methoden im eigenen Code hat, arbeitet mit Konstruktionen, die der Core abbaut. Das läuft noch, aber es läuft auf ein Verfallsdatum zu. Der Vorteil: Diese Fälle lassen sich per statischer Analyse finden, nicht per Durchklicken.

Die Templates. Fluid 5 ist der Punkt, an dem sich Aufwand entscheidet. Bei einem Standard-Sitepackage ist es Routine. Bei über Jahre gewachsenen Templates mit eigenen ViewHelpern wird es zur eigentlichen Aufgabe.

Der Weg. Von Version 13 aus ist es ein Schritt. Von Version 12 aus wird eine Version übersprungen — technisch vorgesehen, aber mit mehr Prüfaufwand, weil die Breaking Changes zweier Zyklen gleichzeitig eintreten. Aus Version 11 oder älter liegen drei Major-Versionen zwischen Ist und Ziel. Ob sich das als Upgrade-Kette rechnet oder ob ein Neubau der kürzere Weg ist, entscheidet nicht das Alter des Systems, sondern der Zustand von Extensions und Templates. Das klärt eine Bestandsaufnahme, keine Faustregel.

Quellen

TYPO3-Insights
Back