Von v12 direkt auf v14: Warum ein KI-gestützter Port des l10nmgr kein Spaziergang war

„Schmeiß den Code der alten Extension einfach in ChatGPT, die macht das schon fit für TYPO3 v14!“

Diesen Satz hört man aktuell öfter. Und Spoiler vorab: Wer so an ein Upgrade komplexer Extensions herangeht, wird sein System mit Anlauf an die Wand fahren.

Wichtiger Hinweis vorweg: Ich gehöre nicht zum Entwicklerteam des Localization Manager (l10nmgr) und das hier ist kein offizielles Release. Ich habe mir lediglich die öffentlich zugängliche v12 geschnappt und sie für interne Zwecke in Eigenregie auf TYPO3 v14 portiert. Da die v13 nicht öffentlich ist, fehlte jegliche Zwischenstufe – ich musste also zwei Major-Versionen an Breaking Changes auf einmal überbrücken.

Genau bei diesem Doppel-Sprung habe ich die echten Grenzen von KI-Tools erlebt. Hier sind ein paar konkrete Beispiele aus der Praxis, warum blindes KI-Vertrauen beim Refactoring scheitert.

---

1. Das Trainingsdaten-Problem: KI liebt alte Zöpfe

Ein Sprachmodell weiß nicht, was sich im allerneuesten TYPO3-Core geändert hat – es kennt vor allem das, womit es gefüttert wurde. Und beim Sprung von v12 auf v14 halluziniert die KI mit Vorliebe veraltete Zwischenlösungen zusammen, die im v14-Core sofort einen Fatal Error werfen:

• Die alte KI-Gewohnheit: Um Übersetzungsdatensätze abzufragen, schlägt die KI gerne gewohnte Helfer wie LocalizationRepository::getRecordTranslation() vor.
• Die v14-Realität: In v14 läuft das über saubere, TCA-basierte Record-Lookups.
• Gleiches Spiel bei der Datenbank: Altes Doctrine-Handling muss explizit auf Connection::createSchemaManager() umgebaut werden.

Die KI baut dir fehlerfreien PHP-Code – der auf einem v14-System trotzdem augenblicklich crasht, weil die Methoden im Core gar nicht mehr existieren.

---

2. Datenkorruption verhindern: Der RTE-CAT-XML-Roundtrip

Der l10nmgr schubst nicht nur ein paar Strings durch die Gegend, sondern exportiert Datenstrukturen in spezielles XML für Übersetzungs-Tools (CAT-Software) und liest sie wieder ein.

Das muss absolut symmetrisch laufen. Bei Rich-Text-Feldern (RTE) in pages und tt_content bedeutet das: Absätze, HTML-Tags und Links müssen nach dem Re-Import exakt an der gleichen Stelle sitzen wie vorher.

• Wo die KI blind ist: KI schaut auf isolierte Code-Schnipsel. Sie "sieht" nicht den gesamten Datenfluss über Export und Import hinweg. Ändert sie beim Refactoring des XML-Parsers auch nur eine Kleinigkeit, geht der Export zwar durch, aber beim Import zerschießt es leise die Formatierung in der Datenbank.
• Der FlexForm-Fallstrick: Beim Traversieren von FlexForms über das compiled TcaSchema müssen unvollständige Datensätze sauber auf null-Werte geprüft werden. Die KI vergisst solche Edge Cases gerne – bis im Backend ein Redakteur ein halb ausgefülltes Element übersetzen will und das Modul abbricht.

Solche Fehler findet keine KI per Prompting, sondern nur der Entwickler durch akribisches Debugging mit echten Testdaten.

---

3. Strikte Security: Das Desaster mit Inline-JavaScript

Ein Klassiker, wenn man die KI bittet, das Backend-Modul auf den neuesten Stand zu bringen: Sie baut schnell ein kleines Inline-Script oder ein onclick="document.forms[0].submit()" ein, damit die Buttons im Modul wieder reagieren.

In TYPO3 v14 knallt das sofort. Dank strenger Content Security Policy (CSP) sperrt der Core Inline-Code rigoros aus.

• CSP-Konformität: Sämtliche Event-Listener und Formular-Submits mussten sauber aus dem Fluid-Code getrennt und CSP-konform eingebunden werden.
• UI-Upgrade: Nebenbei musste die Navigation des Moduls auf moderne Bootstrap-5-Tabs umgestellt werden.

Der KI ist eine CSP-Violation völlig egal – in ihrer isolierten Code-Welt funktioniert das Skript ja. Dass der Browser die Ausführung im TYPO3-Backend blockiert, merkt man erst beim manuellen Testen in den Developer Tools.

---

Mein Fazit für die Praxis

Der l10nmgr läuft bei mir intern für pages und tt_content jetzt stabil unter TYPO3 v14 – aber nicht, weil die KI den Job erledigt hat, sondern weil sie mir die stupide Tipparbeit abgenommen hat, während ich den Code Schritt für Schritt durchleuchtet und korrigiert habe.

