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 :)

[audrasjb]

As per today's bug scrub:
Hello @gziolo @fabiankaegy @maxschmeling, the PR is in draft status and it looks like we still need a decision. I'll move it to Future Release by next week or so :)

[gziolo]

I took another look at this ticket, and I concluded that we could introduce a way to filter the way the block attributes are accepted for processing with Block Bindings. I would be in favor of using a slightly modified approach which is closer to the existing filter that allows changing the return value computed for the specific source:

​block_bindings_source_value

The definition looks as follows:

apply_filters( 'block_bindings_source_value', mixed $value, string $name, array $source_args, WP_Block $block_instance, string $attribute_name )

In the case of the decision process for the individual attributes on whether they should be processed when connected through Block Bindings, we could have something similar in place, example:

apply_filters( 'block_bindings_supported_attribute', boolean $supported, WP_Block $block_instance, string $attribute_name )

It would definitely require some refactoring in the patch proposed, but I personally like the flexibility it offers while keeping the simple API where the filtered value has a boolean type in contrast to the current proposal where the array would have to be extended with every possible block type and attribute names.

[audrasjb]

As per today's bug scrub: It appears this ticket is still needs some work. As 6.8 beta 1 is very close, I'm moving it to 6.9. Feel free to move it back to 6.8 if it can be committed by Monday.

[Bernhard Reiter]

#63740 was marked as a duplicate.

This has been discussed in https://core.trac.wordpress.org/ticket/62090.

Alternatives considered include:

1. A dedicated property to denote a block attribute as bindable in block.json, e.g.

"attributes": {
	"datetime": {
		"type": "string",
		"bindable": true
	},
}

2. Inferring that an attribute is bindable if it has "role": "content" set:

"attributes": {
	"datetime": {
		"type": "string",
		"role": "content"
	},
}

I agree that the latter is probably a good idea in the long run. However, there are currently 83 block attributes with "role": "content" in Gutenberg, and it's not a trivial feat to make all of them bindable. (There are some complications, e.g. attributes such as an image block's caption which is only rendered conditionally.)

In the meantime, the absence of an extensibility mechanism for the list of supported block attributes means that _each block has to manually invoke block bindings to ensure backwards compatibility_, as seen e.g. ​here for the Date block. This is required so the block doesn't erroneously receive the fallback value for the bound attribute if the GB plugin is run on a WP version that doesn't have that block attribute added to $supported_block_attributes in WP_Block::process_block_bindings(). On a WP version that _does_ support the block attribute, it means that the relevant code is needlessly run twice.

This is suboptimal. It also puts undue burden on block developers to include the back-compat code in their blocks, instead of being able to mark their bindable block attributes as such; it thus can hamper adoption of Block Bindings, as it makes it much more difficult to update a block to make some of its attributes bindable.

Note that this solution isn't meant to be mutually exclusive with the long-term perspective of having "role": "content" determine if a block attribute is bindable or not, as the initial value of $supported_block_attributes could be computed by iterating over blocks and including all attributes with that criterion in the list.

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

[Bernhard Reiter]

In 60611:

Block Bindings: Add filter to set supported block attributes.

Add a new filter, block_bindings_supported_attributes_{$block_type}, that allows customizing which of a block's attributes can be connected to a Block Bindings source.

Props bernhard-reiter, gziolo, maxschmeling.
Closes #62090.

Comitted to Core in https://core.trac.wordpress.org/changeset/60611.

I've committed a changeset to Core that implements a filter to customize which of a block's attributes are supported by Block Bindings. Thanks everyone!

Backport of changes made to the tests in ​https://github.com/WordPress/gutenberg/pull/71389.

Independently of that PR, I think these changes make sense, since they make the tests less verbose and less redundant.

The changes are basically as follows:

• Use the newly introduced block_bindings_supported_attributes_{$block_name} filter to register a test/block's attribute as supported by Block Bindings, rather than using an actual block (Paragraph) for most tests.
• Merge three test cases that check if get_value_callback works correctly (accepts arguments; correctly includes symbols and numbers; return value is sanitized when rendered) into one, by using a dataProvider.
• Merge two test cases that check if block context is correctly evaluated, and that access is only given to context included in a source's uses_context property.

No semantic changes have been made, at least not deliberately -- the tests should still cover the same expected behavior.

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

Committed in #60720.

[Bernhard Reiter]

In 60790:

Block Bindings: Add block_bindings_supported_attributes filter.

Add a block-agnostic version of the block_bindings_supported_attributes_{$block_type} filter first introduced in [60611].

This allows adding block bindings support for attributes of multiple different blocks in one go.

Follow-up to [60611].
Props bernhard-reiter.
See #62090.

Add a block-agnostic version of the block_bindings_supported_attributes_{$block_type} filter (first introduced by `[60611`]/​https://github.com/WordPress/wordpress-develop/pull/9392)

This will allow adding block bindings support for attributes of multiple different blocks in one go.

See ​https://github.com/WordPress/gutenberg/pull/71662#issuecomment-3291847715.

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

Committed to Core in https://core.trac.wordpress.org/changeset/60790.