Allow Disabling of Synced Pattern Overrides (dynamically)

[MadtownLems]

What problem does this address?

While we are very excited about the possibilities of Synced Pattern Overrides, it feels like a very advanced topic that we'd like to prevent our content providers from creating on their own (at least for now). We also imagine a world where Network Administrators can create them (and content providers could use them)

What is your proposed solution?

Allow the ability to create patterns that contain overrides to be removed with a filter, such as with block_editor_settings_all (https://developer.wordpress.org/reference/hooks/block_editor_settings_all/). This would allow us the ability to let Network Administrators create them, but typical users could only use them.

[talldan]

As pattern overrides are implemented using the block binding API, I'll also add the 'Block bindings' label to this. It could potentially be a block bindings feature rather than specific to patterns.

[SantosGuillamot]

It seems there are different use cases here that might affect the potential implementation:

• Conditionally disallow "Synced Pattern" creation.
• Conditionally disallow the "Overrides" option from synced patterns.
• Conditionally disallow the editing of the overridable values when a synced pattern with overrides has already been created.

The first two points seem specific to the Synced Patterns UI, which does not use bindings.

For the last one, I assume that if a user has the permissions to edit the post where the pattern is inserted, they should be able to edit the overridable values. And if they don't have permissions, they shouldn't. Is that right?

[kraftner]

Related: #28895 (comment)

[talldan]

The first two points seem specific to the Synced Patterns UI, which does not use bindings.

The first is really #28895. Patterns (wp_block post types) need their own distinct capabilities to enable that.

The second is more nuanced (hiding the Enable/Disable overrides button), and I think that's what this issue is about. In my mind this is more closely related to bindings.

For example, it might be that in the future extenders can configure which blocks support which bindings, and that could be one way to achieve this. Whether it disables the UI for enabling bindings or completely prevents the bindings from working at all is another matter. The second option is dangerous as it can completely change a site's content if they already have active bindings.

It could also be that there's some config in the binding source to prevent the UI from showing, though perhaps that's only for the default bindings UI.

There's also the possibility of unregistering the binding source completely.

For the last one, I assume that if a user has the permissions to edit the post where the pattern is inserted, they should be able to edit the overridable values. And if they don't have permissions, they shouldn't. Is that right?

Yep, that's correct.

[gziolo]

Linking the related issue that proposes adding meta capability for Pattern Overrides:

• Pattern overrides: ensure an additional meta capability for override capability #57940

Speaking of Block Bindings, there was recently a block editor setting introduced that controls whether the user should be able to manage Block Bindings through UI:

• Block Bindings: Allow only admin users to create and modify bindings by default #64570

There is a follow-up work that explores adding meta capability to add more control on the server:

• Block Bindings: Add canUpdateBlockBindings editor setting wordpress-develop#7258