Block Bindings: Iteration for WP 6.6

[SantosGuillamot]

Iteration of the Block bindings API tracking issue.

This is what we expect to include in WordPress 6.6. We'll use this issue to share regular updates and progress.

---

• Bindings creation

Even though we'll probably won't add a UI to create bindings yet, we'd like to start discussing how it should work.

• Server APIs

• Improve the existing code
  • Block bindings: Remove not needed breaks in gutenberg_block_bindings_replace_html #61660
  • Block Bindings: Simplify the HTML replacement logic until the HTML API is ready #61236
• Revisit how sources access the needed context.
  • Add context needed by block bindings sources during its processing

• Editor APIs

• Improve the existing hook implementation.
  • Block bindings: don't use hooks #60724
• Add support for allowing editing.
  • Block bindings: don't use hooks #60724
• Simplify the HTML replacement logic until the HTML API is ready.
• Add callback so sources can decide when to lock/allow editing.
• Improve the UX when the editing of bound blocks is locked.
  • Add bindings panel in the block inspector controls: Once/if this is merged, we can revisit the existing toolbar indicators.
  • Filter pattern overrides source in bindings panel
  • Notify on save when users edit the value of a connected custom field instead of the post content.
  • Add indicator that an attribute is connected instead of hiding the controls.
• Define and implement UX for editing custom fields directly from blocks connected.
• Define how to work with placeholders.
• Revisit how sources access the needed context.
  • Block Bindings: rely on broader context instead of requiring direct block context #60826

• Core sources

• Use block bindings editor API to update pattern overrides.
  • Pattern overrides: use block binding editing API #60721
• Support editing in "Post meta" source.
  • Block Bindings: Allow editing in post meta source #61753

---

Follow up tasks after 6.6

• Don't use a hook to modify setAttributes as discussed here.

[SantosGuillamot]

Update

There are a bunch of pull requests/initiatives going on:

• ✅ Editor hook refactoring: This was already merged. It simplifies the logic and solves the existing issues related to the editor. Additionally, it allows registered sources to define how to update the values when a block is bound.
• Use block bindings editing APIs in pattern overrides: After the refactoring, it is possible to use the block bindings editing APIs for pattern overrides. This pull request aims to cover that.
• Allow editing of custom fields from connected blocks: The idea of that pull request is to support editing when a block is connected to Post Meta. It is "working", but it lacks the possibility of locking the editing depending on the context and proper e2e tests.
• Support all content image and button attributes in block bindings: I started this pull request to support the remaining attributes for these blocks. It is probably needed by pattern overrides. It misses some logic in the editor and adding e2e tests.
• Rely on broader context instead of requiring direct block context in the editor: After some discussion, I believe this one is ready to be merged.
• Add context needed by block bindings sources during its processing: Complementary to the previous point, we should decide if we want to pursue this approach.
• Simplify the HTML replacement logic until the HTML API is ready: Change the block bindings HTML replacement logic to use a hardcoded list of selectors based on the block and a regex to substitute the inner content until the HTML API is ready.
• Explore how to improve the UI when a block is bound. I believe this can be approached progressively, so I opened three different issues to discuss separately:
  • Add bindings panel in the block inspector controls: Once/if this is merged, we can revisit the existing toolbar indicators.
  • Notify on save when users edit the value of a connected custom field instead of the post content.
  • Add indicator that an attribute is connected instead of hiding the controls.

Apart from that, I started this experiment to expose the editor APIs and allow any block to use them.

List of blockers/decisions to be made

I'm listing here what I consider the current blockers or decisions remaining for these issues/pull requests, but let's keep the discussion in their specific threads.

Use block bindings editing APIs in pattern overrides

Figure out how to solve calling setAttributes for non-connected block attributes as discussed here.

Support all content image and button attributes in block bindings

Is it okay to modify the image render callback like this? It solves the issue when a link is not part of the save.js, but it is defined by the binding during the rendering.

Add context needed by block bindings sources during its processing

Is this approach correct?

Simplify the HTML replacement logic until the HTML API is ready

Is it worth it and safe to make this change until the HTML API is ready?

Notify on save when users edit the value of a connected custom field instead of the post content

Does this make sense? How this should/could work?

[fabiankaegy]

Hi all 👋

Reminder: The release candidate for Gutenberg Version 18.5 is scheduled for next Friday (May 31st). So anything that is supposed to make it into WordPress 6.6 must be merged by then.

Please raise any important issues that need additional attention :)

[SantosGuillamot]

Merged PRs

Since the last update, some of the mentioned PRs have already been merged:

