gutenberg icon indicating copy to clipboard operation
gutenberg copied to clipboard
verified publisher icon WordPress

Block Bindings: Iteration for WP 6.6

Open SantosGuillamot opened this issue 1 year ago ā€¢ 20 comments

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
  • Editor APIs
  • Core sources
  • [x] Use block bindings editor API to update pattern overrides.
    • https://github.com/WordPress/gutenberg/pull/60721
  • [x] Support editing in "Post meta" source.
    • https://github.com/WordPress/gutenberg/pull/61753

Beta phase fixes

SantosGuillamot avatar Apr 22 '24 12:04 SantosGuillamot

Update

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

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?

SantosGuillamot avatar May 06 '24 14:05 SantosGuillamot

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 :)

fabiankaegy avatar May 21 '24 14:05 fabiankaegy

Merged PRs

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

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:

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

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

SantosGuillamot avatar May 22 '24 15:05 SantosGuillamot

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 (https://github.com/WordPress/gutenberg/pull/61255). Is this correct?

ndiego avatar May 28 '24 14:05 ndiego

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 avatar May 29 '24 07:05 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:

https://github.com/WordPress/gutenberg/assets/34552881/d1d057d7-788f-46ec-b5a4-32cba9103e87

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

https://github.com/WordPress/gutenberg/assets/34552881/31644bfe-5ff5-420c-a9c6-f86c12bbf795

  • Custom fields can be updated from a query loop

https://github.com/WordPress/gutenberg/assets/34552881/eee965d1-4b3a-4e4d-bcee-add69564f88e

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

https://github.com/WordPress/gutenberg/assets/34552881/b29b498b-836f-4db3-9270-11503e2d3a6d

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.

Screenshot 2024-06-03 at 10 42 56

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 https://github.com/WordPress/gutenberg/issues/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 https://github.com/WordPress/gutenberg/issues/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 https://github.com/WordPress/gutenberg/issues/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.

SantosGuillamot avatar Jun 03 '24 10:06 SantosGuillamot

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.

gziolo avatar Jun 03 '24 11:06 gziolo

Thanks for the update @SantosGuillamot!

Remove "Site updated" message when editing custom fields: As discussed https://github.com/WordPress/gutenberg/pull/61811#issuecomment-2141748869, 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: https://github.com/WordPress/gutenberg/issues/62236

artemiomorales avatar Jun 03 '24 12:06 artemiomorales

@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:

juanmaguitar avatar Jun 03 '24 16:06 juanmaguitar

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

cbravobernal avatar Jun 03 '24 19:06 cbravobernal

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 avatar Jun 04 '24 08:06 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?

SantosGuillamot avatar Jun 04 '24 08:06 SantosGuillamot

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

cbravobernal avatar Jun 04 '24 09:06 cbravobernal

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.

gziolo avatar Jun 04 '24 12:06 gziolo

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 šŸ™‚

juanmaguitar avatar Jun 04 '24 12:06 juanmaguitar

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 avatar Jun 04 '24 13:06 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 avatar Jun 05 '24 08:06 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 avatar Jun 07 '24 11:06 SantosGuillamot

Latest fixes during beta

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

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.

SantosGuillamot avatar Jun 17 '24 10:06 SantosGuillamot

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.

juanmaguitar avatar Jun 28 '24 12:06 juanmaguitar

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.

SantosGuillamot avatar Jul 01 '24 12:07 SantosGuillamot

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

juanmaguitar avatar Jul 01 '24 13:07 juanmaguitar