TYPO3 v14: Was ist wirklich neu

Die Template-Engine Fluid hat ein Major-Upgrade auf Version 5 bekommen. Für Integratoren und Entwickler ist das die Änderung, die am meisten Aufmerksamkeit verdient – auch weil sie Breaking Changes mit sich bringt.

Die strikte Typisierung ist jetzt Standard. ViewHelper validieren ihre Argumente deutlich strenger. Code, der bisher funktionierte (aber eigentlich gegen die API-Spezifikation verstieß), wird jetzt zurückgewiesen. Das klingt schmerzhaft, ist aber langfristig ein Gewinn: ViewHelper-Implementierungen können sich endlich auf die deklarierten Typen verlassen, was defensive Programmierung überflüssig macht.

Ein konkretes Beispiel: Wenn ein ViewHelper einen String erwartet und man bisher versehentlich ein Array übergeben hat, wurde das oft stillschweigend geschluckt. Ab Fluid 5 gibt es einen klaren Fehler. Die gute Nachricht: Einfache Typ-Konvertierungen (Integer zu String) funktionieren weiterhin automatisch.

CDATA-Sections werden nicht mehr entfernt. Das war nie dokumentiert, aber viele Teams haben <![CDATA[ ]]> als Workaround genutzt, um Template-Code auszukommentieren. Das funktioniert nicht mehr. Fluid bietet jetzt eine alternative Syntax für diesen Anwendungsfall.

Variablennamen mit Unterstrich-Präfix sind nicht mehr erlaubt. Wer Variablen wie _internal oder _temp verwendet hat, muss diese umbenennen.

Fluid 5 bringt auch neue ViewHelper mit, die den Alltag erleichtern. <f:page.title>, <f:page.meta>, <f:page.headerData> und <f:page.footerData> ermöglichen eine präzisere Steuerung von Seiteninformationen direkt aus dem Template heraus. Außerdem wurde die Fallback-Logik für Template-Dateinamen vereinfacht: Dateinamen müssen nicht mehr zwingend mit Großbuchstaben beginnen.

Bisher gab es verschiedene Wege, um auf Dateien in TYPO3 zuzugreifen – je nachdem, ob es sich um Extension-Ressourcen, FAL-Assets oder Projektdateien handelte. Die neue System Resource API standardisiert das.

Statt des gewohnten EXT:-Präfix können jetzt auch PKG: für Paket-Ressourcen, FAL: für Assets und APP: für Projektdateien verwendet werden – konsistent in PHP, TypoScript und Fluid. Das Legacy-Keyword EXT bleibt vorerst funktionsfähig, aber die neue Systematik ist klarer strukturiert.

Für Extension-Entwickler bedeutet das: Der Code wird portabler und leichter zu verstehen, weil sofort erkennbar ist, woher eine Ressource kommt.

Die Arbeit mit mehrsprachigen Inhalten wurde überarbeitet. Der neue „Guided Translation Workflow" führt Schritt für Schritt durch den Übersetzungsprozess. Das ist besonders für Teams relevant, die nicht täglich mit Übersetzungen arbeiten und bei denen der Prozess immer wieder neu erlernt werden musste.

Technisch interessant: TYPO3 unterstützt jetzt sowohl XLIFF 1.2 als auch XLIFF 2.0. Bei XLIFF 2.0 werden Übersetzungen erst ab Status „reviewed" oder „final" an Übersetzungsdienste übertragen. Wer mit externen Dienstleistern arbeitet, bekommt damit mehr Kontrolle über den Workflow.

Die Lokalisierungsarchitektur wurde auf die Symfony Translation Component migriert. Das eröffnet die Möglichkeit, Custom Translation Loaders nach Symfony-Standard zu implementieren.

Einige Änderungen sind weniger sichtbar, aber für die langfristige Wartbarkeit wichtig.

TYPO3 v14 erfordert mindestens PHP 8.2 und unterstützt PHP 8.3, 8.4 und sogar das neue 8.5. Da TYPO3 v12, v13 und v14 ähnliche Systemanforderungen haben, kann die PHP-Version auf dem Server bereits vor dem TYPO3-Upgrade aktualisiert werden.

Extbase nutzt keine doctrine/annotations mehr – deren Upstream-Wartung wurde eingestellt. Stattdessen sind PHP Attributes jetzt der Standard. TYPO3 unterstützt Attributes für alle Extbase-Annotations seit Version 12, der Migrationspfad ist also klar.

Extbase Models und Controller unterstützen jetzt auch Symfony Validators. Zusammen mit den bestehenden Extbase-Validators und PHP Attributes wird die Input-Validierung deutlich einfacher.

Das Install-Tool-Passwort kann jetzt per CLI-Befehl gesetzt werden. Für automatisierte Deployments und sichere Initial-Setups ist das ein echter Zugewinn. Außerdem gibt es einen neuen CLI-Befehl zum Löschen von Cache-Einträgen basierend auf Cache-Tags.

TYPO3 Core führt keine HTTP-Response-Kompression mehr durch. Die bisherigen Konfigurationsoptionen wurden entfernt. Moderne Server bieten effizientere Kompressionsalgorithmen und verhandeln direkt mit den Clients – das verhindert doppelte Arbeit und mögliche Konflikte.

TYPO3 v14 folgt einem klaren Sprint-Zyklus:

• 14.0 (November 2025): Erstes Sprint-Release mit den Grundlagen
• 14.1 (Januar 2026): Weiterführung der Backend-Modernisierung, neue API-Endpoints, Default-Theme
• 14.2: Weiteres Sprint-Release
• 14.3 LTS (April 2026): Long-Term-Support-Version

Die Sprint-Releases werden bis zum nächsten Minor-Release mit Bugfixes und Security-Updates versorgt. Das LTS-Release erhält Bugfixes bis Ende 2027 und Security-Patches bis Mitte 2029.

Zum Release-Zeitpunkt waren bereits die ersten Extensions im TER als v14-kompatibel markiert, darunter etablierte Pakete. Die Zahl wächst stetig. Wer v14 produktiv einsetzen möchte, sollte die Extension-Kompatibilität der eigenen Setup-Komponenten prüfen.

Unser Vorgehen: Wir testen Extensions in einer Staging-Umgebung, bevor wir Kundenprojekte migrieren. Bei kritischen Extensions, die noch nicht kompatibel sind, warten wir oder passen sie selbst an.

TYPO3 v14 ist kein Update, das man machen muss, weil der Support ausläuft. Es ist ein Update, das sich lohnt. Die Backend-Modernisierung macht das System zugänglicher, ohne erfahrene Nutzer zu verprellen. Die technischen Änderungen – Fluid 5, System Resource API, Extbase-Modernisierung – schaffen eine sauberere Codebasis für die nächsten Jahre.

Für unsere Projekte bedeutet das: Schnelleres Onboarding neuer Redakteure, weniger Workarounds im Template-Code, und eine Plattform, die auch in fünf Jahren noch aktuell sein wird.

Die Migration erfordert Vorbereitung – insbesondere bei Fluid-Templates sollte das Deprecation-Log vorab geprüft werden. Aber der Aufwand ist überschaubar und zahlt sich aus.