If you build block themes, you know how this goes. You check a reference table, see a checkmark, assume the block supports what you need, then hit a wall. The WordPress 7.0 design tools roster is the core team admitting that a yes or no column stopped being enough. Hardcoded feature sets are on the way out, replaced by a dynamic filter based architecture that makes my life easier, and yours, as long as you know where to hook in.
On a project last year I had to hack pattern overrides into a custom block, and it ended up a mess of race conditions and transient data that never quite behaved. The WordPress 7.0 developer updates summarize what changed since: the same mechanism that powers Block Bindings now covers Pattern Overrides. Cleaner, but it does mean the old lookup tables are shifting under us.
The major shifts in WordPress 7.0
This release renames a block and expands the library. The Verse block is now the Poetry block. Past the naming, 7.0 adds Accordion with its sub-blocks, Breadcrumbs and a dedicated Math block to core, and each one ships with full design support instead of being a thin wrapper.
The block_bindings_supported_attributes filter is the source of truth now. Pattern Overrides and Block Bindings used to sit in a hardcoded column covering Button, Image, Paragraph and Heading. That column is gone in 7.0. Support is opt-in per block and per attribute, which helps a lot if you write custom blocks.
WordPress 7.0 design tools: the core block roster
Below is the cumulative list of design supports across the core block library. It covers what changed between 6.1 and 7.0, with the most recent cycles marked. Start here when you are debugging why a sidebar panel is not showing up for your users.
Moving to dynamic attributes
To find the WordPress 7.0 design tools logic in the source, look at how attributes get registered. If you write custom blocks, you can no longer assume core handles the binding for you. You have to tell WordPress which attributes are bindable.
Here is a snippet that registers support for a custom attribute the 7.0 way:
<?php
/**
* Opting into Block Bindings and Pattern Overrides for custom blocks.
*/
function bbioon_register_block_binding_supports( $supported_attributes, $block_type ) {
if ( 'my-agency/custom-block' === $block_type->name ) {
$supported_attributes[] = 'customContent';
$supported_attributes[] = 'buttonText';
}
return $supported_attributes;
}
add_filter( 'block_bindings_supported_attributes', 'bbioon_register_block_binding_supports', 10, 2 );
?>The official dev notes on Pattern Overrides show how the mechanism scales. It is a clean break from the legacy model, where you enabled these features by hand.
If the WordPress 7.0 design tools shift is eating your dev hours, hand it to me. I have been wrestling with WordPress since the 4.x days, and I have watched API changes like this break more sites than I can count. A “simple” core update should not cost you a weekend of chasing CSS regressions.
What to do with this as a developer
Read the roster as a roadmap. Blocks like Post Time to Read and Term Template push WordPress further toward a full design system, so lean on the core supports rather than fighting the editor. When a block does not support the property you need, extend it with the RTC pivots and hooks covered in the earlier notes.
