Block Bindings iteration for WordPress 6.7

[SantosGuillamot]

Iteration of the Block bindings API tracking issue.

This issue will be used to gather the new functionalities and bug fixes expected to be included in WordPress 6.7. It will serve to share regular updates and progress.

Please keep in mind that the list of issues will change once new ones come up.

For this iteration of WordPress 6.7, the focus will be on these items (no specific order):

• Follow-ups from 6.6 and bug fixes: There were a few items that weren't included in the 6.6 iteration that will need some work. Additionally, bugs need to be addressed.
• Add UI to connect attributes with the binding sources: Basically, add the first iteration to be able to create the bindings through the UI instead of having to go to the Code Editor.
• Polish and open block bindings editor’s APIs for extenders: Core sources like "Post Meta" use some private APIs to handle bindings in the editor. The idea is to polish those APIs to enable external developers to use them.
• Add support for more core sources: In order to ensure that the editor APIs fit future use cases, it'd be great to add support for more core sources, or at least experiment with them in case we want to create them in the future.
• Support anything needed by pattern overrides: We can expect some work needed to support new functionalities in pattern overrides.

Follow-ups and bug fixes

• [ ] Ensure custom field changes work fine with revisions.
• [ ] Improve accessibility of bound paragraphs when using a screenreader in Navigation Mode.
• [ ] Change "This block is connected" indicator to make it accessible.
• [ ] Output granular post meta changes in a list
• [ ] Add indicator for modified post meta in pre-publish flow
• [ ] Add indicator that an attribute is connected instead of hiding the controls.
• [ ] Editing bound paragraph in post editor causes "Site Updated" message to appear.
• [ ] Add support for image caption.
• [ ] Add support for image href.
• [ ] Potential filter to modify the value returned by bindings.

UI to create bindings

• [ ] Create initial UI for connecting block attributes and custom fields.
• [ ] Create utils to add/remove bindings in the object that can be reused.
• [ ] Use utils in pattern overrides.
• [ ] Add an extensibility mechanism to allow other sources to appear in the UI.
• [ ] Explore how permissions should work with bindings creation.

Polish and open editor APIs

• [ ] Unify the setValue/setValues APIs.
• [ ] Revisit how core sources are registered and how external sources should do it.
• [ ] Revisit the API to output the placeholder value.
• [ ] Improve how the context is handled.
  • [ ] (related core PR) Block Bindings: Add context needed by block bindings sources during its processing
• [ ] Add proper docs to the editor functions.
• [ ] Add unit tests similar to the ones we have on the server.

Support for more core sources

• [ ] Create an experiment to support taxonomy meta and decide if it should be included as a core source.
• [ ] Create an experiment to support site data and decide if it should be included as a core source.
• [ ] Create an experiment to support post data and decide if it should be included as a core source.

[fabiankaegy]

@SantosGuillamot Thank you for creating this new iteration issue :)

Do you think it is feasible as part of 6.7 to aim for opening up the block bindings features (and therefore block pattern overrides) to 3rd party blocks / extenders?

[SantosGuillamot]

Do you think it is feasible as part of 6.7 to aim for opening up the block bindings features (and therefore block pattern overrides) to 3rd party blocks / extenders?

I'm afraid it will probably take more time than this release. To give more context, block bindings heavily rely on the HTML API, which still lacks a few functionalities to safely interact and modify any HTML element. It needs to ensure that it doesn't create any security issues or break the page. For core blocks where the markup is controlled, this isn't a big problem, but opening it for any 3rd party block, which could have any markup, could trigger unexpected issues. Additionally, a new opt-in mechanism would need to be defined.

Hopefully, if I am not mistaken, the HTML API is not far from being able to handle these use cases, so I believe it should probably be one of the top priorities for upcoming releases.

In the meantime, if there is a need to support other core blocks, those could be considered.