Block Bindings API/UI: Attributes Panel still shows when block is set to 'contentOnly' editing mode.

[bacoords]

Description

When you set a block to using to contentOnly mode the Attributes panel is still visible, even though all of the other InspectorControls are gone.

CC @cbravobernal @SantosGuillamot

Step-by-step reproduction instructions

1. Enable contentOnly editing mode on a block, typically using const { setBlockEditingMode } = useDispatch( blockEditorStore );,
2. Check any block that's allowed to have bindings, the panel shows up.

Screenshots, screen recording, code snippet

Normal Paragraph Inspector controls:

Paragraph in contentOnly editing mode (it appears whether a binding was set or not):

Environment info

• Gutenberg 19

Please confirm that you have searched existing issues in the repo.

• [X] Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• [X] Yes

[SantosGuillamot]

This is an interesting use case, and I'm not sure what the expected behavior is. Someone could argue that connecting block attributes is actually content.

In this other pull request, we plan to change the Attributes section to behave like the "Advanced" controls. That means that for the paragraph block, it doesn't add a "Settings" tab.

Let's gather some examples of how the paragraph and image blocks work right now with contentOnly mode and how they would work with that pull request.

Paragraph block WITHOUT the "Attributes" panel

It is the same for an empty paragraph and paragraph with content. But it still shows some settings like "Typography".

Empty Paragraph	Paragraph with content

Paragraph block WITH the "Attributes" panel

We would be adding a new controls aside from "Typography".

Empty Paragraph	Paragraph with bindings

Image block WITHOUT the "Attributes" panel

It still shows controls for relevant attributes like alt or title.

Empty Image	Image with content

Image block WITH the "Attributes" panel

We would be adding the "Attributes" controls among the existing ones.

Empty Image	Image with bindings

---

With that in mind, do we really want to remove the "Attributes" controls in contentOnly mode, or should the changes in the mentioned pull request be enough? I must say I don't have a strong opinion yet.

[gziolo]

This is an interesting use case, and I'm not sure what the expected behavior is. Someone could argue that connecting block attributes is actually content.

That was exactly my thinking, too. @SantosGuillamot also has open PR when the experiment for enabling connecting block bindings is promoted to a feature that is controlled with a setting in Preferences:

• https://github.com/WordPress/gutenberg/pull/64570

It's still to decide how this setting would work :

• Disabled for all users but the admin to start with?
• Limit this setting to certain roles/permission?

[cbravobernal]

Disabled for all users but the admin to start with?

This could be a good starting point.

My point of view is that connecting bindings should be only allowed to "layout" creators. And editing the values should be available to any "content" people.

I'm still thinking about the case of a newspaper site, where the editor/admin sets the layout of a post, page and people from content fill with content every day.

For site owners, you are already an admin, so that should not be a problem.

The main issue I find with that approach is that showing the panel only in posts/pages seems not to be really useful. As that panel will be mostly used in site editor, where we have still tons of decisions to make (show keys, default values, how to implement it with REST API, etc).

But, for the future "bits", as content creator, you may want to add a paragraph that connects to a custom field, and they would suffer this limitation.

Should we create a capability and let the site owner to decide if the panel should show or not?

[bacoords]

This is an interesting use case, and I'm not sure what the expected behavior is. Someone could argue that connecting block attributes is actually content.

I would disagree with this- disconnecting a block from a binding or changing it to connect to a different piece of data is a structural change beyond simply changing content. Editing the field/binding data would be editing the content, but adding/removing a connection seems like something you wouldn't want in contentOnly mode, the same way you wouldn't allow someone to change/remove a binding in a synced pattern.

What's the use case for setting a binding that can always just be disconnected/changed anyway?

Should we create a capability and let the site owner to decide if the panel should show or not?

I think this would be a decent starting place/compromise.

[SantosGuillamot]

In this comment, I've tried to cover the different use cases of how that pull request works. There are two different aspects:

• See the existing connections.
• Create/modify connections.

That pull request adds a preference to enable/disable the creation of connections, which is only available for admin users. I am not sure in which scenarios admin users will have the contentOnly option enabled, so it should palliate whatever we decide here.

It'd be great to agree on which cases we should show the "read-only" UI, if we should hide it even if there are existing connections, and in which cases users should be able to create/modify them.

[fabiankaegy]

I would agree with @bacoords here. Managing bindings is not something a regular content editor should be able to change especially when in content only locking mode.

Creating a special capability for it though sounds even better 👀

[SantosGuillamot]

In this other pull request, if it gets merged, it will only allow admin users to create and modify bindings, while the rest of the users will just see a "read-only" panel when bindings exist. It relies on an editor setting that can be overridden using a filter.

This means that regular content editor wouldn't be able to manage bindings, just read them.

In that case, do you think we still need to hide the panel when "content only" mode is enabled? Is it common to have "content only" mode for admin users?

[bacoords]

I think that's fine. Conceptually I still would agree with the original premise of this issue, but if there's an alternative using a filter or custom capability, that's a viable solution.