WordPress 7.0 reshapes how patterns and template parts are edited, bringing significant changes for developers, theme authors, and site admins. The introduction of expanded contentOnly mode impacts unsynced patterns and default editing behaviors, demanding attention across the ecosystem.
The centerpiece of this update is the enhanced focus on contentOnly mode for unsynced patterns and template parts. By default, these components prioritize the editing of text and media while shielding users from deeper block structures and style controls. For synced patterns, changes are made globally via an isolated editor, enabling precise design modifications without impacting the originating document.
A New Approach to Pattern Editing
WordPress 7.0 introduces specific mechanisms for editing unsynced and synced patterns. Unsynced patterns now allow users to engage a spotlight mode by either double-clicking the body of the pattern or selecting the ‘Edit pattern’ button. This mode unlocks full editing capabilities, giving users granular control over design changes.
In contrast, synced patterns offer an ‘Edit original’ button that transports users to an isolated editor. Here, modifications apply globally, streamlining workflows for teams managing reusable design components across multiple pages.
Implications for Block Developers
Block authors must adapt their blocks to align with the expanded contentOnly behavior. If a block should be editable inside a contentOnly pattern, its attributes must include "role": "content" in its block.json. Blocks lacking this role are hidden from List View and become non-selectable within contentOnly containers.
For blocks without suitable attributes, WordPress 7.0 introduces contentRole. Developers can add "contentRole": true to the block supports declaration, achieving the same effect as "role": "content". Parent-child blocks, like List and Gallery, benefit from this expanded behavior, allowing seamless insertion of child blocks when both parent and child include "role": "content".
List View Enhancements
Block developers can now leverage a new "listView": true block supports declaration, enabling a dedicated List View UI. This addition simplifies the management of container blocks, such as rearranging or inserting child blocks. List View is also visible in patterns, making it an essential feature for blocks serving as containers.
What Theme Authors Should Know
Theme and pattern authors face new considerations with the default application of contentOnly mode. Patterns reliant on unrestricted editing must be tested to ensure user accessibility aligns with the intended design. Blocks like Buttons, Lists, and Navigation require extra scrutiny due to targeted contentOnly improvements.
Authors should audit patterns for compatibility and use the ‘Manage allowed blocks’ feature to restrict insertion where necessary. Code-based adjustments can also enforce such restrictions via the "allowedBlocks": [] attribute.
Site Admin Options
Administrators gain new control over pattern behaviors with the disableContentOnlyForUnsyncedPatterns setting. This setting, configurable via PHP or JavaScript, allows opting out of contentOnly mode for unsynced patterns. When activated, blocks with patternName metadata are restored to full editing behavior, while synced patterns remain unaffected.
For PHP implementation, admins can use:
add_filter( 'block_editor_settings_all', function( $settings ) {
$settings['disableContentOnlyForUnsyncedPatterns'] = true;
return $settings;
});Or via JavaScript:
wp.data.dispatch( 'core/block-editor' ).updateSettings({
disableContentOnlyForUnsyncedPatterns: true,
});What To Do
- Block Developers: Update
block.jsonfiles to include"role": "content"for editable blocks. Use"contentRole": truefor blocks without content attributes. Implement"listView": truefor container blocks. - Theme Authors: Audit existing patterns for compatibility with contentOnly mode. Restrict block insertion where appropriate using code or editor settings.
- Site Admins: Configure
disableContentOnlyForUnsyncedPatternsto opt out of default contentOnly behavior where necessary. - Plugin Developers: Test plugin functionality against the expanded contentOnly state to ensure UI components render correctly.
