WordPress 7.0 Pattern Editing changes what your clients are allowed to touch in the editor. The part that matters is the expansion of contentOnly editing to unsynced patterns and template parts. If you build custom themes or blocks, this one reaches your support inbox before it reaches your release notes.
contentOnly used to be opt-in. In WordPress 7.0 unsynced patterns arrive in that mode already, so a user gets text and media and nothing else, with the block structure and the style controls tucked behind Spotlight mode. The intent is clear enough: keep layouts safe from the creative client edit that quietly takes a landing page apart.
Why the WordPress 7.0 pattern editing defaults matter
I handed over a site once where the client accidentally deleted a nested container inside a complex pattern, and the whole landing page went with it. Locking the structure prevents that. It also means that if your block attributes are not declared properly, the client can edit nothing at all, which is a different support ticket in the same tone of voice.
Updating your block.json
A custom block nested inside one of these patterns needs a role on its attributes. Leave out the "role": "content" declaration and the block goes invisible in the contentOnly view, with nothing in the UI to explain why. Worth an audit pass over your block.json files now instead of after the update.
{
"attributes": {
"url": {
"type": "string",
"role": "content"
},
"text": {
"type": "string",
"role": "content"
}
}
}Some blocks have no single content attribute and still need to be selectable. Those use the contentRole support property instead, which covers container blocks that hold no raw data of their own.
{
"supports": {
"contentOnly": true
}
}New listView support for complex containers
The listView block support is the part of WordPress 7.0 Pattern Editing I am happiest about. Managing child blocks in contentOnly mode was awkward on anything shaped like a slider or a features grid. Adding "listView": true gives you a dedicated UI for reordering and adding inner blocks without leaving the restricted context.
My write-up of the other WordPress 7.0 features covers where this sits in the rest of the release.
Turning contentOnly back off
Sometimes you want the old behaviour back, usually for one admin who knows exactly what they are doing. The block_editor_settings_all filter switches it off globally. Use that sparingly, because it hands the delete button back to everyone else on the site as well.
<?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;
}
If auditing patterns and block.json files is eating your week, I take that work on for clients. I have been building WordPress sites since the 4.x days.
What to do before 7.0 lands
The direction of travel is a more managed editing experience. Fewer broken layouts, and more work for anyone who has been loose with block.json. Test your patterns against Spotlight mode before the update reaches production, and read the official WordPress dev note for the implementation detail.