• ✅ Use block bindings editing APIs in pattern overrides: It helped to identify what is needed for the editor APIs, it simplified the pattern overrides implementation, and it addressed some challenges.
• ✅ Add block bindings panel to the inspector controls: This is the first step to bring more clarity when a block attribute is bound.
• ✅ Simplify the HTML replacement logic until the HTML API is ready: Code improvement to easily understand the processing until the HTML API is ready.
• ✅ Remove not needed breaks in gutenberg_block_bindings_replace_html: Code quality improvement.

Risks for 6.6

With Gutenberg RC scheduled for next Friday, I would like to bring up a potential risk of not having the functionality to allow editing of custom fields when connected to blocks ready for 6.6.

Basically, it depends on this other pull request to move the logic directly to the store, but we hit some blockers I am not sure how to solve. Please check the linked comment for more info about them.

While working on the initial pull request to allow editing, we realized that hooking into the Edit attributes (the current implementation), was causing some issues due to discrepancies when calling getBlockAttributes. Moving the logic directly to the store was already in our minds, so we decided to address it in this pull request trying to solve that problem. However, as mentioned, it is causing other issues as well.

If we are not able to overcome those blockers, I'm afraid the functionality to allow editing of custom fields might be at risk.

Apart from that, even if we solve them, I would say that the editor APIs are not ready yet to be public. Although it shouldn't be a problem to keep them private as they are right now.

Next steps

I would say that the next steps are trying to solve the mentioned issues and decide based on that. The focus will be on merging these pull requests:

• Move logic to core functions instead of using a hook.
• Allow editing in post meta source: If the previous PR is ready, I feel confident that we could land this one as well.
• Backports of the merged pull requests.

Apart from that, there is some work being done related to improving the UX of connected blocks:

• Notify on save when users edit the value of a connected custom field instead of the post content
• Adjust the icons and text of the binding connected blocks.

Finally, if the mentioned challenges are solved, we can push other important (although not 100% needed) aspects:

• Modify how we access context: editor & server. It may be affected by the refactoring.
• Improve and simplify the editor APIs to make them ready to be public.
• Add support to all content image and button attributes in block bindings: This should be more or less ready.

[ndiego]

