Block Bindings: Add `canUpdateBlockBindings` editor setting

[santosguillamot]

Needed for [WordPress/gutenberg#64570](​https://github.com/WordPress/gutenberg/pull/64570)

Adds canUpdateBlockBindings editor setting that will be read to decide if the user should be able to create and modify bindings through the UI. By default, only admin users can do it, but it can be overridden with block_editor_settings_all filter.

Needed for ​https://github.com/WordPress/gutenberg/pull/64570

This pull request adds a canUpdateBlockBindings editor setting that will be read to decide if the user should be able to create and modify bindings through the UI. By default, only admin users can do it, but it can be overridden with block_editor_settings_all filter.

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

[peterwilsoncc]

I've been trying to figure out the appropriate permission without success.

@santosguillamot commented on the pull request to explain the reasoning behind the change in permissions:

Part of the feedback received was that creating and managing bindings was too technical and still unclear who should be able to do that. As a safety measure, we considered adding this possibility to only admin users until we receive more feedback on who should have access to this and how.

I've come to the opinion that modifying the permissions is solving the wrong problem. Given that the issue is that the interface is too confusing, that doesn't really change based on a user's role.

If the interface is too confusing for a contributor, author or editor then it's also too confusing for an administrator. That the user can manage options, edit others' posts or has some other capability it doesn't make the interface easier to understand.

I think the best path forward is to iterate on the UI to make it intuitive for all users before introducing it to WordPress.

I've posted a comment on the associated issue Core-61945 (comment) -- tl;dr is that I think this is solving the wrong problem given the earlier comment that the interface is too technical.

[peterwilsoncc]

This was discussed in the dev chat earlier, see the ​conversation in #core

@santosguillamot Are you able to provide more information about the feedback you've received that I mentioned above? Did the comment about the UI being too technical come out of user testing, discussion among the team working on the feature or elsewhere?

It would also be good to know more info about the comments if they went in to further detail.

[cbravobernal]

Feedback we received:

• Custom fields are behind an advanced panel, in block editor settings. Block bindings, as are quite related so it is an advanced feature.

• The block bindings interface is using the ToolsPanel. Removing bindings needs to use the "reset" button. Is a common editor interface, but is easier to understand you are resetting styles than resetting connections per attribute.

• Some devs may not want their site admins to edit block bindings. Link: ​https://github.com/WordPress/gutenberg/pull/64570#issuecomment-2338829939

• Concepts like attributes, custom sources, custom fields, may be too developer focused.

• There were more than 20 comments discussing the interface with design, that gave us an impression of being too technical.

Apart from that, I agree that giving the same permissions as the custom meta fields is the way to go.

The feature flag has been enabled for a month or more, and we didn't get more feedback, I think now is time to give more visibility and be ready for Beta 1.

@santosguillamot won't be able to answer until next week I'm afraid.

Sorry folks, can I get some help on testing this. I followed the instructions in the GB PR but without success.

These are the steps I took:

1. Set up:
   • WP 6.6.2
   • Gutenberg trunk @ ​https://github.com/wordpress/gutenberg/commit/8a74d31f28e4d5ddc6f21be1bc2134e675d2913f
2. Build GB
3. Add new page
4. Insert paragraph, unable to see attributes
5. Insert second paragraph, still no luck
6. Activate Jetpack after seeing a comment on the GB PR
7. Add an image, no attributes.

I'm sure it's a problem at my end, can someone let me know what I am missing.

Sorry folks, can I get some help on testing this. I followed the instructions in the GB PR but without success.

These are the steps I took:

1. Set up:

• WP 6.6.2
• Gutenberg trunk @ ​WordPress/gutenberg@8a74d31

2. Log in as an admin

3. Build GB

4. Add new page

5. Insert paragraph, unable to see attributes

6. Insert second paragraph, still no luck

7. Activate Jetpack after seeing a comment on the GB PR

8. Add an image, no attributes.

I'm sure it's a problem at my end, can someone let me know what I am missing.

You may need to register a meta data. Like this:

function add_bindings() {
register_meta(
		'post',
		'all_templates_key',
		array(
			'show_in_rest'      => true,
			'single'            => true,
			'type'              => 'string',
			'default'           => 'all templates default value',
		)
	);
}

add_action( 'init', 'add_bindings');

If the meta is for a post it will appear in a post. If the meta is for a page, then you need to register with the page key.

Jetpack was adding a private custom field, that's the reason why it made the selector to appear before. We fix that, that's the reason why it didn't work for you anymore.

Here is a small video demo:

​https://github.com/user-attachments/assets/82a8c7b9-c285-4460-8f7f-78e13e67d3bd

Thanks @cbravobernal I knew I must have been missing something so I appreciate the help.

I am circling back to the ​Dev Chat, September 11, 2024 that I couldn't attend. I want to share more context.

My main concern here is that the approach is to hide the UI from users with low permissions. I don’t feel that this is a great approach to handling a UI that is considered too technical, as I don’t think there is anything to suggest that an administrator will understand what an author does not.

So I’m of the view the interface ought to be improved and made less technical before it’s shipped in core.

Block Bindings UI for connecting sources with block attributes will be ready with optimized user experience on time for WP 6.7. We had some minor concerns initially about how to present post meta options in the UI in the sidebar and for editable fields, but we did several iterations and plan to ​extend post meta to offer human-friendly labels to show in the editor. I think that was the primary concern we had (​related report) as seeing post meta keys like themeslug_book_rating will never be the most efficient for processing by human brain (despite being helpful for debugging in some cases).

I’d be fine with just updating this to use caps. The interface doesn’t strike me as being too technical. Can put it in the Advanced tab if we’re worried…

…The short of it is that I’m okay with fixing the cap issue (add a new cap, don’t check against a role) and shipping in 6.7 or leaving it in the plugin for more testing. Up to the team working on it. We have until beta 1 to decide.

The goal of this ticket/PR was to define the best strategy for handling the feature's exposure. We want to choose the best defaults that can be further optimized by the site owners. The panel for managing bindings would be only confusing when presented to all users, in particular those that only care about editing data. We also anticipated that on some sites, it will be disabled for nearly everyone as it is considered an advanced feature for site building. For example, when the intention is to expose block variations or patterns with bound attributes, the consumer should have a streamlined experience when editing values. However, the person editing the pattern’s design in the editor should be able to connect these attributes with binding sources. That’s basically what we want to offer with proper permissions, and that’s why we contemplated a custom capability.

I think meta capabilities is the way to go.

Similar to post types, we probably want multiple caps for editing own, editing others, etc. This will allow developers maximum flexibility.

To account for different permissions with CPTs, we'd probably want them to require the post ID, eg current_user_can( 'edit_block_binding', $post_id ) mapping to $post_type->caps->edit_others_posts. The edit_post meta capability will provide a guide.

Naming things is hard but typically meta capabilities are singular while primitive capabilities are plural.

Thanks for the guidance 🙂

To account for different permissions with CPTs, we'd probably want them to require the post ID

The main issue with this is that bindings can be edited in the site editor in templates, where a post ID doesn't exist. I checked and it seems in the site editor we are checking the edit_theme_options capability: ​link.

Would it make sense to fallback to that one when there is no post ID and we are in the context of the site editor? I made a commit trying to show what I mean: ​https://github.com/WordPress/wordpress-develop/pull/7258/commits/24951bcde7d5c2f8f756d5325c1e7e049c58a27d

Hey @SantosGuillamot. JavaScript packages were updated in r59072 so you might wish to rebase this for easier testing. The deadline to commit this backport is 6.7 Beta 1 which is scheduled for 1 October.

Rebased done 🙂 I believe I already have an idea of what needs to be done once we agree on the path forward. Let's see if we can agree on the mapping capabilities.

I've addressed the changes suggested and added a unit test to check the capabilities are mapped properly. Let's see if the unit tests pass.

With these changes, this is how it should work:

• If it is in the context of a post, and post->ID exists, it maps to edit_post.
• If it is in the context of a template, and post->IDDOES NOT exist, it maps to edit_theme_options.

Let me know if that makes sense, or if I should change anything.

What's clear here is that the right solution here is still unclear and there are still diverging opinions. If It helps unblock this PR, I wouldn't mind personally this is landing as a block editor setting.

Now, my personal opinion is that whether this applies to the block editor only or not is irrelevant, we want to control the ability of the user to perform a task or not. So for me, this is a user capability (in the large sense) and the ideal for me is that we should have a unique way in core-data to access user capabilities. (I'm less opinionated about the backend and REST API, how user capabilities are managed there is not something I have expertise on)

[cbravobernal]

In 59122:

Block bindings: Add canUpdateBlockBindings editor setting.

Adds a canUpdateBlockBindings editor setting that allows to decide if the user is able to create and modify bindings through the UI. By default, only admin users can do it, but it can be overridden with block_editor_settings_all filter.

Props santosguillamot, gziolo, jorbin, noisysocks, matveb, cbravobernal, youknowriad, mamaduka, timothyblynjacobs, peterwilsoncc, drivingralle.
Fixes #61945.

Commited with https://core.trac.wordpress.org/changeset/59122

TThere has been some discussion about whether the ability to update block bindings in the editor should be a setting/preference or a capability.

This ability should be filterable by external developers, which suggests the editor setting approach. However, it is not a user setting, as the user cannot choose whether or not to update block bindings—it is only enabled for admins or filtered by third-party extensions.

Overuse of editor settings is not recommended by Gutenberg practices, so adding a capability could work. However, it has not been merged yet.

Considering there is no clear right solution, and the editor setting is theoretically a valid approach, I have committed it so it doesn't block the adoption of block bindings. Additionally, it is a helpful feature for site admins, as shown, for example, in this comment:
​https://github.com/WordPress/gutenberg/pull/64570#issuecomment-2338829939