WordPress 7.0 expands contentOnly editing to unsynced patterns and template parts.
The key behavioral change is that unsynced patterns and template parts inserted into the editor now default to contentOnly mode, prioritizing the editing of text and media without exposing the deeper block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. structure or style controls.
Pattern-level editing modes
At times a user will want to make design changes to a pattern, and this works differently depending on the type of pattern.
- Unsynced — A user can click an ‘Edit pattern’ button or double click the body of a pattern, and a spotlight mode engages. In this mode users have full editing capabilities A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the
current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability)..
- Synced (synced patterns / template parts) — Users can click the ‘Edit original’ button and are taken into an isolated editor when they can make any changes to the underlying pattern. The editor header The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. provides navigation back to the originating document. Changes to synced patterns apply globally.
What developers need to do
Block authors
If your block is nested in a contentOnly pattern and should be editable, ensure attributes that represent a block’s content have "role": "content" set in block.json. This is unchanged from WordPress 6.7, but is now more important as contentOnly mode is applied more broadly by default.
{
"attributes": {
"url": {
"type": "string",
"role": "content"
},
"label": {
"type": "string",
"role": "content"
}
}
}
Blocks without any "role": "content" attributes will be hidden from List View and non-selectable inside a contentOnly container.
At times a block may not have an appropriate attribute to which to apply "role": "content". A "contentRole": true property can be added to the block supports declaration, and this has the same effect as "role": "content".
{
"supports": {
"contentRole": true
}
}
Developers should prefer "role": "content" where possible.
Parent / child contentOnly blocks
Many blocks are considered ‘content’, but consist of both parent and child block types. Some examples of Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks are:
- List and List Item
- Gallery and Image
- Buttons and Button
Whenever both a parent and child block have a "role": "content" attribute or "contentRole": true block supports, contentOnly mode allows insertion of child blocks. This behavior has been present since WordPress 6.9, but is now more prominent.
Block developers can take advantage of this behavior.
List View block support
New for WordPress 7.0, block developers can add a "listView": true block supports declaration. This adds a List View tab to the block inspector with a dedicated List View UI User interface for the block that allows users to easily rearrange and add inner blocks. This List View is also displayed in Patterns and is recommended for any block that acts as a container for a list of child blocks.
{
"supports": {
"listView": true
}
}
Theme / pattern authors
Patterns that previously relied on unrestricted editing of their inner blocks will now be presented to users in contentOnly mode by default. Review your registered patterns and consider:
- Testing that the content users are expected to change is accessible in
contentOnly mode.
- Auditing patterns containing Buttons, List, Social Icons, and Navigation blocks specifically — these have had targeted
contentOnly improvements and may behave differently than before.
- Restrict the allowed blocks if users shouldn’t be able to insert blocks in a specific area of a pattern. If assembling a pattern in a block editor, this can be done using the ‘Manage allowed blocks’ feature in the Advanced section of the block inspector for any blocks that have
"allowedBlocks": true block support. Through code, the "allowedBlocks":[] attribute can be added to prevent insertion of inner blocks.
Site admins
A new block editor setting, disableContentOnlyForUnsyncedPatterns, allows opting out of contentOnly mode for unsynced patterns. Via PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher, use the block_editor_settings_all filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.:
add_filter( 'block_editor_settings_all', function( $settings ) {
$settings['disableContentOnlyForUnsyncedPatterns'] = true;
return $settings;
} );
Or via JavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser.
https://www.javascript.com:
wp.data.dispatch( 'core/block-editor' ).updateSettings( {
disableContentOnlyForUnsyncedPatterns: true,
} );
When disableContentOnlyForUnsyncedPatterns is true, blocks with patternName metadata are no longer treated as section blocks and their children are not placed into contentOnly editing mode. Template parts and synced patterns (core/block) are unaffected — they remain section blocks regardless of this setting.
Plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. developers
If your plugin interacts with pattern editing state — toolbar controls, sidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. panels, List View visibility, or entity navigation — test against the new editing modes. The contentOnly state is now applied more broadly, and UI components that assume full block access inside patterns may not render as expected.
Props to @talldanwp and @andrewserong for helping to write this dev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..
References
#7-0, #dev-notes, #dev-notes-7-0
