Make WordPress Core

Opened 3 weeks ago

Last modified 7 days ago

#62090 new defect (bug)

Editor: Add filter for supported block binding attributes

Reported by: maxschmeling's profile maxschmeling Owned by:
Milestone: 6.8 Priority: normal
Severity: normal Version: 6.5
Component: Editor Keywords: has-patch has-unit-tests
Focuses: Cc:

Description

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

Change History (8)

This ticket was mentioned in PR #7404 on WordPress/wordpress-develop by @maxschmeling.


3 weeks ago
#1

  • Keywords has-patch has-unit-tests added

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

@gziolo commented on PR #7404:


2 weeks ago
#2

We are discussing exactly the same problem in Gutenberg:

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

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

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:

@maxschmeling commented on PR #7404:


2 weeks ago
#3

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 commented on PR #7404:


2 weeks ago
#4

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 commented on PR #7404:


2 weeks ago
#5

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 commented on PR #7404:


13 days ago
#6

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:

@fabiankaegy commented on PR #7404:


13 days ago
#7

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

Let me know if you have more questions :)

#8 @gziolo
7 days ago

  • Component changed from General to Editor
  • Milestone changed from Awaiting Review to 6.8
  • Summary changed from Add filter for supported block binding attributes to Editor: Add filter for supported block binding attributes
  • Version set to 6.5
Note: See TracTickets for help on using tickets.