When a text shadow appears in the editor but not on the public page, compare the saved preset class and generated CSS before adding another shadow declaration. When the control itself is missing, start with block support and the Typography panel options.
What changed
Gutenberg pull request 79584 adds full text-shadow support, including supports.typography.textShadow, theme-defined presets and a control that is hidden by default. The proposed serialization uses preset classes, with variables named --wp--preset--text-shadow--{slug}. Paragraph and Heading are included in the change. Confirm that the build you are testing contains this feature before diagnosing an older runtime as broken.
Trace one heading through four layers
Use a staging heading with ordinary text and no existing custom class. Keep another heading untouched as a comparison. Record the original theme configuration before editing it.
- Support: verify the block type opts into the feature in the version you run. A custom block does not inherit every control from Paragraph.
- Settings: inspect the effective typography settings and preset list. A theme can intentionally restrict available tools.
- Saved content: choose one preset, save and reopen. Record the actual stored attribute and rendered class.
- CSS: locate the matching rule and custom property on the anonymous frontend. Inspect computed text-shadow, not just the presence of a stylesheet.
Plain text: No unexpected effect. Preset text: Computed shadow is correct. Theme variation: Text remains legible. Rollback: Restore settings and styles. Explanatory checklist, not a customer test result.
Separate the common failures
If the control appears after enabling it in the panel menu, there may be no code defect. If a preset disappears after save, check whether the editor and server agree on supported settings. If its class persists but the variable is absent, inspect generated Global Styles and the active theme. If the variable exists but the computed value is different, inspect the winning CSS declaration.
Avoid using a general h1, h2, p rule to mask the problem. It can add shadows to legal text, checkout instructions and other content that was never selected for the effect. Also avoid renaming preset slugs merely to change their labels: saved posts may depend on those identifiers.
A small release worksheet
| Fixture |
What should survive |
| Heading with selected preset |
Selection after save and reopen |
| Plain paragraph |
No unrequested shadow |
| Existing post using an older preset |
Compatible saved reference |
| Narrow phone view |
Readable text without clipping |
| Alternate style variation |
Legible contrast and intentional effect |
Do not treat a shadow as a substitute for readable text color against its background. Check the actual design with the effect removed as well as enabled. For related viewport inheritance issues, follow responsive block styles and theme settings.
Ship only the necessary change
Keep the theme configuration diff and a screenshot of the computed rule with the release record. Clear affected generated styles and page caches using the site's normal workflow, then compare an anonymous page. If rollback is necessary, restore the configuration as well as the stylesheet so the editor does not keep offering a preset that the frontend cannot render.
Get a focused WordPress styling repair with your theme name, build numbers and one failing heading.
Source: text-shadow support implementation and tests. This worksheet is a recommended validation procedure, not a claim that the feature is present on all WordPress releases.
References reviewed October 17, 2026. Examples are explanatory, not customer test results.