TYPO3 13.4.27: Was ein Maintenance Release wirklich verlangt
Maintenance Releases gelten als das langweilige Ende der TYPO3-Updates: keine Features, kein Datenbank-Update, in einer halben Stunde eingespielt. TYPO3 13.4.27 zeigt, warum das trügerisch ist — es enthält einen stillen Breaking Change, der eingebettete Inhalte im Frontend betreffen kann, ohne dass sich am Inhalt etwas ändert. Dieser Artikel beschreibt die relevanten Änderungen, den einen Punkt, den Sie danach testen müssen, und wie Sie mit Patch-Releases grundsätzlich umgehen. Für Entwickler und Betreiber von TYPO3 13 LTS.
- Maintenance Release
-
Ein Maintenance Release ist ein Patch-Update innerhalb einer LTS-Version, das ausschließlich Fehlerbehebungen, Kompatibilitätsanpassungen und kleinere Verbesserungen enthält. Ziel ist, bestehende Installationen stabil und sicher zu halten, ohne neue Funktionen oder Breaking Changes einzuführen.
-
Abgrenzung
Ein Security Release schließt gezielt bekannt gewordene Sicherheitslücken und sollte sofort eingespielt werden. Ein Maintenance Release kann sicherheitsrelevante Verbesserungen enthalten, ist aber keine Reaktion auf eine akute Bedrohung — was nicht heißt, dass man es liegen lassen sollte.
Die eine Änderung, die Sie testen müssen
Mit 13.4.27 wandert CKEditor 5 auf Version 47.6. Dabei ändert sich ein Standardverhalten: Der Editor erzwingt jetzt Sandbox-Beschränkungen für iframes.
Das betrifft alle Installationen, in denen Redakteure eingebettete Inhalte im Rich-Text-Editor verwenden — Kartenausschnitte, Videos, externe Formulare. Ihre Inhalte ändern sich dabei nicht. Was sich ändert, ist das Verhalten im Frontend: Eingebettete Elemente können nach dem Update eingeschränkt oder gar nicht mehr funktionieren.
Genau das macht die Änderung tückisch. Sie erzeugt keinen Fehler, keine Warnung und keinen Eintrag im Log — die Seite sieht auf den ersten Blick normal aus, nur das Eingebettete lädt nicht mehr.
Was sonst behoben wurde
Rund 40 Commits adressieren Probleme, die im Betrieb aufgefallen sind. Die für den redaktionellen Alltag relevanten:
- Form Editor: Ein Absturz beim parallelen Bearbeiten in mehreren Browser-Tabs ist behoben — dieser Fehler konnte zu Datenverlust führen.
- Recycler: Die Filterauswahl beim endgültigen Löschen arbeitet wieder korrekt, ebenso die Blätterfunktion bei mehreren Datensatztypen.
- Seitenbaum: Vorauswahl-Probleme in der Seitenauswahl sind behoben.
Dazu zwei sicherheitsrelevante Korrekturen, obwohl es kein Security Release ist: Standard-Fehlerseiten erhalten jetzt Content-Security-Policy-Header — zuvor waren Fehlerantworten davon ausgenommen, was bei individuellen Fehlerseiten eine Lücke sein konnte. Außerdem wurden bekannte Schwachstellen in npm-Entwicklungsabhängigkeiten geschlossen.
Weitere Korrekturen betreffen den FilesProcessor (TypeError bei nicht-rekursiver Verarbeitung), doppelte Cache-Control-Header, das Zusammenführen von Upload-Argumenten in Extbase, fehlerhafte Dateireferenzen und veraltete Icons durch zu aggressives Browser-Caching.
PHP 8.5 — vorbereitet, nicht unterstützt
Das Release behebt null-Array-Offset-Meldungen, die unter PHP 8.5 in der Settings API auftreten. Das ist eine Vorbereitung, keine Freigabe: TYPO3 13 unterstützt PHP 8.5 offiziell nicht. Wer PHP 8.5 in einer Testumgebung fährt, hat mit 13.4.27 eine sauberere Basis als mit älteren Patches — für Produktivsysteme bleibt es bei den offiziell unterstützten Versionen.
Wer ohnehin über den Sprung auf die nächste Hauptversion nachdenkt, findet die Vorgehensweise im Upgrade-Guide für TYPO3 14.
Ablauf für dieses Update
- Release Notes lesen und prüfen, ob inzwischen eine neuere Patch-Version vorliegt
- `composer update` zunächst auf der Staging-Umgebung ausführen
- Seiten mit eingebetteten Inhalten im Frontend gezielt aufrufen und testen
- Bei nicht ladenden Einbettungen die RTE-Konfiguration um die nötigen Sandbox-Rechte ergänzen
- Recycler und Form Editor stichprobenartig prüfen
- Auf Production ausrollen
- Caches leeren (`typo3 cache:flush`) — ein Datenbank-Update ist nicht erforderlich
Häufig gestellte Fragen
Nein, es ist ein reines Maintenance Release ohne dedizierte Sicherheitspatches. Enthalten sind aber zwei sicherheitsrelevante Verbesserungen: CSP-Header für Standard-Fehlerseiten und das Schließen bekannter npm-Schwachstellen in den Entwicklungsabhängigkeiten. Ein Grund zur Eile ist das nicht, ein Grund zum Aufschieben aber auch nicht.
Nein. Das Release enthält keine Schema-Änderungen. composer update und ein Cache-Flush genügen.
CKEditor 5 geht auf Version 47.6 und erzwingt Sandbox-Beschränkungen für iframes. Wenn Ihre Redaktion eingebettete Inhalte im Rich-Text-Editor nutzt, testen Sie diese Seiten nach dem Update im Frontend. Fehlende Funktion lässt sich über gezielte Sandbox-Ausnahmen in der RTE-Konfiguration beheben.
Nein. Das Release beseitigt erste Unverträglichkeiten, offiziell unterstützt wird PHP 8.5 in TYPO3 13 nicht. Für Testumgebungen ist 13.4.27 die bessere Ausgangsbasis, für Produktivsysteme bleiben die freigegebenen PHP-Versionen maßgeblich.
Ein fester Rhythmus schlägt Einzelfallentscheidungen — monatlich ist für die meisten Projekte ein guter Takt, Security Releases dazwischen sofort. Entscheidend ist weniger die Frequenz als die Verbindlichkeit: Updates, die niemandem zugeordnet sind, stauen sich, und aus einem halbstündigen Patch wird nach einem Jahr ein Projekt.
Wann sich Unterstützung lohnt
Regelmäßige Updates sind Routine, aber Routine braucht jemanden, der sie hält. Extern sinnvoll wird das, wenn:
- keine Staging-Umgebung existiert und Updates direkt auf Production laufen
- niemand die Release Notes liest und bewertet, was davon Sie betrifft
- unklar ist, ob eine Konfigurationsänderung wie die CKEditor-Sandbox Ihre Inhalte trifft
- Updates sich über Monate stauen, weil andere Projekte Vorrang haben
- kein definierter Rückweg existiert, falls ein Update Probleme macht
Für Major-Updates gilt derselbe Gedanke in größerem Maßstab — dafür gibt es die Upgrade-Checkliste.
