You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Docs: Document block_bindings_supported_attributes filter and pattern overrides in dynamic blocks
Adds comprehensive documentation for:
– The block_bindings_supported_attributes filter for extending supported block attributes
– The block_bindings_supported_attributes_{$block_type} dynamic filter with examples
– How to access pattern override values in a dynamic block’s render_callback
– Step-by-step guide with complete code examples for implementing pattern overrides in custom blocks
Copy file name to clipboardExpand all lines: docs/reference-guides/block-api/block-bindings.md
+112–1Lines changed: 112 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,7 +23,7 @@ An example could be connecting an Image block `url` attribute to a function that
23
23
24
24
## Compatible blocks and their attributes
25
25
26
-
Right now, not all block attributes are compatible with block bindings. There is some ongoing effort to increase this compatibility, but for now, this is the list:
26
+
Right now, not all block attributes are compatible with block bindings. There is some ongoing effort to increase this compatibility, but for now, this is the default list:
27
27
28
28
| Supported Blocks | Supported Attributes |
29
29
| ---------------- | -------------------- |
@@ -32,6 +32,117 @@ Right now, not all block attributes are compatible with block bindings. There is
32
32
| Image | id, url, title, alt |
33
33
| Button | text, url, linkTarget, rel |
34
34
35
+
### Extending supported attributes
36
+
37
+
_**Note:** Since WordPress 6.9._
38
+
39
+
Developers can extend the list of supported attributes using the `block_bindings_supported_attributes` filter. This filter allows adding support for additional block attributes.
40
+
41
+
There are two filters available:
42
+
43
+
-`block_bindings_supported_attributes`: A general filter that receives the supported attributes array and the block type name.
44
+
-`block_bindings_supported_attributes_{$block_type}`: A dynamic filter specific to a block type (e.g., `block_bindings_supported_attributes_core/image`).
45
+
46
+
Example of adding support for the `caption` attribute on the Image block:
This filter also affects which blocks and attributes are available for Pattern Overrides, as both features share the same underlying supported attributes configuration.
72
+
73
+
### Accessing Pattern Override values in dynamic blocks
74
+
75
+
When creating a dynamic block that supports Pattern Overrides, you can access the override values within your `render_callback` function. The Pattern block (`core/block`) provides override values to nested blocks via the `pattern/overrides` context.
76
+
77
+
**Step 1: Register your block with the required context and supported attributes**
78
+
79
+
```php
80
+
add_action( 'init', function() {
81
+
// Register supported attributes for pattern overrides
// Declare that you need the pattern/overrides context
98
+
'uses_context' => array( 'pattern/overrides' ),
99
+
'render_callback' => 'my_block_render_callback',
100
+
) );
101
+
} );
102
+
```
103
+
104
+
**Step 2: Access override values in your render callback**
105
+
106
+
The override values are stored in `$block->context['pattern/overrides']` as an associative array. The keys are block metadata names (assigned when enabling overrides), and the values are arrays of attribute overrides.
107
+
108
+
```php
109
+
function my_block_render_callback( $attributes, $content, $block ) {
110
+
// Get the block's metadata name (set when enabling overrides)
-**`uses_context`**: Your block must declare `pattern/overrides` in its `uses_context` to receive override data from parent Pattern blocks.
142
+
-**Block metadata name**: Each overridable block instance has a unique name stored in `$attributes['metadata']['name']`. This name is assigned when the user enables overrides on the block in the editor.
143
+
-**Empty string convention**: An empty string (`""`) in the overrides represents a reset to the default value. Your code should handle this appropriately.
144
+
-**Fallback behavior**: Always provide fallback values from `$attributes` in case the block is not inside a pattern or overrides are not set.
145
+
35
146
## Registering a custom source
36
147
37
148
Registering a source requires defining at least `name`, a `label` and a `callback` function that gets a value from the source and passes it back to a block attribute.
0 commit comments