WordPress 7.0 Pattern Editing has just introduced a fundamental shift in how your clients interact with the editor. Specifically, the expansion of contentOnly editing to unsynced patterns and template parts is the headline change. If you have been building custom themes or blocks, you need to pay attention, or your support inbox is about to get very loud.
In previous versions, contentOnly was an opt-in feature. However, in WordPress 7.0, unsynced patterns now default to this mode. This means users are restricted to editing text and media by default, while the underlying block structure and style controls are hidden behind a “Spotlight” mode. Furthermore, this update aims to protect site layouts from “creative” client edits that inevitably break the design.
Why WordPress 7.0 Pattern Editing Defaults Matter
As a developer, the “war story” here is simple. I once handed over a site where the client “accidentally” deleted a nested container inside a complex pattern. Consequently, the entire landing page collapsed. WordPress 7.0 tries to prevent this by locking the structure. But if you haven’t defined your block attributes correctly, your users won’t be able to edit anything at all.
Updating your block.json
If your custom block is nested inside one of these patterns, you must ensure that your attributes have a defined role. Without the "role": "content" declaration, your block will simply be invisible in the contentOnly view. Therefore, you should audit your block.json files immediately.
{
"attributes": {
"url": {
"type": "string",
"role": "content"
},
"text": {
"type": "string",
"role": "content"
}
}
}Alternatively, if your block doesn’t have a single “content” attribute but still needs to be selectable, you can use the contentRole support property. This is a handy workaround for container blocks that don’t hold raw data themselves.
{
"supports": {
"contentOnly": true
}
}New ListView Support for Complex Containers
One of the best additions in WordPress 7.0 Pattern Editing is the listView block support. For instance, if you are building a “Slider” or a “Features Grid,” managing child blocks in contentOnly mode used to be a nightmare. Now, adding "listView": true provides a dedicated UI for rearranging and adding inner blocks without leaving the restricted editing context.
For more context on how this fits into the broader roadmap, check out my deep dive on WordPress 7.0 Features.
The Escape Hatch: Disabling contentOnly
Sometimes, you just want the old behavior back. Specifically, site admins might want to disable this “training wheels” mode for power users. You can do this globally via the block_editor_settings_all filter. Specifically, you should use this sparingly as it re-exposes the “delete” button to people who might not know how to use it.
<?php
/**
* Disables the default content-only mode for unsynced patterns in WP 7.0
*/
add_filter( 'block_editor_settings_all', 'bbioon_disable_pattern_lock', 10, 1 );
function bbioon_disable_pattern_lock( $settings ) {
$settings['disableContentOnlyForUnsyncedPatterns'] = true;
return $settings;
}
Look, if this WordPress 7.0 Pattern Editing stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Technical Takeaway
WordPress 7.0 is moving toward a more “managed” editing experience. While this reduces layout breakages, it increases the technical debt for developers who ignore block.json standards. Specifically, you should test your patterns against the new Spotlight mode before the update hits your production servers. For official implementation details, refer to the Official WordPress Dev Note.
