One of the most irritating things a tool can do is tell you that you have made a mistake when it has not finished checking.
In May 2026 I fixed an editor flow that did exactly that. A saved block opened with a valid selection, but its supporting data arrived afterwards. During that brief gap the interface treated an empty list as proof that the selection was no longer available. The warning could stick even once the preview had loaded correctly.
“Nothing here yet” is different from “nothing exists”
The mistake was in the states the interface understood. It knew about loading and it knew about an empty result. It did not properly distinguish a request that had not started from one that had completed.
I changed the checks so a warning needed evidence from a completed lookup. The useful general pattern is to keep separate states for not started, loading, loaded with results, loaded without results and failed. A timeout belongs in that last state; it does not prove that the thing being looked up has disappeared.
Clear the whole dependent selection
The same editor had linked fields. Pick a broad option, then a narrower option, then an individual item. Changing the first field cleared only part of what followed it. Old selections could remain in the saved attributes while the screen was already showing a new list.
I made the reset follow the dependency chain. Changing a parent clears the children that no longer make sense, their temporary lists and any error attached to the old combination. That is a data rule, not just a visual tidy-up.
What I ask of a good error message
- Say which action failed: loading a list, validating a choice or saving the block.
- Use language an editor understands, with technical detail available separately.
- Give a sensible next step, such as retrying the request or choosing again.
- Disappear when the condition has been resolved.
- Keep already saved content intact when a temporary service error occurs.
I test this with a slow connection, a failed request and an existing saved block, as well as the happy path of creating a new one. The awkward states are where an editor decides whether they trust the tool.
This was an engineering fix with a very ordinary benefit: fewer false alarms while someone was trying to get their work done. That is usually a better starting point for a custom WordPress interface than adding another panel of settings.