Wenn du ein ähnliches internes Portierungsprojekt planst, behandle die KI wie einen sehr schnellen, aber extrem zerstreuten Junior-Entwickler:

1. Lass dir die reine Fleißarbeit abnehmen.
2. Hinterfrage jede geänderte API-Zeile.
3. Teste den Daten-Roundtrip gründlich mit echten Test-Inhalten.

Erst die Kombination aus KI-Geschwindigkeit und deiner eigenen Erfahrung führt zu einem Code, dem du deine Datenbank anvertrauen kannst.

DIY-Upgrade auf TYPO3 v14: Warum ich den l10nmgr selbst migriert habe – und was das bedeutet

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.

[UPDATE 2] TYPO3 9.x+ Routing mit tx_jobfair nutzen

Ich weiß ich weiß, eigentlich nutzt man keine veralteten Extensions mehr, die evtl. noch Sicherheitsprobleme haben - in diesem Fall nutze ich die Upload-Funktion überhaupt nicht, daher sollte diese Sicherheitslücke gar kein Problem mehr sein. Zurück zum Thema

Kurzum, wenn Ihr Jobfair mit TYPO3 9 oder 10 nutzen wollt und trotzdem sprechende URLs haben möchtet, braucht ihr folgenden Code in der der Siteconfig (config.yaml). An dieser Stelle möchte ich mich nochmal bei den Mitgliedern der inoffziellen TYPO3-Gruppe auf Facebook herzlich bedanken für die Hilfe! 

  Jobfair:

    type: Extbase

    limitToPages: 

      - 123

    extension: Jobfair

    plugin: Pi1

    routes:

      - 

        routePath: '/{job_title}'

        _controller: 'Job::show'

        _arguments:

          job_title: job

    defaultController: 'Job::show'

    aspects:

      job_title:

        type: PersistedAliasMapper

        tableName: tx_jobfair_domain_model_job

        routeFieldName: job_title slug

UPDATE:

Hey Leute, kurzes Update - wie ihr im Code oben sehen könnt, habe ich bei "routeFieldName:" anstatt job_title nun slug genommen. Das ist viel besser, weil hier aus den Titeln saubere URLs generiert werden. Gerade bei Stellenanzeigen mit Angaben wie z.B. (m/w/d) oder so werden die Slashes nicht mit in die URL übernommen sondern sauber mit "-" umgeschrieben. Dasselbe gilt auch für Umlaute. 

Falls ihr viele Stellenanzeigen habt und die ganzen Slugs nicht per Hand neu generieren wollt (bei einem Upgrade der Website) dann kann ich euch die Extension "Rebuild URL slugs" empfehlen. Damit könnt ihr auf Knopfdruck z.B. von allen News oder allen Jobs die Slugs neu generieren. 

P.S.: Wenn ihr eine angepasste Version von Jobfair für V9 haben wollt, gebt mir einfach Bescheid - aber bitte nicht die Bewerbungsfunktion nutzen! 

UPDATE 2 (2022): 

Jobfair wurde inzwischen offiziell fortgeführt! Vielen Dank an dieser Stelle an "nhovratov"!

Mir ist allerdings bei einer Installation ein neuer Bug aufgefallen: Wenn ihr die Stellenanzeigen in einem Ordner habt, der nicht im Seitenbaum eurer aktuellen Website liegt, werden die Stellenanzeigen auf der Detailseite nicht korrekt angezeigt. Siehe Screenshot, damit ihr wisst, was ich meine:

Es geht hier darum, dass dieselben Stellenanzeigen auf mehreren Seiten eingebunden werden sollen. Das Problem wird hier nochmal ausführlich dargestellt: https://forge.typo3.org/issues/91397. 

Die Lösung bei Jobfair: Ihr müsst folgende TCA anpassen, dann sollte es funktionieren:

$GLOBALS['TCA']['tx_jobfair_domain_model_job']['columns']['slug']['config']['eval'] = 'unique';

Nextcloud Fehlermeldung: Step 4 is currently in process. Please reload this page later.

Hey Leute, 

wenn ihr mal euer Nextcloud aktualisiert und der Vorgang (aus welchem Grund auch immer) hängt und jeder Update-Prozess mit der Fehlermeldung "Step 4 is currently in process. Please reload this page later." quittiert wird, dann könnt ihr folgendes machen: 

1. Geht per FTP/Shell/WebFTP etc. zum Unterordner "data". Hier dürfte es einen Unterordner namens "updater-xxxxxxxxxxxx" geben, wobei die "x" eine beliebige Zeichenfolge sein können. 
2. Löscht diesen Unterordner (könnte eine Weile dauern, weil in dem Unterordner sämtliche Dateien für das jeweilige Update hinterlegt ist)
3. Started den Updateprozess neu
4. Et voilà!