This chapter collects the failure patterns that have already been mentioned individually throughout the series, and adds a systematic debugging order - the three most common symptoms in UI Components work.

Symptom 1: empty grid with no error message

The most common cause is a wrong provider chain (chapter 4): the value in js_config/provider must exactly match {listing_name}.{dataSource_name}. Steps to check, in order:

1. Open the browser network tab, filter for mui/index/render - does the request even arrive, and what does the response return?
2. For a JSON response with an empty items array: check the DataProvider's filter logic, especially accidentally too-narrow addFieldToFilter() calls.
3. For no request at all: compare the provider chain in js_config against the actual dataSource name.
4. For a 404/500 on mui/index/render: check the PHP exception log (bin/log exception.log) - usually a typo in the class name of the dataProvider argument.

Symptom 2: form doesn't save (or nothing visibly happens)

• Redirect to a 404 - the save controller doesn't implement HttpPostActionInterface (chapter 12), or submit_url in form.xml points to the wrong path.
• Page reloads but with no visible change - a validation error without DataPersistorInterface (chapter 12); the error appears as a session message but is easy to miss.
• Save button doesn't react at all - usually a JavaScript error in the browser console, often from a broken validation rule (chapter 11) or a missing <field> that an imports/exports path (chapter 21) references.

Symptom 3: an XML/PHP change doesn't show up

Different file types land in different caches - knowing the right cache to clear saves a lot of time:

• listing.xml/form.xml changes - bin/cache-clean is usually enough (UI Component and layout cache, chapter 4).
• acl.xml/menu.xml changes - cache:clean plus possibly an admin logout/login (chapter 3).
• A new/changed PHP class - with an active di.xml compile (production mode), setup:di:compile is required; in developer mode, cache:clean is usually enough.
• db_schema.xml changes - always setup:upgrade, never just cache commands (chapter 2).

A systematic debugging order

1. Browser console and network tab first - many problems are visible purely client-side before touching any PHP code.
2. Check bin/log exception.log and bin/log system.log for fresh entries.
3. For data problems: look directly in the database (bin/mysql) for whether the expected rows/columns even exist.
4. Only after that: compare the XML declaration line by line against a known-working example (for example from chapter 15/16).