TYPO3-Extensions: Pflegen, kürzen, ersetzen — wann sich das lohnt

Was sich in TYPO3 13 architektonisch ändert

Ein Major-Release ist kein Routine-Update. Wer das bei TYPO3 13 so behandelt, trifft das Deprecation-Log oder eine inkompatible Extension als erste Überraschung. Die Änderungen sind real, gut dokumentiert und planbar. Nur unterschätzt werden sollten sie nicht.

Bereits auf Serverebene setzt TYPO3 13 eine Stufe höher: PHP 8.2 ist Pflicht, während TYPO3 12 noch mit PHP 8.1 auskommt. Das klingt marginal, hat allerdings praktische Konsequenzen. Viele Managed-Hosting-Pakete und ältere Serverkonfigurationen stellen PHP 8.2 nicht als Standardversion bereit, sodass der erste Schritt vor jeder Migration die Prüfung der Serverumgebung ist.

ContentBlocks und Site Sets: zwei Konzepte kommen an

ContentBlocks sind in TYPO3 13 kein Experiment mehr, sondern der empfohlene Weg für eigene Content-Elemente. Bisher war das eine Mischung aus TCA-Konfiguration, TypoScript und FlexForms, verteilt über mehrere Dateien und schwer wartbar. ContentBlocks fassen alles in einer geordneten Verzeichnisstruktur zusammen: lesbarer, testbarer, versionierbar. Bestehende Content-Elemente funktionieren weiterhin; der Umstieg ist nicht erzwungen, für neue Projekte aber die richtige Wahl.

Site Sets erfüllen eine ähnliche Funktion auf der Konfigurationsebene. Statt Konfigurationen über statische TypoScript-Templates zu verteilen, lassen sich wiederverwendbare Pakete als Site Sets definieren und gezielt einbinden. Bei Multi-Site-Installationen mit mehreren Domains unter einem TYPO3 reduziert das die Konfigurationskomplexität erheblich. Vorausgesetzt, man ist bereit, bestehende Strukturen umzubauen.

Backend-JavaScript und Extbase

TYPO3 tauscht seinen JavaScript-Stack systematisch gegen Web Components und Lit aus. Das sieht der Redakteur nicht; relevant ist es für alle, die eigene Backend-Module entwickelt haben oder Custom-JavaScript im TYPO3-Backend einsetzen. RequireJS-basierte Lösungen aus früheren Versionen haben in Version 13 keinen Platz mehr.

Extbase bleibt erhalten. Die Anzahl echter Breaking Changes ist überschaubar, aber Extension-Autoren sollten die Changelogs Punkt für Punkt prüfen, da kleinere API-Anpassungen bestehenden Code brechen können, ohne dass eine Deprecation-Warnung vorausgegangen ist.

Der häufigste Migrationskiller: entfernte Deprecations

Was bei einer TYPO3-Migration die meiste ungeplante Arbeit verursacht, ist nicht das Neue, sondern das Entfernte. Funktionen und APIs, die in TYPO3 12 als deprecated markiert wurden, sind in Version 13 vollständig entfernt. Das ist Absicht: Deprecations sind Ankündigungen mit Verfallsdatum, keine Warnung auf Vorrat.

Wer in TYPO3 12 das Deprecation-Log ignoriert hat, zahlt in 13 nach. Die gute Nachricht: TYPO3 12 protokolliert im Deprecation-Log präzise, was betroffen ist. Klasse, Methode, Zeile und oft die empfohlene Alternative stehen dort. Wer das Log systematisch abarbeitet, bevor er auf 13 wechselt, beseitigt den größten Teil des Risikos im Vorfeld.

Ein zweiter häufiger Stolperstein sind Extensions ohne TYPO3-13-Kompatibilität. Das ist nicht zwingend ein Qualitätsproblem einer Extension, sondern eine Frage des Timing: Release-Zyklen von TYPO3 und Extension-Maintainern laufen nicht synchron. Vor dem Upgrade prüft man daher alle installierten Extensions gegen die Kompatibilitätslisten im TER oder über Composer-Constraints.

Wie eine Migration sinnvoll abläuft

Der Ablauf ist nicht komplex, aber er verträgt keine Abkürzungen.

Testumgebung zuerst. Der gesamte Prozess läuft auf einer Kopie der Produktivinstanz. Nur in einer isolierten Umgebung sieht man alle Fehler, bevor sie echte Nutzer treffen.

Composer update auf 13.x. In einer Composer-basierten Installation ändern Sie die Versionsconstraints in der composer.json und führen composer update aus. Nicht-Composer-Installationen sind seit TYPO3 12 deprecated; spätestens jetzt ist der Wechsel überfällig.

Deprecation-Log abarbeiten. Noch vor dem eigentlichen Upgrade durch das Deprecation-Log aus TYPO3 12 arbeiten. Custom-TypoScript, Extension-Code und Template-Dateien sind die häufigsten Fundorte für veraltete Aufrufe.

Extension-Kompatibilität prüfen. Jede installierte Extension gegen die 13.x-Kompatibilität abgleichen. Extensions ohne Kompatibilitätserklärung entweder ersetzen, auf eine gepflegte Fork-Version setzen oder, sofern der Code überschaubar ist, selbst anpassen.

Dann testen. Funktionstest, Redaktionstest, Frontend-Check. In dieser Reihenfolge, nicht umgekehrt.

Was bleibt: die grundlegende Datenbankstruktur ist stabil, der Seitenbaum funktioniert wie gewohnt, der RTE bleibt erhalten. TypoScript ist nicht verschwunden. ContentBlocks reduzieren zwar den Bedarf daran für neue Content-Elemente, aber bestehende Konfigurationen behalten ihre Gültigkeit.

Wann der Wechsel sich lohnt

TYPO3 12 ist als LTS-Release bis Ende 2026 mit Security-Updates versorgt. Es besteht also kein sofortiger Druck. Der sinnvolle Migrationszeitpunkt für produktive Sites ist nicht der Tag-1-Release eines Major-Releases, sondern der erste Patch: 13.1 signalisiert, dass kritische Fehler des Releases behoben und die wichtigsten Extensions nachgezogen haben.

Ehrlicher Vorbehalt: Wie aufwändig die Migration konkret wird, lässt sich pauschal nicht sagen. Eine Standardinstallation mit wenigen gepflegten Extensions ist an einem Tag durch. Eine historisch gewachsene Multisite-Installation mit umfangreichem Custom-Code kann Wochen beanspruchen. Der Unterschied liegt fast nie in TYPO3 selbst, sondern im Zustand des bestehenden Codes.

Wer TYPO3 13 plant, startet am sinnvollsten mit einem Deprecation-Audit der laufenden 12er-Installation. Das ist der realistischste erste Schritt, da er zeigt, was tatsächlich zu tun ist, bevor man eine Aufwandsschätzung ansetzt.