Block bindings: Add filter for supported block attributes

[maxschmeling]

Adds a filter called block_bindings_supported_block_attributes to allow adding blocks / attributes to the supported list.

This list of allowed attributes for block bindings is the only thing in core keeping us from making larger use of block bindings for our Remote Data Blocks plugin. The bindings already work how we need them to, they just aren't allowed on custom blocks, and this filter will allow us to add additional blocks / attributes to the list so we can hook remote data up to dynamic blocks using the standard block binding functionality.

For our use case, the use of this will be abstracted away by our plugin and it would not be super problematic to deprecate this filter if another approach is decided on in the future. But without this change making it into 6.7, it means our RDB plugin will be severely limited in functionality until at least 6.8, so getting this merged would be huge for us.

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

---

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]

Hi @maxschmeling! 👋

Thank you for your contribution to WordPress! 💖

It looks like this is your first pull request to wordpress-develop. Here are a few things to be aware of that may help you out!

No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description.

Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this GitHub repository mirrors. Please feel free to open pull requests to work on any contribution you are making.

More information about how GitHub pull requests can be used to contribute to WordPress can be found in the Core Handbook.

Please include automated tests. Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the Automated Testing page in the handbook.

If you have not had a chance, please review the Contribute with Code page in the WordPress Core Handbook.

The Developer Hub also documents the various coding standards that are followed:

• PHP Coding Standards
• CSS Coding Standards
• HTML Coding Standards
• JavaScript Coding Standards
• Accessibility Coding Standards
• Inline Documentation Standards

Thank you,
The WordPress Project

[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]

We are discussing exactly the same problem in Gutenberg:

• Open up "Pattern Overrides" and therefore intern block bindings to custom dynamic blocks gutenberg#64870

The initial idea was to use a more declarative approach and mark bindable attributes explicitly:

• Block Bindings: Expose bindable attributes through an annotation in the block definition gutenberg#64756

In the meantime, @getdave started working on changes that makes the role property stable:

• Blocks: Stabilise role attribute property gutenberg#65484

In effect, we are pivoting towards allowing annotating block attributes as content. Example for the Paragraph block would look like:

"attributes": {
	"content": {
		"type": "rich-text",
		"source": "rich-text",
		"selector": "p",
		"role": "content"
	}
}

That role alone would be enough to open the attribute for Block Bindings processing. In effect, we need to rethink whether a proposed filter fits into this system. The downside of PHP filter that gets wired during server-side processing is that the same information is missing in the editor, so it would be up to the developer to handle everything correctly there. I have some concerns that this proposal doesn't offer a general enough solution. More consideration to take into account is covered in this issue:

• Block Bindings: context for supporting any block attribute gutenberg#64189

[maxschmeling]

Thanks, @gziolo

I definitely understand that there's a real chance this doesn't end up being the end solution, and so if it can't get in, I understand. However, I'm really hoping there's some way we could open up block bindings in core with 6.7 so we don't have to wait for 6.8 to expand our Remote Data Blocks plugin that we're building at WPVIP. I know once there's a filter here, it's more of a pain to remove it, so maybe it's just not possible for now.

Having some way to modify that restrictor on supported blocks allows things to move in Gutenberg and our plugin and get our customers using the functionality before 6.8.

I love the idea of being able to programmatically control some of this (rather than just declaratively from the block itself) so that bindings could be enabled on a block from outside. Ideally our Remote Data Blocks plugin could "turn on" bindings for custom blocks provided by customers.

Let me know if you see any way of modifying this to something we're comfortable with for 6.7.

[SantosGuillamot]

Apart from everything already mentioned, I'm concerned about adding a way to enable bindings for any block at this point because we know many of them, especially static blocks, won't work as expected in multiple scenarios. You can find more context in this GitHub issue. For that reason, I believe that this should be done "at your own risk", which makes me think that, if something is added right now, it should be treated as experimental.

I know it is a pain not having bindings for any block yet, and it is one of the focuses right now, but there are some functionalities needed first to ensure block bindings are reliable.

[maxschmeling]

It makes sense for it to be experimental for now to me. But having something in there that allows us to experiment in Gutenberg and get feedback from our “beta” users would help us learn more about real world usage.

[gziolo]

New block API for attributes role: content landed and will be included in WordPress 6.7. It lets us use it to enable bindings for every attribute that is annotated with role: content. So the alternative to the filter proposed could be integrated in the same place:

wordpress-develop/src/wp-includes/class-wp-block.php

Lines 253 to 261 in 0b8b804

	// If the block doesn't have the bindings property, isn't one of the supported
	// block types, or the bindings property is not an array, return the block content.
	if (
	! isset( $supported_block_attributes[ $this->name ] ) ||
	empty( $parsed_block['attrs']['metadata']['bindings'] ) ||
	! is_array( $parsed_block['attrs']['metadata']['bindings'] )
	) {
	return $computed_attributes;
	}

Pseudo-code I was thinking about:

// Detects if the block can have bindings.
$bindable = false;
if ( ! str_starts_with( 'core/ ) && $this->name $this->block_type->is_dynamic() ) {
    foreach ( $this->block_type->attributes as $key => $schema ) {
        if ( 'content' === $schema['role'] ) {
            $bindable = true;
            break;
        }
    }
}

I was wondering how the custom blocks would work with the filter outlined in this PR. The same information won't be available on the client. At the same time, the changes outlined above with role: content could be read by the client, but at the moment, the entire UI is limited to the allowed core blocks: Paragraph, Heading, Image, and Button. @fabiankaegy, can you share more details about the use cases you had in mind when opening an issue:

• Open up "Pattern Overrides" and therefore intern block bindings to custom dynamic blocks gutenberg#64870

[fabiankaegy]

@gziolo I had shared some examples here: WordPress/gutenberg#64870 (comment)

Let me know if you have more questions :)