Endlos-Spinner nach dem TYPO3-Upgrade: wenn ein Altlast-Feld das ganze Formular blockiert

Christopher Zechendorf

30.07.2026

Share:

Nach dem Upgrade auf TYPO3 13 hängt das Anlegen neuer Datensätze im endlosen Ladespinner – ohne Fehlermeldung. Wie ein Altlast-Feld das Formular blockiert.

Wenn das Backend nur noch dreht

Ein TYPO3-Upgrade gilt gemeinhin als geschafft, wenn das Frontend wieder sauber ausgeliefert wird und die Tests grün sind. Der unangenehmste Teil kommt aber manchmal erst danach – im Backend, im ganz normalen Redaktionsalltag. In zwei von uns betreuten TYPO3-Installationen zeigte sich nach dem Sprung von Version 12 auf 13 dasselbe Bild: Ein Klick auf „Neuer Datensatz” öffnete kein Eingabeformular mehr, sondern einen Ladespinner, der sich endlos weiterdrehte. Keine Fehlermeldung, kein Hinweis, kein Abbruch – nur eine Seite, die nie fertig wird.

Betroffen waren die TYPO3-Website von Profenster sowie eine weitere von uns betreute Installation. Die Ursache war am Ende eine einzige Feldkonfiguration, die noch aus deutlich älteren TYPO3-Zeiten stammte. Dieser Artikel zeigt, warum ein einzelnes Altlast-Feld ein komplettes Formular lahmlegen kann, warum genau dieser Fehler so schwer zu finden ist – und warum das Aufräumen solcher Altlasten in jede Upgrade-Vorbereitung gehört.

Die Herausforderung

Das Fehlerbild war denkbar unkomfortabel für die Fehlersuche, denn es fehlte schlicht jeder Anhaltspunkt:

• Kein Serverfehler. Die Anfrage lieferte einen sauberen HTTP-200. Im PHP-Fehlerlog und im TYPO3-Log stand nichts – aus Sicht des Servers war alles in Ordnung.
• Keine Fehlermeldung im Backend. TYPO3 zeigte weder eine Exception noch einen Hinweis an. Die Redaktion sah nur einen Spinner, der nicht aufhörte.
• Nicht überall reproduzierbar. Für manche Tabellen liess sich problemlos ein neuer Datensatz anlegen, für andere nie. Ein Muster war auf den ersten Blick nicht erkennbar.
• Vorher lief alles. Unter TYPO3 12 funktionierten exakt dieselben Formulare einwandfrei. Der Fehler entstand erst durch das Upgrade – ohne dass jemand die betroffenen Felder angefasst hätte.

Genau diese Kombination macht solche Regressionen teuer: Man sucht zwangsläufig zuerst dort, wo man Fehler gewohnt ist – in den Logfiles, in der Datenbank, in den eigenen PHP-Klassen. Und findet dort nichts, weil der Fehler gar nicht auf dem Server passiert.

Unsere Lösung

1. Die Suche dorthin verlagern, wo der Fehler entsteht

Wenn der Server einen fehlerfreien HTTP-200 liefert und trotzdem nichts erscheint, ist die Arbeit im Browser noch nicht abgeschlossen. Das TYPO3-Backend baut seine Eingabeformulare zu einem grossen Teil clientseitig auf: Die sogenannte FormEngine initialisiert nach dem Laden jedes einzelne Feld – Validierungsregeln, Datumsauswahl, Abhängigkeiten zwischen Feldern.

Der Blick in die Entwicklerkonsole des Browsers lieferte deshalb in Sekunden, was Stunden im Serverlog nicht hergegeben hätten: einen abgebrochenen JavaScript-Fehler aus der Datums-Bibliothek, mit der TYPO3 13 arbeitet. Der Spinner drehte sich nicht, weil etwas dauerte – er drehte sich, weil der Code, der ihn hätte ausblenden sollen, nie erreicht wurde.

2. Die Ursache: eine „0”, die kein Datum ist

Dahinter steckt eine Änderung, die mit dem Upgrade auf TYPO3 13 kam. Die clientseitige Formularvalidierung schickt jedes Feld, das in der Feldkonfiguration (dem TCA) als eval => 'datetime' markiert ist, durch die Datums-Bibliothek Luxon und deren Funktion DateTime.fromISO(). Erwartet wird also ein Datum im ISO-8601-Format.

In über Jahre gewachsenen Erweiterungen sind diese Felder aber häufig ganz anders angelegt: als reine Ganzzahl-Spalten mit dem Standardwert 0 – typischerweise die von älteren TYPO3-Vorlagen kopierten Sichtbarkeitsfelder starttime und endtime. Das Feld liefert der Validierung damit den Wert "0". Und "0" ist kein gültiges ISO-8601-Datum. Luxon wirft einen Fehler.

Der entscheidende Punkt ist, was dann passiert: Dieser Fehler wird nicht abgefangen. Er bricht nicht nur die Initialisierung des einen kaputten Feldes ab, sondern die gesamte Initialisierungsschleife – und damit den Aufbau des kompletten Formulars. Ein einziges Alt-Feld, das im Zweifel nicht einmal sichtbar ist, legt so ein Formular mit dreissig anderen, völlig intakten Feldern still. Das erklärt auch, warum der Fehler nur bestimmte Tabellen traf: genau jene, deren Konfiguration noch die alte Schreibweise enthielt.

