Review: WordPress 7.0 Block Editor Changes for Pattern Editing, Block Visibility, Custom CSS, Dimensions, and Text Indent

#wordpress #drupal #gutenberg #blockeditor

On March 15, 2026, WordPress core published a set of WordPress 7.0 dev notes covering five block-editor changes that matter more than they first appear: pattern editing defaults, viewport-based block visibility, per-block custom CSS, expanded dimensions support, and native text-indent controls.

None of these are headline platform shifts like the Interactivity API or collaboration work. They are more practical than that. They change what editors can do without custom code, what block authors should opt into or opt out of, and where plugin and theme teams can finally stop carrying custom UI or CSS debt.

Executive take

Change	What core added	Main developer risk
Pattern editing	Unsynced patterns and template parts default more aggressively to content-only editing modes	Custom blocks and editor extensions that assume unrestricted inner-block editing can break or confuse users
Block visibility	Viewport-based show/hide rules for desktop, tablet, and mobile	Teams may mistake presentation rules for access control or forget to test hidden-state UX
Per-block custom CSS	Instance-level CSS in the block inspector, gated by `edit_css`	Wrapper blocks may expose unsafe or misleading styling surfaces unless they opt out
Dimensions support	Width, height, and dimension size presets	Theme.json token drift and inconsistent block support configuration
Text indent	Native `textIndent` typography support	Legacy CSS overrides may conflict with new block support behavior

1) Pattern editing: content-only is now the default assumption

The WordPress 7.0 pattern-editing dev note says unsynced patterns and template parts inserted into the editor now default to content-only editing more broadly. That is a meaningful UX shift, not a cosmetic one.

For developers, the practical implication is simple: if your block expects editors to reach inner blocks, reorder children freely, or use block-level controls inside a pattern, you need to retest those flows under the new editing modes. Core explicitly calls out toolbar controls, sidebar panels, List View visibility, and entity navigation as areas that can behave differently when full block access is not available.

There is an escape hatch if a project is not ready for that model:

add_filter( 'block_editor_settings_all', function( $settings ) {
    $settings['disableContentOnlyForUnsyncedPatterns'] = true;
    return $settings;
} );

That should be a temporary compatibility valve, not the long-term plan. If a pattern only works when editors can punch through every inner block, the pattern may be carrying too much structural responsibility.

2) Block visibility: useful presentation control, not authorization

WordPress 7.0 adds viewport-based block visibility rules. Blocks can now be shown or hidden per device class, and the dev note documents mobile, tablet, and desktop visibility state in block metadata.

This is valuable for editorial teams because it reduces the need for one-off responsive utility classes or duplicate pattern variants. It is also useful for plugin authors shipping curated patterns, because those patterns can carry visibility metadata out of the box.

The migration risk is mostly semantic:

Audit any custom block inspector UI that already offers responsive hide/show behavior.
Check whether your patterns or reusable blocks duplicate visibility logic now provided by core.
Verify List View and editor affordances if your plugin adds custom block actions.

Inference from the source: treat block visibility as presentation logic, not access control. The dev note describes metadata and CSS-driven viewport behavior, not permission or data-protection boundaries. Sensitive content still needs real server-side or capability-based protection.

3) Per-block custom CSS: powerful, but only for blocks that can safely expose it

WordPress 7.0 adds custom CSS for individual block instances in the block inspector. The CSS is stored in style.css, no selector is required, and access is gated by the edit_css capability. Core also notes that the CSS is applied live in the editor and can override both defaults and Global Styles block-type CSS.

This feature will remove a lot of theme and agency workaround code. It also creates a new decision point for block authors: should your block expose instance-level CSS at all?

If the answer is no, core provides the opt-out:

{
  "supports": {
    "customCSS": false
  }
}

Blocks that wrap opaque markup, render fragile structures, or depend on tightly controlled class output should strongly consider disabling it. Otherwise support requests will shift from "how do I style this block?" to "why did my injected CSS break this block?"

4) Dimensions support: WordPress 7.0 finally gives width and height a cleaner model

The dimensions dev note is more important for theme authors than it may look in changelog form. WordPress 7.0 expands dimensions support with block opt-in for width and height controls, plus settings.dimensions.dimensionSizes presets in theme.json.

That means teams can stop relying as heavily on arbitrary values or ad hoc CSS conventions for recurring size choices. A theme can define a controlled size palette once and let blocks consume it consistently.

Example support opt-in:

{
  "supports": {
    "dimensions": {
      "width": true,
      "height": true
    }
  }
}

The migration concern here is governance, not syntax. If a product team has custom spacing, sizing, and layout tokens scattered across block styles, editor CSS, and bespoke controls, WordPress 7.0 is the point where those should be consolidated into theme.json presets instead of extended further.

5) Text indent: one less reason to ship ad hoc typography CSS

WordPress 7.0 adds native textIndent block support, with the Paragraph block as the first core adopter. Core frames this as a long-requested typography capability and explicitly positions it as native support that avoids custom CSS.

For plugin and theme maintainers, the main value is not the feature itself. It is the chance to delete brittle exceptions:

custom editor styles just for first-line indentation
frontend-only CSS that does not round-trip through the editor
block variations created only to simulate indentation options

If your block needs the control, opt in through typography support instead of continuing to maintain a one-off style UI.

Compatibility and migration checklist

Use this before shipping WordPress 7.0 support in a plugin, theme, or agency distribution:

Test all custom patterns with content-only editing enabled, especially patterns containing Buttons, List, Social Icons, Navigation, or custom container blocks.
Review editor extensions that depend on toolbar buttons, sidebar panels, List View, or entity navigation inside patterns.
Remove or deprecate any plugin-provided responsive block visibility UI that core now covers.
Confirm no team is using viewport visibility for content protection; replace that assumption with capability or rendering controls where needed.
Decide block-by-block whether instance custom CSS should be allowed. Add "customCSS": false where it should not.
Retest wrapper and dynamic blocks whose root classes or markup can be destabilized by injected per-instance CSS.
Define shared dimension size presets in theme.json instead of letting width and height become another arbitrary-value sprawl point.
Audit legacy CSS for paragraph indentation and replace it with textIndent support where appropriate.
Run editor smoke tests on both existing production content and new content creation flows, because these changes affect authoring behavior as much as rendering.

Why this matters for Drupal and WordPress teams

WordPress teams should see these changes as a small but real reduction in custom-code surface area. The more of your editorial behavior lives in core-supported block supports and theme.json settings, the less upgrade debt you carry.

Drupal teams should pay attention too, especially agencies maintaining both stacks. The pattern-editing and visibility changes echo a familiar lesson from Drupal: editorial constraints and display rules are safer when they are modeled as first-class configuration, not layered on later with fragile UI hacks. The migration discipline is the same in both ecosystems: remove custom behavior where core now covers the use case, and retest any extension that assumed deeper editor access than the platform still guarantees.

Sources

Looking for an Architect who doesn't just write code, but builds the AI systems that multiply your team's output? View my enterprise CMS case studies at victorjimenezdev.github.io or connect with me on LinkedIn.

Originally published at VictorStack AI — Drupal & WordPress Reference