Hi folks, I am working on some content for Synced Pattern Overrides, which depend on the Block Bindings API. I wanted to confirm that in 6.6, no additional blocks will be supported, but perhaps all image and button attributes will be supported (#61255). Is this correct?

[SantosGuillamot]

Yes, that's correct. However, taking into account the 6.6 deadline, I wouldn't expect the image and button attributes to be supported for the next release, either.

[SantosGuillamot]

Update before the beta phase

Now that the beta phase is here and we don't plan to add new functionalities, let's do an update of what we can expect from block bindings in 6.6.

Highlights

Editing custom field values directly from blocks when they are connected

This was one of the main focuses for this release cycle and, although we still have to improve the workflows and iterate on it, I believe it is in good shape for an initial version.

Some quick demos of what is possible with this implementation:

• Edit the value of the custom field from a block connected to it:

editing.demo.1.mp4

• When multiple blocks are connected to the same custom field, their value is synced:

sync.editing.mp4

• Custom fields can be updated from a query loop

query.loop.edit.mp4

• Users can only edit the custom fields from posts where they have permissions

permissions.mp4

Improve the UI to clarify when a block attribute is connected

Additionally, we made some improvements to the UI to ensure users are aware of which attributes are connected to which source, although there are still aspects to improve. The main new functionality here is a new panel in the block inspector controls that lists the block attributes and the sources. It is supposed to be a first step to allow users to create and delete bindings in an easier way.

Pattern overrides are using the block bindings API now in the editor as well

In this pull request, we moved the pattern overrides to use block bindings API in the editor and reuse the logic. It also helped to solve some issues the previous implementation was causing.

Polish the existing code

Apart from that, we took the opportunity to improve the existing code. The most relevant change here is how the implementation was improved and avoid the use of hooks: link.

Next steps

I consider the most important part is gathering feedback about these recent changes, especially regarding the UX, during the beta phase and addressing anything relevant.

Bug fixes

As mentioned, I expect the beta phase to trigger potential bugs after getting more testing, and we should focus on addressing them. So far, there are a couple of issues that could be considered bug fixes that we could work on:

• Remove "Site updated" message when editing custom fields: As discussed here, right now, when user edit a custom field value from a connected block and save it, it triggers the "Site updated" message apart from the "Post updated" one.
• Add a header to the bindings panel: Pointed by @cbravobernal , the new panel added to the inspector controls could benefit from having a "header" clarifying that the left part are the block attributes and the right one the binding sources. We should discuss if this make sense, how it should look like, and if we should include it in 6.6.

Follow-ups

Apart from the listed tasks in the tracking issue, these are some follow-ups and discussions we need to have, potentially for 6.7.

I can create different issues for each of them.

Improve editor APIs in order to make them public

One of the possibilities for this release cycle, was to open the editor APIs to allow external sources reuse them. However, after making some changes to adapt them to the new functionalities, we feel that we still need to iterate on them before making them public. For example, we need to review the existing properties, potentially merging setValue/setValues as discussed here.

We could also explore exposing them as experimental somehow to allow external sources to use it at their own risk.

Keep exploring how to handle the context needed by the sources

During this release cycle, we started working on improving the way we pass the needed context both in the editor and the server. However, it wasn't included because we still have to figure out the best way to do it.

Keep improving the UX to clarify the bound attributes

Apart from the feedback we receive during beta phase, as part of this process, it was discussed to add an indicator that an attribute is connected instead of hiding the controls. It needs to be discussed and implemented in more detail, but it'd be a good step forward on clarifying the process.

Improve the pre-publish workflow when editing a custom field

As discussed here, after merging this new functionality, we only notify users when a custom field has been modifying after saving a published post. However, it'd be great to explore how to integrate something similar in the pre-publish workflow, currently unmodified.

Review hasPostMetaChanges selector implementation

In this pull request, a new private hasPostMetaChanges selector was introduced to track if the post had changes in the meta fields. It was released as private because we expect to iterate on it and discuss potential improvements. For example, we need to discuss if it only applies to meta changes or other post data like title, excerpt, etc, when there are other binding sources to edit that.

Additionally, in the current implementation, there is a hardcoded workaround to skip footnotes that needs to be reviewed.

Decide what to do when pressing "Enter" or pasting a new block in a bound rich text

As discussed here, right now when a user presses "Enter" it creates a new block, and pasting another block is disabled. I believe it is good enough for a first version, but we need to explore and discuss how the ideal workflow is.

Explore abstracting the changes needed for bindings in the ItemGroup component`

As discussed here, some styles specific to block bindings panel were added, but it'd be great to explore if it makes sense to create some abstraction in the components used to allow other users to benefit from that.

Add support for all images and button attributes

We started exploring how to do this in this pull request. However, there were still some improvements to be made and it didn't make it in time for 6.6.

Should we move the block bindings logic to core functions in the store

In this pull request, we started exploring the possibility of moving the logic to getBlockAttribues and updateBlockAttributes instead of using a hook in the Edit component.

However, it triggered some challenges and concerns:

• It isn't clear if we always want to return the "bindings" value instead of the "fallback" value. We need to explore the different use cases better. One possible solution could be creating a new util that returns the bound values and let users decide when to use getBlockAttributes or this new util.
• It isn't clear how to access the block context from these functions. Block binding sources need to access the block context in order to process the value. For example, "Post meta" need to access the postId and the postType. However, accessing it from the store it is tricky. We explored the possibility of syncing it with the store, but we aren't sure about that approach either.

Should we include adding the __default possibility for all sources or just pattern overrides?

This pull request added the possibility of just passing a __default option to the bindings object that applies to all the supported attributes. However, it just only works for pattern overrides. For that specific use, it makes sense. But we need to discuss if we should open this possibility for other use cases as well.

[gziolo]

Excellent update @SantosGuillamot. It looks like there isn't much work left for WP 6.6 as we know only about two of them. It would be great to file issues for them to have better space to discuss the next steps and an easier way to track progress in the WP 6.6 project. There is a large list of potential work for 6.7 so it feels like we should start planning the Iteration for WP 6.7 where we will have to set proper priorities taking into account that we also need to add support to more block binding sources and continue iterating for the UI that eventually allows setting the bindings in the UI.

[artemiomorales]

Thanks for the update @SantosGuillamot!

Remove "Site updated" message when editing custom fields: As discussed #61811 (comment), right now, when user edit a custom field value from a connected block and save it, it triggers the "Site updated" message apart from the "Post updated" one.

I've created an issue for this and will work on a fix: #62236

[juanmaguitar]

@SantosGuillamot, as per this comment, I added the Needs Dev Note label because I think it would be helpful for developers to share how the workflows for working with Block Bindings have been improved in WP 6.6.

I agree with @fabiankaegy in this comment

I think the fact that the post meta bindings are now editable in line deserve a quick dev note. Even if there are no actual API changes.

To add more context, there is no existing end user documentation for Block Bindings; only the DevNote and some posts in the Developer Blog are available:

• New Feature: The Block Bindings API - DevNote
• Introducing Block Bindings, part 1: connecting custom fields - Developer Blog post
• Introducing Block Bindings, part 2: Working with custom binding sources - Developer Blog post