WordPress 7.0 opens Pattern Overrides up to custom blocks. Until now there was a hardcoded list of Core blocks, and if you wanted users to edit content inside a pattern, your block had to be on that list. Anyone shipping a suite of custom blocks on a large site has been working around that for years.
I have watched people try some ugly workarounds over the past year, mostly variations on tricking the editor into treating a custom block as a Core paragraph. They broke on every other release and nobody wanted to maintain them. In WP 7.0, any block attribute that supports Block Bindings can be overridden.
How to enable pattern overrides for custom blocks
This is not on by default for every block you have ever registered. You opt in through a server-side filter, which also means you decide exactly which attributes the pattern editor exposes.
The filter is block_bindings_supported_attributes. This is the shape I use in production, scoped to one block type so it does not collide with whatever else is hooked in:
<?php
/**
* Opt-in custom block attributes to Pattern Overrides.
*/
function bbioon_register_custom_block_overrides( $supported_attributes, $block_type ) {
if ( 'my-agency/custom-hero' === $block_type->name ) {
$supported_attributes[] = 'title';
$supported_attributes[] = 'buttonText';
}
return $supported_attributes;
}
add_filter( 'block_bindings_supported_attributes', 'bbioon_register_custom_block_overrides', 10, 2 );
?>What happens underneath: static vs. dynamic
How WordPress applies Pattern Overrides depends on how the block renders. Dynamic blocks are the easy case: the bound attribute values arrive in your render_callback(). Static blocks take more work.
For those, WordPress uses the HTML API to locate attributes sourced from html, rich-text or attribute in your persisted markup, then swaps the values in on render. If your selectors are more complex than the HTML API can follow, you still need a render_block filter as a fallback. I have had to do that for legacy blocks with deeply nested <div> structures the parser could not walk.
For where this feature came from, I covered Gutenberg Pattern Overrides back when it landed in earlier versions.
The gotchas worth watching for
Adding the filter is not the whole job. I have seen attributes quietly fail to render because the block’s save function did not produce markup the HTML API expected. If the attribute is not explicitly sourced from that markup, the override may never reach the front end. Test with WP_DEBUG on and check the block_bindings property in the block’s JSON metadata.
The official WP 7.0 dev note goes through the edge cases for unsourced attributes in static blocks. When a bound value refuses to render, that is your cue to move the block to a render_callback.
If this kind of work is eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days.
Final takeaway for developers
This is the piece the “patterns as a CMS” idea was missing. Custom blocks now play in the same sandbox as Core blocks, so modular layouts no longer cost the client their editing experience. Start with the block_bindings_supported_attributes filter, and only reach for a render_block filter when the HTML API lets you down. If you have legacy patterns carrying old workarounds, this is a good moment to strip them out.
