TYPO3 14 LTS: modernes Backend, AI-API, Fluid 5 und Maintenance
TYPO3 14 LTS ist seit 21. April 2026 verfügbar. Die erste Long-Term-Support-Version bringt einen klaren Wartungspfad bis 2029.
TYPO3 14 LTS ist seit 21. April 2026 als Version 14.3.0 verfügbar. Es ist die erste Long-Term-Support-Version der v14-Linie. Release-Verantwortung liegt bei Benni Mack als Project Lead. Der Wartungspfad steht: Bug-Fixes via Community bis 31. Dezember 2027, Security-Patches via ELTS bis 30. Juni 2029. Damit ist der Planungshorizont für Bestandsprojekte gesetzt.
Drei Sprints, dann das Fundament
Das v14-Release ist nicht in einem Wurf entstanden. Die Linie lief planmäßig über drei Sprint-Releases, jeder mit einer eigenen Aufgabe: Breaking Changes klären, Features integrieren, das Set einfrieren. Mit 14.3 wird das Tragwerk fixiert und in den Long-Term-Support überführt.
Wer parallel TYPO3 12 betreibt: Community-Support endet am 30. April 2026. Für 13 läuft die Maintenance noch bis 31. Oktober 2027. Für die meisten Bestandsumgebungen heißt das: irgendwann zwischen jetzt und Ende 2027 wird migriert.
Backend: Camino, neue Module, klarere Namen
Mit v14 kommt erstmals ein Default-Theme im Core-Lieferumfang: Camino. Es ist nicht als finales Live-Theme gedacht, sondern als Startgerüst mit mehreren Farbschemata — und gibt Integratorinnen und Integratoren eine Referenz, wie ein zeitgemäßes Frontend aufgebaut sein kann. Wer ein eigenes Sitepackage entwickelt, kann Camino als Vorlage zerlegen oder ignorieren.
Das Backend selbst wurde aufgeräumt. Module heißen jetzt nach dem, was sie tun: aus Filelist wird Media, aus Page wird Layout. Der Befund ist alt — wer die Begriffe nicht kennt, findet die Funktion nicht. v14 trägt zwei der älteren Hürden ab.
Ein neues Context Panel öffnet sich beim Bearbeiten als Slide-In von rechts, ohne dass die Seite neu geladen wird. Dazu kommt ein Page Creation Wizard mit geführten Schritten, ein Scheduler Task Wizard mit modernem UI und ein Bookmark Manager mit Gruppierung und globalen Bookmarks. Marketing-Workflows landen mit zwei dedizierten Modulen direkt im Backend: ein QR-Code-Generator mit Hit-Counter und Ablaufoptionen, plus ein Short-URL-Modul mit Tracking. Beides war bislang Drittextension-Gebiet.
Das Form Framework hat deutlichen Zuwachs bekommen. Multiple File Uploads sind möglich, CKEditor 5 wird als Editor unterstützt, und die Konfigurationen lassen sich datenbankgetrieben statt nur per YAML-Datei pflegen — wichtig für Site-Sets mit mehreren Mandanten oder dynamischer Form-Verwaltung.
Für Redaktionen ergänzen mehrere kleine, aber sichtbare UX-Bausteine das Bild: Dashboard-Widgets zeigen letzte Logins und zuletzt geöffnete Dokumente, ein Content Type Usage Report macht transparent, wo welche Content-Elemente verwendet werden, und das Page Module unterstützt direkten Sprachvergleich nebeneinander. Content Blocks bleiben als Core-nahe Extension der Standardweg, wenn Editor-Teams eigene Content-Element-Definitionen mit grafischem Konfigurations-Frontend brauchen. Auch die Workspace-Vorschau wurde überarbeitet — Inhalte mit komplexem Workspace-Status rendern konsistenter, der Form-Editor selbst hat zusätzliche visuelle Indikatoren bekommen.
Unter der Motorhaube
Im Maschinenraum hat das Release Substanz nachgelegt:
- Fluid Standalone auf 5.3 mit neuen ViewHelpern, CDATA-Support und CLI-Befehl fluid:analyze
- Doctrine/DBAL auf 4.4
- TypeScript-Setup im Backend auf v6
- Symfony-Pakete auf den aktuellen Patch-Releases
- Symfony Translation Component mit XLIFF 1.2- und 2.x-Support
Architekturseitig kommt eine neue System Resource API. Sie ersetzt die bisher unterschiedlichen Wege, Files und Assets in PHP, TypoScript und Fluid aufzulösen. Wer eigene Resolver gebaut hat: Hier liegt der Refactoring-Anker für die Migration.
Für Extension-Entwicklung: Symfony-Vereinheitlichung
v14 zieht die Extension-Schicht weiter in Richtung Symfony-Konsistenz. In Extbase lassen sich jetzt Symfony Validators direkt nutzen — die TYPO3-eigene Validation-Schicht muss nicht mehr parallel gepflegt werden. Hinzu kommen zwei neue PHP-Attribute: #[Authorize] deklariert Berechtigungen direkt am Controller oder an der Action, #[RateLimit] bringt Rate-Limiting ohne externe Middleware.
Mehrere Utility-Methoden ohne expliziten Request-Parameter sind als deprecated markiert: GeneralUtility::getIndpEnv(), GeneralUtility::sanitizeLocalUrl(), GeneralUtility::isOnCurrentHost(). Auch ext_tables.php in Extensions ist auf der Deprecation-Liste und wird in einer kommenden Major-Version verschwinden. Wer Extensions pflegt, hat einen klaren Cleanup-Pfad — der Migrationsweg ist über statische Analysen gut dokumentiert.
KI im Editorial-Workflow — als API, nicht als Feature
Die GenAI Toolbox liefert einen API-Layer, an dem externe AI-Services wie ChatGPT oder Claude Editorinnen und Editoren bei der Inhaltserstellung unterstützen können. Text-Generierung, Optimierung, Zusammenfassung — direkt im Backend, bei vorhandenen Inhalten. Die Position des Cores ist dabei klar: Infrastruktur statt festverdrahteter Vendor-Bindung. Das ist die richtige Statik. Wer das Modell wechselt, bricht damit nicht das Editorial-Setup. Konkrete Anbindungen liefern Extensions oder eigene Implementierungen — der Core hält die Schnittstelle. Damit bleibt die Architektur für eine Branche kompatibel, in der die Modell-Landschaft im Quartalstakt wechselt. Anbindungen an OpenAI, Anthropic oder lokal gehostete Modelle laufen damit über austauschbare Adapter, nicht über Core-Patches.
System-Anforderungen
Mindest-PHP-Version ist 8.2. Unterstützt sind 8.2, 8.3, 8.4 und 8.5. Bei MariaDB und MySQL bleibt der Stand der v12/v13-Linie. Im Backend laufen Sessions optional über Redis mit Authentication — relevant für Setups mit höheren Concurrency-Anforderungen. Das Install Tool erlaubt zusätzlich CLI-basiertes Generieren von Password-Hashes. Sicherheitsseitig hat das Release leise nachgezogen: Die JWT-Key-Derivation läuft jetzt über HKDF, und 405-HTTP-Responses tragen einen Allow-Header — kleine Korrekturen an der Spec-Compliance, die in Audits regelmäßig auffallen. Wer noch auf PHP 8.1 sitzt, hat den Migrationspfad nicht erst seit gestern auf der Agenda.
Was wegfällt
v14 räumt auch im Core auf. Die HTTP-Response-Compression ist entfernt. Frontend-Asset-Konkatenation und -Compression auch — moderne Build-Tools übernehmen diese Aufgaben heute außerhalb des CMS. Extbase-Annotations werden nicht mehr unterstützt; PHP-Attribute sind seit Jahren der Standardweg.
Was das für Bestandsprojekte heißt
Wer von v13 migriert, hat den kürzeren Sprung — eine Major-Version. Wer von v12 kommt, hat zwei Major-Versionen aufzuarbeiten und sollte den Migrationsfahrplan nicht in einen Sprint pressen. Beim eigentlichen Update unterstützen verbesserte Upgrade-Wizards: Schema-Migrationen sind robuster, Datenbank-Integritätschecks decken mehr Fälle ab, und ein neuer Index auf content_from_pid beschleunigt Seiten mit referenzierten Inhalten. Im User-Settings-Modul wurde die Passwort-Speicherung weiter gehärtet — relevant für alle Setups, in denen Editor-Konten lokale Credentials halten. Der Vorteil bei v14 LTS: ein dokumentierter Wartungshorizont mit dreieinhalb Jahren Community-Support und sieben Jahren via ELTS. Das ist Planungssicherheit für die nächsten zwei Hauptversionen.