3. Statt Workaround: auf den modernen Feldtyp migrieren

Die naheliegende Schnellreparatur wäre gewesen, den Standardwert von 0 auf etwas „Datumsähnliches” zu ändern. Das hätte das Symptom kaschiert und die eigentliche Altlast konserviert. Wir haben stattdessen migriert.

TYPO3 kennt seit Version 12 einen eigenständigen Feldtyp type => 'datetime', der die frühere Konstruktion aus Texteingabefeld plus Render-Typ plus eval-Kette ersetzt. In den betroffenen Konfigurationsdateien haben wir konsequent darauf umgestellt und die obsoleten Angaben (renderType, eval, size, checkbox) entfernt. Zwei Eigenschaften blieben bewusst unverändert: der Standardwert und der zulässige Wertebereich, beide weiterhin als klassische Zeitstempel.

Das ist der wichtigste Punkt für den Betrieb: An der Datenhaltung ändert sich nichts. Die Spalten bleiben Ganzzahl-Spalten mit Unix-Zeitstempeln, es ist keine Datenmigration nötig, und bestehende Inhalte bleiben unangetastet. Der moderne Feldtyp interpretiert die 0 schlicht als „leer”, statt sie an eine Datumsbibliothek weiterzureichen, die daran scheitert. Damit ist die Fehlerquelle nicht umgangen, sondern beseitigt.

4. Vollständigkeit statt Symptombehandlung

Ein Fix, der nur das gemeldete Formular repariert, ist bei diesem Fehlerbild wenig wert – denn jedes weitere Alt-Feld wartet nur darauf, beim nächsten Klick dasselbe zu tun. Deshalb gehört zu einem solchen Fix zwingend eine systematische Nachkontrolle: Wir haben die gesamte Erweiterung nach der alten Schreibweise durchsucht, alle Fundstellen migriert und anschliessend verifiziert, dass keine einzige Konfiguration mit dem alten Muster mehr übrig ist. Bei einem der beiden Projekte betraf das vier Konfigurationsdateien quer über Inhaltselemente und eigene Datenmodelle hinweg – gefunden wurden sie nur durch die vollständige Suche, gemeldet worden war ein einziges Formular.

5. Die stillen Altlasten gleich mit aufräumen

Bei dieser Gelegenheit kam eine zweite, unauffälligere Altlast zum Vorschein: Verweise auf Beschriftungstexte, die auf Erweiterungen zeigten, die es im TYPO3-Core so gar nicht mehr gibt. Beim Umbau des Cores in einzelne Composer-Pakete sind diese Pfade umgezogen; die alten Referenzen laufen seither ins Leere.

Diese Verweise legen nichts lahm – sie sorgen nur dafür, dass Felder im Backend gar nicht oder mit kryptischen Platzhaltern beschriftet sind. Für die Redaktion ist das trotzdem täglich spürbar. Wir haben die Pfade auf ihre heutigen Entsprechungen im Core-Paket korrigiert und gegen die tatsächlich installierte Core-Version geprüft, statt sie aus dem Gedächtnis zu setzen.

Das Ergebnis

Das Anlegen neuer Datensätze funktioniert in beiden Installationen wieder – und zwar nicht nur in dem gemeldeten Formular, sondern in allen, die dieselbe Altlast in sich trugen. Die Änderung blieb dabei bewusst klein und gut überprüfbar: reine Feldkonfiguration, kein Eingriff in Programmlogik, keine Datenmigration, kein sichtbarer Unterschied im Frontend. Die Umstellung wurde vor dem Ausrollen unabhängig gegengeprüft – auf Korrektheit der Migration, auf Datenkompatibilität der Zeitstempel und vor allem auf Vollständigkeit.

Fazit

Der teuerste Teil dieses Fehlers war nicht die Reparatur, sondern die Suche. Ein Formular, das ohne jede Fehlermeldung im Ladespinner hängen bleibt, gibt von sich aus keinen einzigen Hinweis darauf, dass die Ursache eine unscheinbare Feldkonfiguration ist, die niemand mehr bewusst gepflegt hat.

Daraus lassen sich drei Dinge mitnehmen. Erstens: Ein Upgrade ist nicht mit dem grünen Frontend abgeschlossen – die Backend-Abläufe der Redaktion gehören genauso auf die Testliste, inklusive „Neuer Datensatz” für jede eigene Tabelle. Zweitens: Wenn der Server einen sauberen HTTP-200 liefert und trotzdem nichts erscheint, lohnt der Blick in die Browserkonsole mehr als jede weitere Runde im Serverlog. Und drittens, am wichtigsten: Veraltete Feldkonfigurationen sind keine Kosmetik, die man „irgendwann mal” angeht. Sie sind stille Blockaden, die genau dann zuschlagen, wenn eine neue Major-Version die Spielregeln ändert. Ein sauberes Upgrade räumt sie systematisch mit ab – nicht erst, wenn die Redaktion vor einem drehenden Spinner sitzt.

Steht bei Ihnen ein TYPO3-Upgrade an, oder verhält sich Ihr Backend seit dem letzten Versionssprung merkwürdig? Sprechen Sie uns an – wir prüfen Ihre Installation auf genau solche Altlasten, bevor sie im Alltag auffallen.