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

---

Beta phase fixes

• Fix site editor breaking when user selects bound and non-bound blocks at the same time.
• Fix applying bindings or pattern overrides to button blocks with empty text.
• Revert changes to replacement logic to prevent reported bugs: Gutenberg & Core.
• Change bindings panel title and add description.
• Fix showing double icons for connected blocks.
• Pattern Overrides: Prevent normal attribute updates when a __default binding exists.
• Remove connections icon and fix padding.
• Add e2e test to ensure block bindings work well with symbols and numbers.
• Only run block bindings Gutenberg logic for sites using WordPress versions below 6.5.
• Use preview instead of publishing post in block bindings tests.
• Pattern overrides: disallow override for image with caption/href.
• Pattern Overrides: Unable to set some attributes like Image block Aspect Ratio when editing the original pattern
• Ensure custom field changes work fine with revisions.

[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

Update: Discussion will happen here.

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

Update: related issue #62329

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`

Update: related issue #62330

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

Update: Related issue #63014

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

[cbravobernal]

We could also work on Adding support for revisions for custom field values.

[SantosGuillamot]

Okay, we will work on a dev note 🙂 I wasn't sure if non-developers topics should be covered in a dev note or other type of posts.

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.

Just to clarify this: The developer workflows haven't been improved for 6.6. They remain the same. We just allowed now editing for the core "Post meta" source (not for external sources) and added a few tweaks to the UI.

[SantosGuillamot]

We could also work on Adding support for revisions for custom field values.

I totally agree it'd be great to support this kind of change in revisions. If I am not mistaken, right now, it creates a revision but it doesn't show any changes. I assume that could be considered a bug?

[cbravobernal]

If it's creating a revision and there is no way to see it, it could be. Yes

[gziolo]

We could also work on Adding support for revisions for custom field values.

Here is the dev note authored by @adamsilverstein: Framework for storing revisions of Post Meta in 6.4. It looks like revisions can get enabled magically with revisions_enabled flag during registration. In effect, my hunch is that there would need to be a special UI to surface these revisions that would allow reverting changes from the previous revisions.

[juanmaguitar]

Just to clarify this: The developer workflows haven't been improved for 6.6. They remain the same. We just allowed now editing for the core "Post meta" source (not for external sources) and added a few tweaks to the UI.

@SantosGuillamot TBH, I’m split down the middle on the need for a DevNote for this Issue. I think a brief note on a larger "Misc Dev Notes" post would be nice (as it enhances the work and experience with the The Block Bindings API), but not having a DevNote would also be OK.

I'll keep the Needs Dev Note for now, but I'll leave it up to you whether to share a DevNote or not. Both options will be fine 🙂

[SantosGuillamot]

Regarding revisions, I just realized there is a closed ticket (as wontfix) and a linked pull request trying to solve the problem we are facing. I can take a look to see if we should reuse that or how to proceed.

[SantosGuillamot]

I just opened a potential pull request for the revisions issue, and I left a comment in the closed ticket to discuss how to proceed.

[SantosGuillamot]

@juanmaguitar I've started this quick note explaining the new workflows related to editing custom fields from connected blocks. It is basically a summary of the latest update on this issue.

I'll let you decide if it should be a Dev Note, if it should go in another place, or if it doesn't even make sense at all. And I'm happy to apply any changes you consider necessary as well.

[SantosGuillamot]

Latest fixes during beta

Since the last update, a bunch of pull requests fixing bugs and polishing the UI were merged:

• Fix site editor breaking when user selects bound and non-bound blocks at the same time.
• Fix applying bindings or pattern overrides to button blocks with empty text.
• Revert changes to replacement logic to prevent reported bugs: Gutenberg & Core.
• Change bindings panel title and add description.
• Fix showing double icons for connected blocks.
• Pattern Overrides: Prevent normal attribute updates when a __default binding exists.
• Remove connections icon and fix padding.
• Add e2e test to ensure block bindings work well with symbols and numbers.
• Only run block bindings Gutenberg logic for sites using WordPress versions below 6.5.
• Use preview instead of publishing post in block bindings tests.

Apart from that, there are other two pull requests started:

• Add support to image caption attribute in block bindings (Core & Gutenberg): This is needed to solve an issue caused by not supporting the caption: link. However, the implementation needs to be discussed further before including the fix in the beta phase.
• Show post meta fields in revisions panel: This one will probably require further discussion on the best approach, so it could be delayed until 6.7.

[juanmaguitar]

I've started this quick note explaining the new workflows related to editing custom fields from connected blocks. It is basically a summary of the latest update on this issue.

@SantosGuillamot yes I think we should publish it but without the "DevNote" tag. I've pinged you via Slack to move forward with this.

[SantosGuillamot]

I'm closing this iteration issue because we don't expect to work on anything new for 6.6. I have just opened a new iteration for 6.7, including the follow-ups from this one.

[juanmaguitar]

For reference, the post Editing custom fields from connected blocks was published on make.wordpress.org/core