#62069 closed defect (bug) (fixed)
Block Bindings: block doesn't receive full __default bindings during render
Reported by: | talldanwp | Owned by: | talldanwp |
---|---|---|---|
Milestone: | 6.7 | Priority: | normal |
Severity: | normal | Version: | 6.6 |
Component: | Editor | Keywords: | has-patch needs-unit-tests |
Focuses: | Cc: |
Description (last modified by )
Original gutenberg issue - https://github.com/WordPress/gutenberg/issues/64688
TLDR - some image block features don't work correctly when the image is using a pattern override due to some missing block bindings code in core.
Longer explanation:
The pattern overrides feature is built upon block bindings, and uses a special __default
binding that means all block attributes that support binding are bound:
bindings: { __default: 'core/pattern-overrides' }
During processing of the bindings, this single __default
binding is replaced with the individual binding attributes - e.g.:
bindings: { src: 'core/pattern-overrides', id: 'core/pattern-overrides', caption: 'core/pattern-overrides', }
In the gutenberg plugin this updated bindings metadata is assigned back to the block before rendering so that the block can reason about which individual attributes are bound:
https://github.com/WordPress/gutenberg/blob/98b8d415830fa9ebf7b4b0a2b95d65b9fd1e813a/lib/compat/wordpress-6.6/blocks.php#L40
This allows blocks like the image block to check whether an individual attribute, like id
, has a binding:
https://github.com/WordPress/gutenberg/blob/98b8d415830fa9ebf7b4b0a2b95d65b9fd1e813a/packages/block-library/src/image/index.php#L31
Unfortunately, WordPress core doesn't have the same logic to assign the updated binding metadata back to the block before rendering, which means the image block's logic fails. The block only receives the individual default binding in its metadata.
Change History (6)
This ticket was mentioned in PR #7394 on WordPress/wordpress-develop by @talldanwp.
3 weeks ago
#1
@talldanwp commented on PR #7394:
3 weeks ago
#3
There are two failing e2e tests, but they also seem to be failing in trunk.
2 weeks ago
#4
That makes perfect sense to update the metadata.bindings
for the __default
special case together with computed values for attributes 👍🏻
@cbravobernal commented on PR #7394:
12 days ago
#6
Committed with https://core.trac.wordpress.org/changeset/59095
Trac ticket: https://core.trac.wordpress.org/ticket/62069
Gutenberg issue: https://github.com/WordPress/gutenberg/issues/64688
## What
Fixes an issue with the image block when using pattern overrides caused by a bug in the block binding logic.
## Why does the bug happen?
The pattern overrides feature is built upon block bindings, and uses a special default binding that means all block attributes that support binding are bound:
During processing of the bindings, this single default binding is replaced with the individual binding attributes - e.g.:
In the gutenberg plugin these individual bindings are assigned back to the block before rendering so that the block can reason about which individual attributes are bound:
https://github.com/WordPress/gutenberg/blob/98b8d415830fa9ebf7b4b0a2b95d65b9fd1e813a/lib/compat/wordpress-6.6/blocks.php#L40
This allows blocks like the image block to check whether an individual attribute, like
id
, has a binding:https://github.com/WordPress/gutenberg/blob/98b8d415830fa9ebf7b4b0a2b95d65b9fd1e813a/packages/block-library/src/image/index.php#L31
Unfortunately core doesn't have the same logic to assign the individual bindings back to the block before rendering, which means the image block's logic fails. Any block that renders just receives the individual
__default
binding.## How has it been fixed?
The fix in this PR is to ensure that the
process_block_bindings
method returns any updates to the block's binding metadata along with other computed attributes.Prior to rendering, the block's attributes are updated with the result of this method (it's where the binding attribute values are updated for a block):
https://github.com/WordPress/wordpress-develop/blob/d8e05446b7d109f8b3c48cbeebf6241d3f6e3946/src/wp-includes/class-wp-block.php#L465-L470
So this will achieve the same result as the code in the Gutenberg plugin.