Block bindings: Ensure the block receives the fully expanded __default bindings when rendering

[talldan]

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:

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 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.

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.

Steps for reproduction

1. Add an image block to a new post and add an image to the block
2. Preview the post and inspect the image, make a note of the image's id in the classname attribute (e.g. wp-image-123)
3. Back in the editor, click on the image block, go to settings, and Create Pattern (make it a synced pattern)
4. Edit the pattern by clicking 'Edit original'
5. Click the image block and go to Advanced > Enable Overrides
6. Enter a name for the block and enable the override
7. Save Pattern and return to post
8. Click on the image block in the pattern and replace with a new image
9. Save page and view on front-end
10. Inspect the image and check that the id in the classname was updated to the new image's id
11. Check that the image has html additional attributes like fetchpriority (which are missing in trunk)

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions[bot]]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props talldanwp, cbravobernal, santosguillamot, mukesh27, gziolo.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions[bot]]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance, it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[talldan]

There are two failing e2e tests, but they also seem to be failing in trunk.

[gziolo]

That makes perfect sense to update the metadata.bindings for the __default special case together with computed values for attributes 👍🏻

[cbravobernal]

Committed with https://core.trac.wordpress.org/changeset/59095