Dieses Kapitel sammelt die Fehlerbilder, die über die ganze Serie hinweg schon einzeln erwähnt wurden, und ergänzt eine systematische Debugging-Reihenfolge - die drei häufigsten Symptome bei UI-Components-Arbeit.

Symptom 1: Leeres Grid ohne Fehlermeldung

Die häufigste Ursache ist eine falsche provider-Kette (Kapitel 4): Der Wert in js_config/provider muss exakt {listing_name}.{dataSource_name} entsprechen. Prüfschritte in Reihenfolge:

1. Browser-Netzwerk-Tab öffnen, nach mui/index/render filtern - kommt der Request überhaupt an, und was liefert die Response?
2. Bei einer JSON-Response mit leerem items-Array: Filterlogik im DataProvider prüfen, insbesondere versehentlich zu enge addFieldToFilter()-Aufrufe.
3. Bei gar keinem Request: provider-Kette in js_config gegen den tatsächlichen dataSource-Namen abgleichen.
4. Bei einem 404/500 auf mui/index/render: PHP-Exception-Log prüfen (bin/log exception.log) - meist ein Klassenname-Tippfehler im dataProvider-Argument.

Symptom 2: Formular speichert nicht (oder scheinbar gar nichts passiert)

• Redirect auf 404 - der Save-Controller implementiert HttpPostActionInterface nicht (Kapitel 12), oder submit_url in form.xml zeigt auf einen falschen Pfad.
• Seite lädt neu, aber ohne sichtbare Änderung - Validierungsfehler ohne DataPersistorInterface (Kapitel 12), die Fehlermeldung erscheint als Session-Message, wird aber leicht übersehen.
• Speichern-Button reagiert gar nicht - meist ein JavaScript-Fehler in der Browser-Konsole, oft durch eine defekte validation-Regel (Kapitel 11) oder ein fehlendes <field>, auf das ein imports/exports-Pfad (Kapitel 21) verweist.

Symptom 3: Änderung an XML/PHP wird nicht sichtbar

Verschiedene Dateitypen landen in verschiedenen Caches - die passende Cache-Leerung zu kennen spart viel Zeit:

• listing.xml/form.xml-Änderungen - bin/cache-clean reicht meist (UI-Component- und Layout-Cache, Kapitel 4).
• acl.xml/menu.xml-Änderungen - cache:clean plus gegebenenfalls Admin-Logout/Login (Kapitel 3).
• Neue/geänderte PHP-Klasse - bei aktivem di.xml-Compile (Produktionsmodus) ist setup:di:compile nötig, im Entwicklermodus reicht in der Regel cache:clean.
• db_schema.xml-Änderungen - immer setup:upgrade, niemals nur Cache-Befehle (Kapitel 2).

Systematische Debugging-Reihenfolge

1. Browser-Konsole und Netzwerk-Tab zuerst - viele Probleme sind rein clientseitig sichtbar, bevor man überhaupt PHP-Code anfasst.
2. bin/log exception.log und bin/log system.log auf frische Einträge prüfen.
3. Bei Datenproblemen: direkt in der Datenbank nachsehen (bin/mysql), ob die erwarteten Zeilen/Spalten überhaupt existieren.
4. Erst danach: XML-Deklaration Zeile für Zeile gegen ein bekannt funktionierendes Beispiel (etwa aus Kapitel 15/16) vergleichen.