Jeder, der seit ein paar Jahren TYPO3-Projekte betreut, kennt das Problem: Ein neues Major-Release wie TYPO3 v14 steht vor der Tür, der Core macht riesige Sprünge – aber manche etablierte Extension hängt fest.
Ein Paradebeispiel dafür ist der Localization Manager (l10nmgr). Für komplexe, mehrsprachige Instanzen ist das Tool Gold wert. Das Problem: Die frei zugängliche Version im Repository steht bei v12. Version 13 ist nicht öffentlich verfügbar, und eine offizielle v14 gibt es schlicht nicht.
Vor diesem Dilemma stand ich vor kurzem für interne Zwecke. Die Lösung? Ich habe mir die öffentliche v12 geschnappt und sie in akribischer Kleinarbeit – aber mit kräftiger KI-Unterstützung – direkt auf TYPO3 v14 gehoben. Völlig in Eigenregie, ohne Anbindung an die offiziellen Entwickler des l10nmgr und natürlich ohne die geschützten Features einer v13.
Das Ergebnis ist eine funktionierende, interne Lauffähigkeit für pages und tt_content. Doch das Experiment wirft ein paar spannende Fragen auf.
Der Doppel-Sprung: Wo KI echte Hilfe war
Von v12 direkt auf v14 zu springen bedeutet, eine komplette Core-Generation (v13) schlicht zu überspringen. Das heißt doppelt so viele Deprecations, doppelt so viele Breaking Changes und völlig veraltete API-Muster im Quellcode.
Sagen wir, wie es ist: Ohne KI-Unterstützung hätte ich mir diesen Aufwand für ein internes Werkzeug kaum gemacht.
- Der Zeit-Katalysator: KI-Modelle sind genial darin, alte v12-Code-Muster zu erkennen und Vorschläge zu machen, wie man zwei Major-Versionen an Core-Evolution auf einmal überbrückt.
- Muster-Mapping im Akkord: Veraltete API-Aufrufe über Dutzende Dateien hinweg aufzuspüren und systematisch umzubauen, ist für eine KI eine reine Fleißaufgabe.
- Eigenbau statt Sackgasse: Statt darauf zu warten, ob irgendwann ein offizielles Update kommt, kann man sich für den eigenen Workflow selbst helfen.
Die Schattenseite: Die Verantwortung beim "Inoffiziellen Fork"
So genial die Möglichkeit ist, veralteten Code eigenhändig wiederzubeleben – man muss sich der Grenzen und der Verantwortung bewusst sein.
1. Völlige Eigenverantwortung
Wenn man eine Extension auf eigene Faust migriert, gibt es kein Sicherheitsnetz. Keine Community, die Bugfixes liefert, und kein offizielles Team, das man fragen kann.
Mein Grundsatz: Wenn der KI-gestützte Code beim Import Daten korrumpiert oder eine Sicherheitslücke aufreißt, gibt es keinen Maintainer, auf den man zeigen kann. Die Verantwortung liegt zu 100 % bei mir.
2. Der "Schuldenberg auf Pump"
Weil die offizielle v13 nicht öffentlich ist, fehlen meinem internen Port sämtliche Features oder Architektur-Anpassungen, die in dieser Generation entstanden sein könnten. Ich habe sozusagen eine v12 auf v14 "gepatcht". Wenn man hier nicht genau versteht, was die KI im Code geändert hat, baut man sich für zukünftige Updates eine technische Schuldenfalle.
3. Community vs. Eigenbrötelei
Open Source lebt eigentlich vom Teilen. Ein reiner "Private Port" löst zwar das eigene Problem, hilft der Community aber erst einmal nicht direkt weiter. Umso wichtiger ist es, transparent zu kommunizieren: Das hier ist ein Experiment für den eigenen Bedarf, kein offizielles Produkt.
Mein Fazit
Dass der l10nmgr auf Basis der v12 bei mir intern unter TYPO3 v14 wieder läuft, zeigt enorm gut, was heute dank KI möglich ist. Man ist nicht mehr völlig blockiert, wenn Erweiterungen veralten.
Aber KI ist kein Zauberstab. Sie nimmt uns die stupide Anpassungsarbeit ab – die Analyse, das Risiko und die finale Verantwortung für die Datenintegrität bleiben reine Mendersache.