If WordPress columns have different gaps in the editor and on the live page, compare the theme's block-spacing support before adding more CSS. A missing setting is not equivalent to an explicit false value. Also check the block's own fallback spacing and the rule actually applied in each context.
This guide covers block themes and the Gutenberg editor, not Avada or Elementor spacing controls. It is especially useful when content looks correct publicly but editors keep adjusting it to compensate for an inaccurate preview.
Start with a controlled page
Create a draft on staging with a three-column Columns block and a Query Loop containing a Post Template. Use short labels and plain backgrounds so you can distinguish space between blocks from padding inside them. Match the editor canvas width to the public page as closely as possible.
Record the WordPress version, Gutenberg plugin version if active, parent and child theme versions, and whether the issue appears in the post editor, Site Editor or both. Do not install a development editor on production merely to test a spacing change.
The Gutenberg block-gap fix addresses an editor fallback mismatch in themes that do not opt into block-gap support. It was merged in September 2026. A merged fix is not proof that the exact editor build running on your site contains it.
Separate support from a spacing value
Read the effective theme configuration, including the parent theme and customizations. Search for both appearanceTools and settings.spacing.blockGap. Then inspect styles.spacing.blockGap and any block-specific value.
These fields answer different questions. Settings control availability and generated styles; styles specify a desired distance. An enabled collection of appearance tools can affect the effective setting even if you do not see a standalone blockGap entry in one file.
The WordPress spacing reference distinguishes these states:
| Setting |
Editor spacing control |
Generated block-gap styling |
| true |
Available for supported blocks |
Enabled |
| false |
Hidden |
Can still be generated |
| null or missing default |
Hidden |
Not enabled through this setting |
Do not flatten all three cases into a generic enabled/disabled test. The recent fix concerns missing or null support and fallback behavior. It does not mean false erases every stored spacing style.
Inspect the winning CSS twice
On the live test page, select the container that actually owns the layout. Record its layout class, computed row-gap and column-gap, child margins, font size and the stylesheet supplying the winning declaration. Repeat in the editor's canvas document.
For a flow layout, the visible separation may come from a margin rather than CSS gap. For an em-based fallback, a different font size can produce different pixel distances even when the declared value matches. A screenshot alone cannot distinguish those cases.
Use this evidence worksheet:
| Observation |
Investigate next |
| Same declared gap, different pixels |
Font size, zoom and container context |
| Public fallback exists, editor substitutes a global value |
Effective support settings and editor build |
| Same rules until custom CSS loads |
Specificity or stylesheet ordering |
| Only one existing block differs |
Saved block-level spacing |
| All spacing appears larger |
Canvas width, typography and layout context |
Setting: Distinguish true, false and null. Layout: Measure gap or child margin. Context: Compare fonts and canvas width. Override: Retest saved block spacing. Proposed verification, not a customer test result.
Choose the smallest repair
If the theme intends to support adjustable spacing, explicitly configure that support and its design values in the theme's normal source. If it deliberately relies on block fallbacks, preserve that design and test an editor build containing the relevant fix on staging.
Do not add a sitewide Columns gap override simply to make one preview look similar. It can overwrite author choices, collapse responsive spacing and conceal the original mismatch. Likewise, do not delete saved Global Styles as a diagnostic shortcut.
Use the broader block-theme regression checklist when more than spacing changed. For a bounded implementation repair, HandL WP can trace the theme and generated CSS.
Acceptance checks
Save and reopen the test page. Verify the intended spacing in both editors and a logged-out public view, at desktop and phone widths. Repeat with one untouched block and one block that has an explicit spacing override. Check that color padding and link focus are still usable.
Keep the before/after configuration diff and computed-style notes. The fix is complete when the intended design matches across contexts, not merely when a new CSS rule makes one screenshot look right.
References reviewed October 19, 2026. Diagrams and test fixtures are explanatory, not customer results.