WordPress 7.0 just dropped a significant update: Pattern Overrides now support custom blocks. For years, we were stuck with a hardcoded list of Core blocks if we wanted to give users the ability to override content within a pattern. If you were building enterprise-grade sites with custom block suites, this limitation was a massive architectural bottleneck.
I’ve seen plenty of “hacks” over the last year—developers trying to trick the editor into treating a custom block like a Core paragraph just to get this functionality. It was messy, it broke often, and it was a nightmare to maintain. Specifically, the shift in WP 7.0 means any block attribute that supports Block Bindings can now participate in the override ecosystem.
How to Enable Pattern Overrides for Custom Blocks
It’s important to understand that this isn’t “on” by default for every block you’ve ever registered. You have to opt-in via a server-side filter. Consequently, you gain full control over which attributes are exposed to the user in the pattern editor.
To register your block, you’ll use the block_bindings_supported_attributes filter. Here is how I typically handle this in a production environment to ensure we aren’t creating race conditions with other plugins:
<?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 );
?>The Underlying Mechanics: Static vs. Dynamic
The way WordPress handles Pattern Overrides depends on how your block is rendered. For dynamic blocks, it’s straightforward: the bound attribute values are passed directly to your render_callback(). However, for static blocks, things get a bit more technical.
WordPress uses the HTML API to find attributes sourced from html, rich-text, or attribute sources in your persisted markup. It then replaces those values on the fly. Furthermore, if you’re using complex selectors that the HTML API doesn’t quite grasp yet, you might still need a render_block filter as a fallback. I’ve had to do this for legacy blocks with deeply nested <div> structures that the current parser struggled to navigate.
If you’re interested in the history of this feature, you might want to check out my previous take on Gutenberg Pattern Overrides from earlier versions.
The “Gotchas” You Need to Watch For
Don’t just add the filter and ship it. I’ve seen attributes fail to render because the block’s save function didn’t perfectly match what the HTML API expected. Specifically, if your attribute isn’t explicitly sourced from the markup, the override might not show up in the frontend. Therefore, always test with WP_DEBUG enabled and verify the block_bindings property in the block’s JSON metadata.
For more technical details, the official WP 7.0 Dev Note covers the edge cases for unsourced attributes in static blocks. If the bound value doesn’t render, that’s your cue to implement a render_callback.
Look, if this Pattern Overrides stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway for Developers
This update effectively completes the “Patterns as a CMS” vision. By allowing custom blocks to play in the same sandbox as Core blocks, we can finally build truly modular layouts without sacrificing the user experience. Just remember: start with the block_bindings_supported_attributes filter and only reach for render_block filters if the HTML API fails you. Refactor your legacy patterns now—your future self will thank you for the cleaner code base.
