Block Bindings: Add context needed by block bindings sources during its processing

[SantosGuillamot]

Trac ticket: https://core.trac.wordpress.org/ticket/61642

What?

Block bindings sources sometimes need to access some context that is not initially available in the block. Right now, we are extending it when the source is registered. This pull request moves the logic so it is added when the block bindings are processed. This means:

• Before: Extend context during block bindings source registration. This implies that the blocks extend the context even when they don't use bindings.
• After: Extend context during block bindings processing. This implies that the context is extended ONLY for the blocks where bindings are defined.

How?

Instead of using the get_block_type_uses_context created back then for this use case, use the available_context in the block class during bindings processing.

I assume it is not possible to remove that filter because of backward-compatibility.

Testing instructions

0. Register a custom field in your site to test it. You can use a code snippet like this:

register_meta(
	'post',
	'url_custom_field',
	array(
		'show_in_rest' => true,
		'single'       => true,
		'type'         => 'string',
		'default'	   => 'https://wpmovies.dev/wp-content/uploads/2023/04/goncharov-poster-original-1-682x1024.jpeg',
	)
);

1. Go to a page and insert an image block.
2. Go to the Code editor and connect the image to the custom field by adding the metadata bindings property. It should look something like this:

<!-- wp:image {"id":134,"sizeSlug":"large","linkDestination":"none","metadata":{"bindings":{"url":{"source":"core/post-meta","args":{"key":"url_custom_field"}},"alt":{"source":"core/post-meta","args":{"key":"text_custom_field"}}}}} -->
<figure class="wp-block-image size-large"><img src="https://wpmovies.dev/wp-content/uploads/2023/04/goncharov-poster-original-1-682x1024.jpeg" alt="Alt content" class="wp-image-134"/></figure>
<!-- /wp:image -->

3. Save the page and check that in the frontend, the URL defined in the custom field is used.
4. Repeat the process for paragraph, heading, and button blocks.

[github-actions]

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 santosguillamot, gziolo, artemiosans, cbravobernal.

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

[github-actions]

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.

[gziolo]

This looks very promising.

[gziolo]

We still need to provide an alternative way to expose the uses_context defined for the block binding sources to the client. Previously it was handled through the block type definitions exposed on the server. In the revised approach, that information is only available on the server, so that might have some implications on how existing block binding sources work in the editor.

[SantosGuillamot]

I've been looking at exposing the uses_context to the client, and I pushed some changes to expose it through editor settings: link. That way it could be consumed by the client with getEditorSettings as explained here.

Is it okay to use editor settings for that? Any other alternative?

[gziolo]

I left some comments related to the idea to expose setting for block bindings together with the editor settings.

Is it okay to use editor settings for that? Any other alternative?

We are using the same approach for many editor features so that should be acceptable approach.

[SantosGuillamot]

I've moved the logic to expose bindings in the editor settings to this other pull request: #7020. The idea is to keep this one to change the way the context is handled.

[artemiomorales]

Looks good to me 👍

[gziolo]

@peterwilsoncc opened #7226 where he started the process of syncing WordPress packages to WordPress core for the WP 6.7 release. Once that lands, this PR needs to be rebased as it already reports some merge conflicts and it will be ready to commit.

[cbravobernal]

@peterwilsoncc opened #7226 where he started the process of syncing WordPress packages to WordPress core for the WP 6.7 release. Once that lands, this PR needs to be rebased as it already reports some merge conflicts and it will be ready to commit.

Happy to rebase, review and test it once is ready.

[gziolo]

It’s time to rebase this branch and commit changes 🚀

[SantosGuillamot]

Rebased done 🙂 Let's see if tests pass, but I believe this should be ready. I'm testing now if it works as expected.

[SantosGuillamot]

I've been manually testing it and it looks good. If I connect an image to a custom field it shows the connected value in both the editor and in the frontend (server processing).