WordPress 7.1 Beta 3 adds selective review to Apply globally, but a custom block may declare supports, serialize attributes, and consume theme.json values differently from a core block. A passing core Button test does not prove a third-party or in-house block promotes only the selected values.
Use this for dynamic blocks, block.json packages, ACF blocks, nested blocks, custom style variations, server-rendered markup, and agency design systems that let editors promote local styling.
Quick answer
Choose one custom block with color, typography, spacing, border, and an unsupported custom control. Record its block.json supports and serialized markup, select only two values in Apply globally, save, and compare the global style path, revision diff, other instances, templates, and rendered CSS. Then restore the revision.
What to check first
- Record block version, apiVersion, supports declaration, attributes, render callback, selectors, style variations, active theme, and relevant theme.json paths.
- Create local values that come from block supports and values stored in custom attributes so the review must distinguish them.
- Capture proposed global paths and selected states before save, then diff the global style revision and post content after save.
- Inspect another instance, a nested instance, a synced pattern, a template part, and front-end pages using different templates.
- Test editor reload, revision restore, theme variation switch, cache clear, and the same workflow under a non-administrator editor role.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Map supports and serialized attributes | Record block version, apiVersion, supports declaration, attributes, render callback, selectors, style variations, active theme, and relevant theme.json paths. | The revision diff contains only the selected paths. |
| Create mixed local values | Create local values that come from block supports and values stored in custom attributes so the review must distinguish them. | Serialized custom attributes do not change unexpectedly. |
| Review proposed global paths | Capture proposed global paths and selected states before save, then diff the global style revision and post content after save. | Editor, server render, templates, and front end agree. |
| Compare revisions and every render context | Inspect another instance, a nested instance, a synced pattern, a template part, and front-end pages using different templates. | Revision restore works after cache and browser state are cleared. |
Why this usually happens
- A custom control may look like a standard block support while storing a private attribute.
- Selectors in block.json can route style values to a nested element.
- Server-rendered markup can consume global CSS differently from the editor preview.
- A style variation can mask the saved value until another template or state loads.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
block: acme/notice
api_version: 3
supports_tested: [color, spacing, border]
custom_attribute: iconShadow
selected_global: [color.background, border.width]
unselected_local: [spacing.padding, iconShadow]
revision_diff_expected: 2
revision_diff_found: 2
front_end_scope: pass
rollback: pass
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Map supports and serialized attributes
- Create mixed local values
- Review proposed global paths
- Compare revisions and every render context
- Restore and document the baseline
Decision rule
Pass when only selected support-backed values enter the expected block style path, custom attributes remain local, unrelated blocks stay unchanged, and revision restore returns the exact prior output.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- The revision diff contains only the selected paths.
- Serialized custom attributes do not change unexpectedly.
- Editor, server render, templates, and front end agree.
- Revision restore works after cache and browser state are cleared.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, or delayed background work.
- Do not paste secrets, personal data, or complete production payloads into tickets or screenshots.
- Do not close the test until the final user-visible state and server-side evidence agree.
Questions teams ask during testing
Does block support declaration guarantee Apply globally support?
No. Selectors, serialization, custom controls, and render callbacks can still create scope differences that need testing.
What if the control has no theme.json equivalent?
Treat it as local unless the block explicitly implements a stable global mapping. Do not infer a path from its label.
When HandL WP should help
Bring in HandL WP when this affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, test a custom block global style change.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references