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.
• Experiment supporting 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.

EDIT: I created a new section for "Saving workflows" after the issues raised and because it seems a big topic to be discussed.

Follow-ups and bug fixes

• Don't show post meta fields that start with an underscore. (Temporary fix)
• Fix empty custom fields not being editable in bindings.
• Add warning when block attribute is connected to an invalid source.
• Rely on Text component instead of Truncate in bindings panel.
• Can't save changes to the source if custom fields are opened
• Potential filter to modify the value returned by bindings.
• Prioritize existing placeholder over bindingsPlaceholder.
• Only use canUserEditValue when setValues is defined.
• Only pass context included in usesContext from rich text component.
• Only pass usesContext properties to editor APIs.
• Refactor passing select and dispatch instead of full Registry.
• Fix editing protected custom fields in block bindings.
• Refactor e2e tests.
• Unify logic in getPostMetaFields function.
• Register bindings sources in widgets screens.
• Accept client ID as parameter for useBlockBindingsUtils.
• Don't render image when src attribute is empty.
• Bootstrap server sources earlier: Core & Gutenberg.
• Improve performance.
• Improve accessibility of bound paragraphs when using a screenreader in Navigation Mode.
• Change "This block is connected" indicator to make it accessible.
• Keep bindings editor calls in their own logic useSelect.

Nice to have

• Add indicator that an attribute is connected instead of hiding the controls.
• Add support for image caption.
• Add support for image href.
• Ensure custom field changes work fine with revisions.
• Send only edited values to the POST API requrest

UI to create bindings

For more info about the tasks, most of the discussions happened here.

• Create initial UI for connecting block attributes and custom fields.
• Block Bindings: Fix long keys overflow in bindings panel.
• Create utils to add/remove bindings in the object that can be reused.
• Decide where the bindings panel should live and in which cases it should be available: link.
• Remove experimental flag once the UI is considered ready.
• Add label argument to register meta.
• Add support for connecting custom fields in templates.
• Use post meta label from register_meta in block bindings workflows.
• Explore how permissions should work with bindings creation: link.

Nice to have

• Abstract the useToolsPanelDropdownMenuProps util.
• Add backdrop-color to connected blocks.
• Keep iterating on the UI:
  • Add a "Clear" button? See link.
  • Add a search bar?
  • Add a prompt when the connection hasn't been created yet. See link.
  • Improve UI of "read-only" panel. See link.

Polish and open editor APIs

• Improve the way sources are registered: This includes a refactoring to work as blockTypes, blockVariations, blockCollections... It also includes new functions like unregisterBlockBindingsSource and unit tests.
• Use @wordpress/warning during block registration instead of console.error and console.warn.
• Unify getValue/getValues and setValue/setValues APIs.
• Don't provide default canUserEditValue in reducer.
• Bootstrap sources defined in the server.
• Improve how the context is handled in the editor.
• Improve how the context is handled in the server.
• Allow bindings bootstrap after registration.
• How should bindings handle placeholder/fallback values?
  • Change placeholder when attribute is bound.
  • Remove getPlaceholder API and rely on key argument or source label.
• Revisit the extensibility mechanism to allow other sources to appear in the UI. See link.
• Make the editor APIs public: link.
• Add docs and types to source registration.

Support for more core sources

Nice to have

• 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.

Saving workflows

Nice to have

It isn't still clear if saving workflows should be modified or not as discussed here.

• Editing bound paragraph in post editor causes "Site Updated" message to appear.
• How/if to improve save workflows to notify users of specific post data changes?.
• Output granular post meta changes in a list.
• Add indicator for modified post meta in pre-publish flow

Backports

• Bootstrap sources defined in the server.

[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.

[SantosGuillamot]

I've opened a couple of pull requests/discussion that will affect the editor public APIs in case anyone wants to share feedback:

• Block Bindings: Unify getValue/getValues and setValue/setValues APIs #63185.
• Block Bindings: Improve the way block bindings sources are registered #63117.

[gziolo]

Thank you for opening the iteration for WordPress 6.7.

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.

That sounds like a potential key highlight in the release. It was one of the most anticipated features so far based on the feedback received. In particular, it will be interesting in conjunction with the Pattern Overrides design interface.

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.

This is another key aspect of opening the counterpart for the server-side API exposed in WordPress 6.5. It will also require some glue layer to pass some data from the server to the client to represent better custom sources that get registered only on the server in the UI.

[SantosGuillamot]

Update

There have been three main areas of work during the last weeks

UI to create bindings

The issue to discuss the potential workflows is receiving a lot of feedback, which is amazing 👏

The idea is to try to approach it progressively. Start with a basic version and keep iterating on top of that. That way, it adds value and let us test as soon as possible, which should help with the discussion.

We have started working on an initial prototype in this pull request, which is not far from ready.

Polish editor APIs

There have been a bunch of pull requests going on to polish the editor APIs in order to make them ready to be opened. I feel confident that it is on good track and it is a matter of making some decisions and review the existing code.

So far, these are the things that need to be solved before making them public:

• Improve the way sources are registered: This includes a refactoring to work as blockTypes, blockVariations, blockCollections... It also includes new functions like unregisterBlockBindingsSource and unit tests.
• Bootstrap sources defined in the server: Gutenberg PR and Core backport.
• Unify getValue/getValues and setValue/setValues APIs.
• Revisit how bindings should handle placeholders.
• Add docs and types to source registration.

Most of them seems to be working. Once they are merged, I feel the APIs could be open in Gutenberg.

Additionally, we have been working on:

• Improve how the context is handled: In the editor and in the server.

This one is not strictly needed to open the APIs, but I consider it important, and it seems to be working.

Saving workflows

While working on improving the saving workflows for post meta ((granular post meta changes and fixing/refactoring the logic for the “Site Updated” message), some important issues where raised that made us revert the current behavior in this pull request.

For that reason, we decided to take one step back and open a new issue to gather all the context to ensure we make informed decisions and avoid more issues like these ones in the future.

• How/if to improve save workflows to notify users of specific post data changes?  #63425

The idea is to discuss there how the saving workflows should work and split it into smaller tasks once it is clearer. It'd be great to get more thoughts there.

Next steps

These are what I considered that could be the next steps for the upcoming weeks:

• Keep the discussion and the prototype around the UI going.
• Review and make decisions around the editor APIs to start merging the changes progressively.
• Solve the remaining issues listed in the opening post, especially the bugs.
• Foster the discussion around saving workflows.

We could also start working on experimenting with potential future core sources to ensure the editor APIs fit their use case. Although we must be aware that the editor APIs are likely going to change in the mentioned PRs.

[bacoords]

Would love to see if this is feasible: #63763

[SantosGuillamot]

Would love to see if this is feasible: #63763

Personally, I would prefer to focus on the internals and add support for more core blocks once the right abstractions are in place and "hardcoding" is not needed. But I'm happy to help, review, or guide if this is wanted for pattern overrides and someone plans to work on that.