A missing item in the WordPress Styles save summary does not prove that the style failed to save. First compare the pending summary, the value after reloading the editor, and the frontend result. A reporting gap can hide the label for a site-wide change while the underlying style still persists.
Check the Scope and Installed Build
Gutenberg change 81407, merged August 11, 2026, addresses missing reports for site-wide border, shadow, outline, filter and dimensions changes. Previously, the change list did not compare all the style groups rendered by the engine. The fix also supplies labels for those groups. Block-level changes were already identified by their block name.
That scope matters. A missing site-wide shadow label is not automatically the same defect as an unsaved button color or a paragraph whose styles were reset. Record the WordPress version, Gutenberg plugin version if active, theme and precise screen. A merged upstream change is not proof that every installed build contains it.
Keep Three Pieces of Evidence Separate
Use a staging copy and a reversible, visible test change. Before editing, capture the original value and one frontend element that actually uses the relevant style. Keep unrelated pending edits out of this test so the save dialog is easy to interpret.
| Evidence |
Question it answers |
What it cannot prove alone |
| Save summary |
Does the editor describe this pending change? |
Whether the server stored it |
| Value after editor reload |
Does the stored editor configuration retain the edit? |
Which CSS rule wins on the public page |
| Frontend computed style |
What styling reaches this element? |
Whether every other element uses the same preset |
| Revision entry |
Is the recorded change described in history? |
Whether the current public response is fresh |
Record the original setting, save result, reloaded value, revision and frontend rule separately. Use one reversible staging edit. Explanatory diagnostic, not a product screenshot.
Run a One-Change Save Test
- Open the Site Editor and enter Styles. Choose a supported site-wide control, such as a shadow setting available in your theme and build.
- Record the original value. Make one small, recognizable change on staging. Do not reset every style to establish a baseline.
- Open Save and capture the list of pending changes. Write down whether the relevant style group is mentioned.
- Complete the normal save operation. Note any visible error. If you inspect its network request, retain only the status and redacted diagnostic details, not authentication tokens.
- Reload the editor and revisit the same control. Compare the actual value with your recorded edit.
- Open Styles revisions, where available, and inspect the latest entry. Compare its timestamp and label with this specific save, not an earlier unrelated revision.
- Load the public page and inspect the intended element. Confirm which rule or preset supplies the computed style before changing caching or inheritance settings.
If the value survives reload but its label is absent, report a summary problem. If the value disappears and the save request failed, investigate the save failure instead. If the editor retains the new value but the public element differs, investigate the frontend rule, selected preset and response freshness. These branches require different fixes.
Avoid a Destructive Reset as a Diagnostic
Do not repeatedly change the same setting until a summary line appears. That creates extra revisions without establishing which layer is wrong. Restore the single test value after gathering evidence and confirm the restoration through the normal save flow.
For an older build, reproduce with a supported update on an isolated copy before making a production upgrade decision. Keep a copy of the theme configuration and current style customizations. Review the relevant release documentation and compatibility requirements rather than copying a source patch into core files on a live site.
For developers maintaining a custom summary, test the underlying compared properties and their display labels independently. A value can be detected by one layer and dropped by a missing label mapping in another. Add a fixture with only one changed property so an unrelated typography change cannot make a broken summary appear complete.
Send a Reproducible Report
Include build versions, the control's location, before and after values, the save result, the reloaded value and the revision timestamp. State explicitly whether the frontend changed. Use redacted screenshots or a disposable staging example rather than exporting the site's whole database.
If the problem is a block missing from the list, follow the Customized filter checks. If a reset reveals another color or spacing value, use the style inheritance diagnostic. For a confirmed persistence or theme integration defect, request a scoped WordPress fix with the evidence above.
This is a diagnostic recipe, not a claim that the test was run on your theme or that a missing summary always has one cause.
References reviewed October 23, 2026. Examples are explanatory, not customer results.