fix(patterns): bands write the padding style WordPress rebuilds #136

Merged
peterswimm merged 1 commit from fix/pattern-group-padding-style into main 2026-09-14 18:32:57 +00:00
Owner

Opening a page in the Site Editor offered "Attempt Block Recovery" in place of the page. Every generated band declared style.spacing.padding in its block attributes and wrote none of it into the markup. WordPress rebuilds a block's markup from its attributes and compares the two, so all five generated pages carried an invalid wrapper.

It is not only an editor warning. core/group is a static block, so the saved markup is what renders:

live <main> today
/rituals/, /spelwork/, /contact/, landing class="wp-block-group alignfull …" — no padding
/news/ … style="padding-top:var(--wp--preset--spacing--lg);padding-bottom:…"

News differs because someone hit this in September, recovered the block and saved, which is what left the page-news override (post 1085) in the database — it now shadows the theme's own template.

_group_wrap was missing alignfull too — the class the align support puts on saved markup — so the brand previews carried the same fault.

Scope

  • forgeblock_pattern.py: both group emitters derive the inline style from the padding they declare, via _padding_style / _preset_css, so the attributes and the markup cannot drift apart again. _group_wrap also emits alignfull.
  • Regenerated every surface (build_surfaces.py build): the 5 theme patterns and all 6 brands' previews.
  • Removed udg/products/fux-capacity/wp-preview/patterns/fux-landing.php, a stale artifact from the old naming scheme that landing.php replaced. Nothing references it and its wrapper was invalid too.
  • New test_generated_block_markup.py reads every generated pattern back: a declared padding must reach the markup, and align:full must carry its class.

Not in scope, found while diagnosing:

  • The ~60 patterns inherited from the third-party theme hold 19 invalid core/cover blocks and 28 blocks needing the Getwid plugins. They sit in the inserter.
  • theme_builder.py (reachable only from cli.py, not from this build path) emits header/footer groups with no wrapper tag at all — the same class of fault.

Testing

  • 322 tests pass (tools/wp_theme_ingestor/, generator/tests/).
  • The new test was mutation-checked: putting the bug back makes it fail with the offending file and style named.
  • Validated with Gutenberg's own validator — @wordpress/blocks + registerCoreBlocks, with every toilville/* block registered from its real block.json. The theme's patterns, templates and parts, and all six brands' previews, now report zero invalid blocks. Before the fix it reported exactly the 5 wrappers.
  • build_surfaces.py check, forgeblock_validate.py check and the pre-commit gates are clean.

Impact Statement

Restores band padding on the landing, rituals, spelwork and contact pages — they gain the top and bottom spacing|lg the design intends and News already has, so expect a visible spacing change on deploy. No copy, colour or structure changes. The editor stops offering block recovery on these pages.

After deploy, the stale page-news override (post 1085) should be deleted so News renders from the theme file again like its siblings; until then, theme-side changes to that page stay invisible.

Opening a page in the Site Editor offered "Attempt Block Recovery" in place of the page. Every generated band declared `style.spacing.padding` in its block attributes and wrote none of it into the markup. WordPress rebuilds a block's markup from its attributes and compares the two, so all five generated pages carried an invalid wrapper. It is not only an editor warning. `core/group` is a static block, so the saved markup is what renders: | | live `<main>` today | |---|---| | `/rituals/`, `/spelwork/`, `/contact/`, landing | `class="wp-block-group alignfull …"` — **no padding** | | `/news/` | `… style="padding-top:var(--wp--preset--spacing--lg);padding-bottom:…"` | News differs because someone hit this in September, recovered the block and saved, which is what left the `page-news` override (post 1085) in the database — it now shadows the theme's own template. `_group_wrap` was missing `alignfull` too — the class the align support puts on saved markup — so the brand previews carried the same fault. ## Scope - `forgeblock_pattern.py`: both group emitters derive the inline style from the padding they declare, via `_padding_style` / `_preset_css`, so the attributes and the markup cannot drift apart again. `_group_wrap` also emits `alignfull`. - Regenerated every surface (`build_surfaces.py build`): the 5 theme patterns and all 6 brands' previews. - Removed `udg/products/fux-capacity/wp-preview/patterns/fux-landing.php`, a stale artifact from the old naming scheme that `landing.php` replaced. Nothing references it and its wrapper was invalid too. - New `test_generated_block_markup.py` reads every generated pattern back: a declared padding must reach the markup, and `align:full` must carry its class. Not in scope, found while diagnosing: - The ~60 patterns inherited from the third-party theme hold 19 invalid `core/cover` blocks and 28 blocks needing the Getwid plugins. They sit in the inserter. - `theme_builder.py` (reachable only from `cli.py`, not from this build path) emits header/footer groups with no wrapper tag at all — the same class of fault. ## Testing - 322 tests pass (`tools/wp_theme_ingestor/`, `generator/tests/`). - The new test was mutation-checked: putting the bug back makes it fail with the offending file and style named. - Validated with Gutenberg's own validator — `@wordpress/blocks` + `registerCoreBlocks`, with every `toilville/*` block registered from its real `block.json`. The theme's patterns, templates and parts, and all six brands' previews, now report zero invalid blocks. Before the fix it reported exactly the 5 wrappers. - `build_surfaces.py check`, `forgeblock_validate.py check` and the pre-commit gates are clean. ## Impact Statement Restores band padding on the landing, rituals, spelwork and contact pages — they gain the top and bottom `spacing|lg` the design intends and News already has, so expect a visible spacing change on deploy. No copy, colour or structure changes. The editor stops offering block recovery on these pages. After deploy, the stale `page-news` override (post 1085) should be deleted so News renders from the theme file again like its siblings; until then, theme-side changes to that page stay invisible.
fix(patterns): bands write the padding style WordPress rebuilds
Some checks failed
PR policy check / policy-gate (pull_request) Successful in 1s
Security Scans / Gitleaks secret scan (pull_request) Successful in 25s
Security Scans / Trivy filesystem scan (pull_request) Successful in 30s
Test Generator / test (pull_request) Failing after 23s
Test Generator / lint-workflows (pull_request) Successful in 23s
Copy coverage / Design copy reaching rendered HTML (pull_request) Failing after 21s
UDG dist drift gate / dist/ matches dtcg + udg sources (pull_request) Successful in 13s
Test Generator / lint-prose (pull_request) Successful in 39s
17d6eb8112
Every generated band declared `style.spacing.padding` in its block
attributes and wrote none of it into the markup. WordPress rebuilds a
block's markup from its attributes and compares, so all five pages had an
invalid wrapper: opening one in the Site Editor offered "Attempt Block
Recovery" in place of the page. Recovering and saving is what left the
`page-news` template override in the database, which now shadows the
theme's own file.

`_group_wrap` was missing `alignfull` as well — the class the align
support puts on the saved markup — so the brand previews carried the same
fault.

Both emitters now derive the inline style from the padding they declare,
and a test reads every generated pattern back: a declared padding has to
reach the markup, and align:full has to carry its class.

Also drops udg/products/fux-capacity/wp-preview/patterns/fux-landing.php,
a stale artifact from the old naming scheme that landing.php replaced;
nothing references it and its wrapper was invalid too.
peterswimm deleted branch fix/pattern-group-padding-style 2026-09-14 18:32:57 +00:00
Sign in to join this conversation.
No description provided.