Open up "Pattern Overrides" and therefore intern block bindings to custom dynamic blocks

[fabiankaegy]

This issue is coming out of a discussion in the Make WordPress Slack Outreach Channel where we discussed some of the reasons why we are not ready to adopt pattern overrides on custom build projects.

Currently, pattern overrides is limited to only a small set of core blocks that have handling for their block bindings HTML replacement handled manually. With that, we have opted not to expose the mechanisms to create blocks that make use of the Pattern Overrides feature publicly until the HTML API lands in core.

However, we just realized that this limitation to wait on the HTML API only really applies to static blocks (ones that serialize their HTML to the database). For dynamic blocks (block rendered via a render_callback in PHP) this limitation does not exist.

Because of that I would propose that we open up the block bindings / pattern overrides feature for custom blocks that use dynamic rendering.

How to achieve that:

First we would need to find a way to indicate which attributes of which blocks actually allow to be bound to something. Currently, this is managed in a hard-coded list. #64756 explores adding a bindable decorator to the attributes definition which could be used to get that list dynamically.

Once we know which attributes of which blocks support bindings, we would need to also use that to handle saving attributes / passing in the correct value of attributes correctly in the editor.

And finally, we can use that same bindable key to replace https://github.com/WordPress/wordpress-develop/blob/e569967ee45e23186f6aa7f479fcb48a7511436b/src/wp-includes/class-wp-block.php#L246-L251 with the dynamic lookup of supported bindings.

[fabiankaegy]

CC: @gziolo @SantosGuillamot since you participated in the conversation in slack :) Would love to get your take on whether I captured things correctly here and to fill in all the nuances that I am missing

[bph]

Also pinging the outreach group @WordPress/outreach to chime in especially on use cases adn further thoughts

[fabiankaegy]

I can chime in and provide some use case examples also :)

First of all, pretty much all blocks we built on custom sites are dynamic block. The reason for this is mostly due to design flexibility with continually changing design requirements.

Some examples of these custom blocks we have on pretty much every project:

1. Post Picker block
   We have a post picker block that works similar to the post template of the core query. So you can use any of the post level blocks within that block to manage your layout. But instead of being defined by a query, the user can manually search for any articles on their site and reference it. Under the hood all we store in the blocks attributes are the postId and postType.
   It would be super valuable to be able to use this post picker in a synced pattern and then enable overrides so that a user is still able to change the post that gets displayed (this happens via the blocks toolbar and already is setup to work in content only locking)

2. Icon block
   Similar to the above example we have an Icon block. This icon block allows the user to pick from a predefined set of icons that we bundle with the theme. All we store is the name of the icon.

It would be great be to able to use that inside a synced pattern and enable overrides so that the user can still change the actual icon that should be used whilst all the design options of how large, what color, etc the icon is are still synced.

---

The end goal that would the make this feature soooooo much more powerful is to allow for all of this in Synced Theme Patterns (#59272)