Editor: Add filter for supported block binding attributes

[maxschmeling]

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

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

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

We are discussing exactly the same problem in Gutenberg:

• ​https://github.com/WordPress/gutenberg/issues/64870

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

• ​https://github.com/WordPress/gutenberg/issues/64756

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

• ​https://github.com/WordPress/gutenberg/pull/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:

• ​https://github.com/WordPress/gutenberg/issues/64189

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.

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.

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.

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:
​https://github.com/WordPress/wordpress-develop/blob/0b8b80449fb25e0242ad53262fcbabc08ea3ecb9/src/wp-includes/class-wp-block.php#L253-L261

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:

• ​https://github.com/WordPress/gutenberg/issues/64870

@gziolo I had shared some examples here: ​https://github.com/WordPress/gutenberg/issues/64870#issuecomment-2315646188

Let me know if you have more questions :)