www.verl.de

Bugsink: https://bugsink.cytrus.de/issues/issue/66d39446-dd85-452c-afd4-5d5c3ce5338f/event/last/

Typ: NEW issue

Projekt: www-verl-de

Bugsink Alert

RuntimeException: Could not find row with UID "0" in table "sys_file"

Automatisch erstellt durch n8n

KI-Analyse:

Fehleranalyse: RuntimeException: Could not find row with UID "0" in table "sys_file" ¶

1. Ursache identifizieren¶

Der Fehler bedeutet, dass TYPO3 versucht, einen Datensatz aus der Tabelle sys_file mit der UID 0 zu laden – ein solcher Datensatz existiert niemals in einer gültigen Datenbank. Dies geschieht typischerweise in folgenden Fällen:

• Korrupte sys_file_reference-Datensätze: Es existiert ein Verweis (sys_file_reference, Feld uid_local) mit dem Wert 0, der auf eine nicht existierende Datei zeigt.
• Gelöschte Datei mit noch vorhandenen Referenzen: Eine sys_file-Datei wurde gelöscht, aber die Verknüpfungen in sys_file_reference oder Feldern wie tt_content.assets wurden nicht aufgeräumt.
• Fehlerhafte Seiteninhalte: Ein Content-Element (z. B. ein Media-Element, Textpic, oder ein Grid Element) enthält eine Dateireferenz mit UID 0.
• FAL-Auflösung während Rendering: Während der Seitenrendering-Phase versucht das Fluid-Styled-Content-System (oder eine andere Extension) über das FAL (File Abstraction Layer) eine Datei aufzulösen, die nicht mehr existiert.

Warum im Stack Trace keine Extension-Sichtbar?
Der Stack Trace zeigt hauptsächlich Core-Komponenten (MiddlewareDispatcher, AbstractApplication). Der Fehler wird wahrscheinlich während des Frontend-Renderings im Page-Controller ausgelöst, wenn Inhalte mit Dateireferenzen verarbeitet werden – vermutlich über PageRenderer oder ContentObjectRenderer, die intern FAL aufrufen.

2. Fix (konkret)¶

Schritt 1 – Betroffene Referenzen finden:

-- Zeigt alle Referenzen, die auf nicht-existierende sys_file-UIDs zeigen
SELECT * FROM sys_file_reference 
WHERE uid_local NOT IN (SELECT uid FROM sys_file);

-- Speziell nach UID 0
SELECT * FROM sys_file_reference WHERE uid_local = 0;

Schritt 2 – Betroffene Datensätze bereinigen:

-- Lösche die problematischen Referenzen (VORSICHT: Backup vorher!)
DELETE FROM sys_file_reference WHERE uid_local = 0;

-- Oder allgemeiner:
DELETE FROM sys_file_reference WHERE uid_local NOT IN (SELECT uid FROM sys_file);

Schritt 3 – Fehlerhafte Inhalte reparieren (falls in tt_content.assets):

-- Prüfe, ob Content-Elemente auf UID 0 verweisen
SELECT uid, pid, assets FROM tt_content WHERE FIND_IN_SET('0', assets);

Schritt 4 – Vorbeugung:

• Füge einen Data Handler-Hook hinzu, der vor dem Speichern prüft, ob uid_local gültig ist.
• Implementiere eine Custom CLI-Command in der betroffenen Extension, die regelmäßig orphaned References aufräumt.
• Nutze TCA-Validation: 'eval' => 'integer' und '_CSH'-Prüfung im Backend-Formular.

3. Betroffene TYPO3 Extension¶

Am wahrscheinlichsten betroffene Extensions:

• fluid_styled_content (Core-Extension, VSC) — das Standard-Content-Rendering-System, das Media-Elemente mit FAL verarbeitet.
• gridelements — falls Grid Elements mit Dateifeldern verwendet werden.
• mask — falls Mask Content Elements mit Dateifeldern konfiguriert sind.
• Eine individuelle/custom Extension, die sys_file-Referenzen im Frontend rendert.

Ohne die genaue Fehlerzeile im Stack Trace (die im vorliegenden Trace nicht sichtbar ist) ist die wahrscheinlichste Extension fluid_styled_content als Auslöser, da dies das Standard-System ist, das beim Rendern von Content-Elementen FAL aufruft.

4. Confidence¶

Confidence: 85%

Begründung:

• ✅ Der Fehlermuster Could not find row with UID "0" in table "sys_file" ist ein absolut typischer TYPO3-FAL-Fehler
• ✅ Die Diagnose (korrupte Dateireferenz / gelöschte Datei mit Restreferenzen) ist in der TYPO3-Community weit verbreitet und gut dokumentiert
• ❌ Der Stack Trace zeigt keine explizite Extension oder Fehlerzeile, was die exakte Zuordnung erschwert
• ❌ Ohne die vollständige Exception-Stack-Trace-Position (welche Klasse/Datei den Fehler auslöst) kann nicht mit 100%iger Sicherheit gesagt werden, welche Extension der direkte Auslöser ist

Empfehlung: Ergänze den vollständigen Exception-Stack-Trace (inkl. der tiefen Schicht, die sys_file->findByUid(0) aufruft), um die betroffene Extension definitiv zu identifizieren.