Connecting block attributes and custom fields & Block Bindings API for WP 6.5

[SantosGuillamot]

Part of:

• Block API #41236
• Custom fields connected to Blocks #51373
• Block Bindings API iteration for 6.5 #54536

Related to:

• Pattern Overrides epic (WordPress 6.5) #53705.
• Create a system for inserting site/post metadata into generic blocks #37753.
• Inline Dynamic Content Solutions #21932.

---

EDIT: Connecting block attributes and custom fields, and the block bindings API tracking issues have been merged into this epic because they are highly related and it seems it is easier to follow having everything under the same discussion.

This issue is meant to keep track of and discuss how to connect block attributes with custom/meta fields and how Block Bindings API should work. It includes a list of tasks needed for this, and we will share updates about the progress here.

• Block Bindings API: Internal API to connect block attributes and different sources. Not only used for custom fields but for other projects like Partially Synced patterns.
• Custom Fields: Using the Block Bindings API, support for the "meta_fields" source to connect block attributes and custom fields.

For more context about the reasoning of the block bindings API, you can take a look at its original tracking issue.

Progress

This is a list of things to consider/questions related to the Block Bindings API that will be updated as we go along:

WordPress 6.5 release process

Click to see the list of issues addressed during 6.5 release cycle

---

A couple of things that are important:

• This project depends on the Block Bindings API: link.
• We will start supporting just a few core blocks attributes that can be increased in a later phase. We can start with:
  • Paragraph content.
  • Heading content.
  • Image URL.
  • Button link and content.

Fixes/updates for Gutenberg 17.6 RC (Tuesday 30th)

• Decide the final name of the public class and methods included in this pull request.
• Migrate all the changes suggested in this wordpress-develop pull request to Gutenberg, including the naming decision. #58383
• Decide the final shape of the bindings object used in the blocks and make the necessary changes: #58337
• Backports to WordPress.
• Add more tests for the bindings, especially in the editor.
• Add validation in the WP_Block_Bindings_Registry class like others like WP_Block_Type_Registry are doing: link.

Fixes/updates for WordPress 6.5 beta 1 (February 13th)

• Review the accessibility of the editor with the accessibility team, including the suggestions made: link.
  • Rich Text: Add aria-readonly attribute to Rich Text component #58687 (review)
• Migrate to Gutenberg the changes made in this core pull request: link. PR: #58683
• Fix a bug with strcasecmp reported here.
• Decide if we should add a WP_Block_Binding_Source class and handle validation there: link. PR: #6042 / Core changeset: 57562
• Refactoring the processing of block bindings into two steps: link. This would solve this issue with the empty images in pattern overrides. PR: #6059
• Add initial documentation. Core changeset: 57560
• Remove unused setAttributes. PR: #58806
• Lock editing by default when the source used in the bindings is not registered in the client and adapt pattern overrides. PR: #58787

Fixes/updates during beta phase

• Fix the way context is added as discussed here. Core / Gutenberg PR
• Remove unnecessary queryId in context: link. Solved as part of Core / Gutenberg PR
• Create a guide about using block bindings. Discussion: 219. Guide part 1.
• Fix metadata attribute not being preserved after block transforms: link. PR: #59179
• Fix query loop not working as expected in the editor when blocks are bound. PR #59283
• Improve the accessibility of the block bindings:
  • Block Bindings: Pressing Enter from connected block doesn't move focus to the newly created block. #58674
  • Block Bindings: UI components that show connected values should be readonly and not disabled #58673
• Review the use-bindings-attributes hook and improve its implementation. As part of that, we should address link. PR with the refactoring: #58895
• Fix insert button when pressing enter in bound blocks. #59361
• Don't show protected meta fields. PR #59326 / Core ticket #59326
• Dev note covering how extenders can use the block bindings.
• Review the current UX and make further improvements: link.
  • Add visual indicator if a block is connected to block binding source #59185
  • Change default "Connected to a custom field" message in bindings #59434
  • Block Bindings: Remove Block Bindings icon from List View, fixes and CSS updates. #59477

WordPress 6.6 planning

This section will be used to keep track of the issues that could potentially be addressed for WordPress 6.6.

As explained in this comment, the idea is to keep the scope limited and work on more functionalities if there is time at the end of the release cycle.

Initial plan

Keep in mind that this is not set in stone and it might change. The initial idea is to focus on these aspects:

Polish the existing code

• Add hook to check when we should lock controls when bindings exist: link.
• Use RichText identifier to check if we should make it non-editable: link.
• Explore how to abstract the locking of controls: link.
• Remove the filter when a source is unregistered as discussed here.

And work on new aspects like:

• Add the possibility of editing the value of the meta fields directly from the bound blocks.
• Improve the UX when the editing of bound blocks is locked.
• Define and implement UX for editing custom fields directly from blocks connected.
• Add support for more core blocks based on feedback. #59607

Out of scope for 6.6

Trying to keep the scope limited for this short release, the idea is to work on these functionalities only once the previous points are finished:

• Add a UI to allow users to add bindings through the Editor.
• Create new sources: Site data, post data, taxonomy data.
• Explore the possibility of creating a filter to modify the value of the meta field returned. Ex: Change the date format with PHP.
• Explore the possibility of concatenating custom fields somehow. Ex: site_url + field_id.
• Explore the possibility of creating "before/after" setting until an Inline Binding functionality is implemented.
• Replace core blocks like Post Author to use variations using these bindings.
• Create opt-in mechanism and expand support for custom blocks (This depends on the HTML API supporting any HTML tag).
• Change the UI to use the upcoming DataViews: link.
• Probably using DataViews, add the possibility of creating new custom fields.

[SantosGuillamot]

Initial experimental MVP

We can start with a simple experimental version, that can be activated through Gutenberg → Experiments, to kick off the project. We can aim to just:

• Connect the paragraph content and the image URL through an object in the block attributes. Just by having the following block attribute, it should display the value of the custom field in the frontend:

<!-- wp:paragraph
    { 
        "connections": {
            "attributes": {
                "content": { 
                    "source": "meta_fields",
                    "value": "my_custom_field"
                }
            }
        }
    }
-->

Keep in mind that this is just an example, and we have to discuss how the API should look. Additionally, it might require adding support for these connections in the block itself.

• Have a really basic UI to add those connections and select the custom field we want to connect.

For this first experimental MVP, I would leave out of the scope:

• Don’t support reading/writing of the custom field values from the editor: We wouldn’t be able to read the value of the custom field or update its value from the editor. We could use a placeholder in the editor (in the frontend it should show properly). Making it work in the editor is trickier, and we might hit some blockers that can be solved in next iterations.

• Don’t show a list of available custom fields: For the same reason, I propose using a text input and keeping the user responsible that it matches an existing custom field in this initial phase.

[Mamaduka]

By the way, the meta attributes source was only deprecated in WP 5.4, and core still maintains backward compatibility.

I wasn't actively involved in the project then, so I don't remember the reason for the deprecation. We should probably dig up old PRs and check.

[SantosGuillamot]

I wasn't actively involved in the project then, so I don't remember the reason for the deprecation. We should probably dig up old PRs and check.

Thanks a lot for sharing! 🙂 I've been taking a look at the old PRs and it seems the deprecation was added in this pull request: link. I've been reading the different conversations and, as stated in the Dev Notes, it seems it was deprecated in favor of the EntityProvider. Which is supposed to "provide a more flexible and powerful way for building blocks that source data from different properties of WordPress entities and data." But I wasn't involved in the project either, and I couldn't find too much information, so I might be missing something.

Anyways, I believe the case here is slightly different than the meta attributes source. In this case, we want that block attributes that are not usually connected to meta fields, can do it if the user wants. If we take the paragraph content as an example, it uses source: html. In most cases, users will want to use the paragraph block as it is used right now but, if wanted, this would offer the possibility to connect it to a meta field (Post Excerpt for example) through a UI in the editor.

Apart from that, blocks using the old meta source would keep working as well. It's just that those attributes wouldn't have the UI to connect to a different meta field. If we consider this a need, we could explore how to support that too in the future.

[michalczaplinski]

I've opened the PR to allow connecting the url attribute of the Image block to Custom Fields:

• Allow connecting "url" and "title" attributes of the Image block to custom fields. #53488

[gziolo]

By the way, the meta attributes source was only deprecated in WP 5.4, and core still maintains backward compatibility.

@mcsf should be the best person to contact, in case you need to know the details. Here is the initial implementation #2740.

[mcsf]

It's been a long time and my memory is fuzzy, but I believe the original meta source was deprecated due to a combination of:

• Gutenberg betting on and consolidating its data needs around Entities as introduced in 2019
• suboptimal performance and/or ergonomics of the meta source compared to normal attributes
• general lack of interest for post meta as an attribute source (newcomers were likely to not use them, whereas heavy users of meta were likely to not use the block editor) weighed against the cost of maintaining that specific source, which IIRC was a bit shoehorned into parts of the block API

[youknowriad]

I think the main problem of the meta source compared to this new proposal is that it requires folks to actually write a new block by explicitly marking a given attribute as a "meta" attribute. While this new proposal allows setting the source as an attribute of existing blocks (no need to write new blocks).

[glendaviesnz]

@SantosGuillamot, @Poliuk I have added a tracking issue for partial syncing, which is going to have some overlap with this work.

[SantosGuillamot]

I wanted to share an update on the work done till now:

Done

The first implementation to connect the paragraph content with custom fields has been merged. It is a really basic MVP that will let us build the rest on top of it. Bear in mind that it's just an MVP to test the technical part, it will change, especially the Editor UX. This is a quick demo of how this initial version works:

I created a custom field "custom_text" with a value "Custom Text Value"

Paragraph.connection.demo.mp4

Apart from that, there is an ongoing PR to be able to connect the Image block URL as well: link.

Additionally, @glendaviesnz has started experimenting with the possibility of using this mechanism for the Partially synced patterns, and he created a tracking issue for that work: link. According to the first impressions, it seems it could work.

Next steps

The potential immediate next steps could be:

• Finish the work to add support for the Image URL attribute.
• Add support for the Image title attribute. I believe this one could be special because the title is usually stored in a meta field that is an object. Adding a new image usually creates two meta fields: _wp_attached_file and _wp_attachment_metadata. The first one contains the image url, but the second one is an object that contains some attributes like the title. For this reason, I believe we can use it to explore how to retrieve/modify the data from a meta field that is an object.
• Investigate how to read/write the custom fields in the editor. Even if we don’t have a proper UX for it yet, there is a technical challenge to research/decide what to do with the show_in_rest limitation. We need to explore different ways of overcoming this limitation. Maybe we can change the API so, if you are an editor, it shows you all the fields. Or not retrieving that data from the REST API and doing it in PHP somehow. I didn’t think too much about it, that's what the research would be about.
• We could work on a fallback mechanism in case that value doesn’t exist. This could be especially interesting for templates and patterns.
• Keep investigating how this mechanism could be used for WP Pattern.

[michalczaplinski]

To reflect the general nature of the feature that goes beyond just custom fields, @SantosGuillamot and I propose to call it "Block Bindings".

• Calling the project "Custom Fields" when the custom fields are only one of the use cases does not make much sense.
• There is prior art for the term binding used in a similar technical sense (e.g. data binding in frontend UI frameworks)
• It rolls off the tongue nicely 😄

The name should not be taken as final, but more as a codename that gives us a way to refer to the combined effort in a consistent way.

[sc0ttkclark]

Majorly agree with thinking beyond custom fields here, binding could be useful for other use cases too

[SantosGuillamot]

After thinking about it and working on the first implementation of custom fields, I believe we can differentiate between Block Bindings API and Custom Fields:

• Block Bindings API: Internal API to connect block attributes and different sources. Not only used for custom fields but for other projects like Partially Synced patterns.
• Custom Fields: Using the Block Bindings API, support for the "meta_fields" source to connect block attributes and custom fields.

Having this distinction should help clarify each project's scope and how they are related. Let us know if it is clear enough.

I've updated the opening comment to reflect that and moved part of the discussion to the Block Bindings API issue.

[SantosGuillamot]

Initial version for WordPress 6.5

We want to include an initial version of the binding between Custom fields and Blocks in WordPress 6.5. We have already experimented with the implementation as explained before, and we feel confident enough to start working on a version meant to be included in WordPress 6.5.

Goal

As a reminder, this feature aims to create a simple way of connecting block attributes and Custom fields/metadata. Imagine something like this:

Bear in mind that the UI still needs to be discussed, this is just for explanation purposes

Custom.Fields.demo.mp4

These bindings are especially helpful when the value of the metadata changes depending on the context. For example, in a Query Loop or inside a template. Imagine a user wants to create a Query Loop of movies like this one:

Right now, they would need to create custom blocks for the release date, the runtime, the trailer button, or any other info related to the movie.

With this initial version, users could bind blocks with custom fields, whose values can easily be changed for each movie, simplifying the process a lot. They would just use a Query Loop with core blocks connected to custom fields:

Proposal for 6.5 release

The whole Custom Fields & Blocks project could be pretty big as it covers many things. I believe we can start small and implement new functionalities progressively. This way, we add value to the users and receive feedback as soon as possible.

I'm sharing the phases that I consider realistic for 6.5. But as I mentioned, we can approach them one by one and get as far as possible. If we only reach phase 2, that would already be much better than what we have now and can be improved in later releases.

I'm including some orientative things/questions that we should consider for each phase, although we will edit this issue once we progress and discover what other things we need to do, and some might be postponed to later phases.

Progress and updates relative to these tasks will be shared in the opening post.

1. Be able to connect block attributes and custom fields without a UI

The idea is that users can add the binding through a new "bindings" block attribute. A couple of things that are important at this point:

• This project depends on the Block Bindings API: link.
• We will start supporting just a few core blocks attributes that can be increased in a later phase. We can start with:
  • Paragraph content.
  • Heading content.
  • Image URL.
  • Button link and content.

With that in mind, this is the list of things to consider:

• Implement the metadata source used by the Block Bindings API.
  • Which metadata should it cover? Site data, post data, taxonomy data, custom fields, user data...
• Mechanism for block attributes to opt-in for these bindings.
• Add tests.

2. Include a basic UI to create these bindings where we can read the metadata value

We can start with a basic dropdown as the one shown in the video without the possibility of editing its value.

• Mechanism to get the available metadata fields in the Editor.
  • Should we use the REST API? Any other methods we should consider?
  • If we use the REST API, should we reconsider changing the default value of show_in_rest for new fields?
• Implement basic UI to select the existing metadata.
  • Should we use the same UI for all block attributes or each one should have a different one.
• Add tests.

3. Add the possibility to edit the value of the meta field directly through the Editor

• Explore how to handle user permissions. A user might be able to read the meta value but not write it, for example.
• Implement UX to let users know they are editing a meta field instead of the block's content.
• Add tests.

4. Add support for more core blocks we consider important

Once we feel confident enough about the solution, we can focus on adding support to more core blocks.

---

With these phases, there is already a lot of work for 6.5. For the next releases, we can keep working on this, work on the remaining tasks, and explore the possibility of addressing new ones like:

• Explore the possibility of adding new functionalities:
  • Concatenate custom fields somehow. Ex: site_url + field_id.
  • Create "before/after" setting until an Inline Binding functionality is implemented.
  • Create a filter to modify the value of the meta field returned. Ex: Change the date format with PHP.
• Change the UI to use the upcoming DataViews: link.
• Probably using DataViews, add the possibility of creating new custom fields.
• Replace core blocks like Post Author to use variations using these bindings.

Anyway, we can analyze this deeply once 6.5 is out, and we have a better picture. Or even reconsider including some of them in 6.5 if we feel they are important enough.

I've updated the opening post to reflect this

[lgladdy]

@SantosGuillamot This looks good! How do you think existing meta will work with this? Will there be some way to mark a meta field as one which should be shown in the list of bindable fields?

ACF currently uses the legacy metabox support for page-wide meta, but if we can add a "progressive enhancement" way for meta to be updated live as users change fields, we could do that so their changes from ACF are visible on bound attributes immediately - this would require a JS api for trigging meta value update events which is subscribed to by each block which uses one.

1. Be able to connect block attributes and custom fields without a UI

Mechanism for block attributes to opt-in for these bindings.

Assuming this will be a way for other blocks and third party blocks to allow an attribute of theirs to be selected from the "link" button from a meta field?

2. Include a basic UI to create these bindings where we can read the metadata value

Mechanism to get the available metadata fields in the Editor.

The REST makes sense here I think, but there should be a way for third party plugins (like ACF) to add fields to it. For legacy data and field location reasons, ACF doesn't use register_field - so we'd have to add support for this by hooking in our fields as available here.

Should there be a way to specify which fields are available to which blocks? For example you'd only want compatible image fields to be possible to set as the source of an image.

[decodekult]

Sorry for the half-spam here. This same ability is provided by Toolset over its Dynamic Sources.

I was the team leader for Toolset when this was developed back in 2020-2021, if anyone here is interested I could name a couple of devs who could provide precious feedback on implementation ideas and edges found during that phase.

[SantosGuillamot]

@lgladdy Thanks a lot for those questions! I'll try to address them one by one but I wanted to note first that we still have to discuss and decide most of the things 🙂

How do you think existing meta will work with this? Will there be some way to mark a meta field as one which should be shown in the list of bindable fields?

On the PHP side, we considered accessing the value of the meta fields using the get_metadata function or get_post_meta. Are ACF accessible through that function?

On the editor side, one idea was to use the REST API to get the list of available fields for a given context. I assume that any field exposed there should be available in the list of bindable fields.

Apart from that, if plugins need something more custom, we were thinking of creating a mechanism to add different sources in the Block Bindings API. For example, we could explore the possibility of having an "ACF" source if we feel that a better approach.

Anyways, it's something we have to explore deeper, and we have to understand better how plugins like ACF work.

this would require a JS api for trigging meta value update events which is subscribed to by each block which uses one.

This could make sense 🙂 Adding it to the list of things to consider.

Mechanism for block attributes to opt-in for these bindings.

Assuming this will be a way for other blocks and third party blocks to allow an attribute of theirs to be selected from the "link" button from a meta field?

The end goal is that any block can decide which attributes can be connected. But for this first version, we will limit it to just a few core blocks where everything is under control. Making the bindings work in any block is a bit trickier and should be done cautiously. There is more info about this in the block bindings API issue.

but there should be a way for third party plugins (like ACF) to add fields to it. For legacy data and field location reasons, ACF doesn't use register_field - so we'd have to add support for this by hooking in our fields as available here.

Totally agree here. We have to ensure that whatever we provide works as smooth as possible with plugins like ACF.

Should there be a way to specify which fields are available to which blocks? For example you'd only want compatible image fields to be possible to set as the source of an image.

We should definitely explore that possibility and analyze how to handle types and that validation. In my opinion, that could be done in a later phase. In the meantime, we can use the own block as the "validator". For example, if I connect an image to a field that is not a URL, the block will fail and return an error. I created a quick video to show what I mean:

Wrong.URL.field.mp4

---

Sorry for the half-spam here. This same ability is provided by Toolset over its Dynamic Sources.

I was the team leader for Toolset when this was developed back in 2020-2021, if anyone here is interested I could name a couple of devs who could provide precious feedback on implementation ideas and edges found during that phase.

@decodekult That looks great! All the feedback we receive, regarding the UX, things to consider, or the development, is more than welcome 🙂

[lgladdy]

Thanks for the reply @SantosGuillamot! This is all logical.

I'm more than happy to help work on the code here too, and will try to make sure ACF is good to go at launch too. I'm passionate about making meta work better in the block editor, so anything I can do to help here I will!

On the PHP side, we considered accessing the value of the meta fields using the get_metadata function or get_post_meta. Are ACF accessible through that function?

On the editor side, one idea was to use the REST API to get the list of available fields for a given context. I assume that any field exposed there should be available in the list of bindable fields.

Specifically with your question on ACF here, yeh - get_post_meta will give you ACF's raw database value, so we'd want to add a layer on top here (maybe by a final return filter on the PHP side?) to intercept and translate accordingly (that's things like return formats for data/time strings etc)

Apart from that, if plugins need something more custom, we were thinking of creating a mechanism to add different sources in #54536. For example, we could explore the possibility of having an "ACF" source if we feel that a better approach.

This would be cool, not just for ACF but the other meta plugins. If plugins could register themselves as a source for meta, and can handle the meta available to that location somehow.

[dinhtungdu]

Be able to edit the value of the custom fields when a binding exists: The functionality has been coded with this in mind, but it wasn't included in this initial version to ensure it works as expected.

@SantosGuillamot do we have any issue/discussion for this one specifically? I can't find one in the repo.

If we haven't already, I'd strongly recommend that we include the updating behavior of the custom field in Site Editor > Pages. For now, we can edit only the title and content of the page. But if we can also edit the custom field value there, it'd be a truly WYSIWYG editing experience. Btw, editors working on content only won't have to worry about breaking the template.

Also, in the future, if we support not only pages but other post types to be edited in the Site Editor, we can have live-editing experiences for any type of content on the site, like products or events.

I'm super excited for the future of editing with Custom fields and Blocking Binding API. Thank everyone involved for the amazing work!

[fabiankaegy]

@dinhtungdu in order to have other blocks besides the featured image, title, and content editable we need to solve #59290

[SantosGuillamot]

@SantosGuillamot do we have any issue/discussion for this one specifically? I can't find one in the repo.

I opened this experiment to explore how it could work, and it was also explored in this refactoring.

I am confident that it is feasible, and it worked nicely in the testing. It is something I'd definitely like to explore deeper. However, I believe it was premature to include that possibility in WordPress 6.5. There are still some uncertainties we need to clarify before adding that functionality, and it seemed better to wait to ensure that whatever lands work as expected and it is backward compatible.

[SantosGuillamot]

Update - Changes made during WordPress 6.5 beta phase

Now that the beta phase has finished and we can only expect to fix critical bugs, it's time to make a summary of the most important issues addressed during this period.

• Fix the way context is added as discussed here. Core / Gutenberg PR
• Fix metadata attribute not being preserved after block transforms: link. PR: #59179.
• Fix query loop not working as expected in the editor when blocks are bound. PR #59283.
• Fix insert button when pressing enter in bound blocks. #59361.
• Don't show protected meta fields. PR #59326 / Core ticket #59326.
• Improve the UX of block bindings: 59185 & #59434
• Improve the accessibility of the block bindings: #58674 & #58673.
• Don't use hooks conditionally: PR #59403.

Apart from that, some resources to understand better the custom fields and bindings were created:

• Dev note: The Block Bindings API.
• Introducing Block Bindings, part 1: connecting custom fields.
• Introducing Block Bindings, part 2: Working with custom binding sources.

---

From here, I'll wrap up WordPress 6.5 in the opening comment and I'll transform this issue into an epic issue to track the upcoming releases for both the custom fields project and the block bindings API. They are highly related and it seems it is easier to follow if the discussions happen in the same place.

Additionally, I plan to post another comment with ideas for WordPress 6.6 and update the opening comment as well.

[SantosGuillamot]

Potential plan for WordPress 6.6

Now that WordPress 6.5 is almost out, it's time to start planning for 6.6.

It is important to keep in mind that this is a short release. WordPress 6.6 Beta 1 estimated date is the 4th of June. And I believe we should aim to have things ready two weeks before to test it properly in Gutenberg. That leaves us a couple of months.

For that reason, I'd like to keep the scope tight and work on other things progressively if there is enough bandwidth in the end.

Having said that, these are the issues I would consider more important:

• Polish the existing code with potential improvements that weren't included in WordPress 6.5.
• Address important feedback we might receive now that users will start using the different functionalities.
• Add the possibility of editing custom fields (or other block bindings sources) directly through the block when it is connected to post meta data. This requires a deeper exploration of the requirements, UX, etc.
• Related to the previous point, the UX might need to be improved. Not only for the editing of custom fields but also when the editing is locked.
• Add support for more core block attributes based on feedback.

I believe that, if this is shipped in WordPress 6.6, it'd be a great iteration over the existing functionalities.

From there, if we feel confident and there's still time, we can work on other aspects like the following ones. But I'd consider them out of the scope for now:

• Add support for other core sources like site data or taxonomy data.
• Add a UI to create the bindings in the visual editor instead of using the code editor.
• Explore how to overcome the show_in_rest limitation. Right now, only fields with show_in_rest set to true are available. And that is false by default.
• Add new functionalities like concatenating bindings or other strings.

Having said that, any feedback is more than welcome. And it's important to note that the planning might change based on that 🙂

As usual, we'll try to keep the opening comment updated with the progress and we'll publish updates in this thread.

[lgladdy]

@SantosGuillamot I feel like the UI to add bindings is probably more important than things like updating the values.

Right now, there's a risk of third party plugins creating their own binding UI and we end up with loads of different variations per binding source plugin.

I'd rather spend time contributing towards that goal in core than try to ship something sooner in ACF. It's also the one question we've had most on our team with our experimental binding support plugin. It was also the first question on the wptavern article on bindings where someone asking how to create their own UI for adding a binding.

[ndiego]

Right now, there's a risk of third party plugins creating their own binding UI and we end up with loads of different variations per binding source plugin.

I agree with this, and it's the first thing I thought about building 😅 Creating a standardized UI that plugin developers can extend is very important.

[SantosGuillamot]

Thanks a lot for your feedback 🙂

I agree having a UI to create bindings that can be extended by plugin developers is really important. And you made really good points. Let me share some of the reasons why I considered working on the editing part first:

• Having the possibility of editing the value of the custom fields (or other sources) when a block is bound, is needed for core sources like pattern overrides.
• Additionally, once that is done, it should allow us to open to editor APIs to be used by external sources as well. Something that is limiting right now because they can only extend the server side.
• The integration of bindings with the classic meta box to edit custom fields is kind of broken. This should solve that part as well.
• There are already working prototypes of how editing the value of custom fields could be implemented.
• Considering this is a short release, and that we also need to polish the existing code and UX, adding the possibility of editing the value of custom fields seems more feasible than creating a UI that can be extended by plugin developers. Creating that UI seems to me like a big challenge with many uncertainties yet.

Having said that, we should probably start exploring how it could look like and how it could be implemented, but I’m not sure if it’s feasible to have it for 6.6. I’m just trying to be realistic given the resources we’ve had till now for this project. I’m more than happy to start those conversations, try to clarify the uncertainties, and push that forward.

[gziolo]

I feel like the UI to add bindings is probably more important than things like updating the values.

Right now, there's a risk of third party plugins creating their own binding UI and we end up with loads of different variations per binding source plugin.

Thank you for your feedback on that one. There are some prototypes, so it might be a good idea to spend some time creating an experiment in the Gutenberg plugin to gather feedback about one of the approaches considered so far.

• Add hook to check when we should lock controls when bindings exist: link.
• Use RichText identifier to check if we should make it non-editable: link.
• Explore how to abstract the locking of controls: Features like pattern overrides and block bindings have limited control over block UI #58233.

These three items on the list are related. In fact, I commented on #58233, resharing the items linking to my comments on PRs. I think it would be helpful to group them together, example:

• Explore how to abstract the locking of controls: Features like pattern overrides and block bindings have limited control over block UI #58233.
  • Add hook to check when we should lock controls when bindings exist: link.
  • Use RichText identifier to check if we should make it non-editable: link.

Having these changes in place would make it easier to open Block Bindings to new core blocks.

[annezazu]

Hey folks! For 6.6, can you all create a new epic issue outlining what's being thought of and close this issue out? This will help us see the progression of a feature scoped for each release over time and help ensure any discussion in the comments is relevant to the current release.

[SantosGuillamot]

Hey folks! For 6.6, can you all create a new epic issue outlining what's being thought of and close this issue out?

As suggested here, and after discussing it with @priethor , I'm closing this issue as an iteration for WP 6.5. I've opened two new issues:

• Block bindings API tracking issue: The idea is to discuss the strategy there.
• Block bindings API iteration for 6.6: We'll share regular updates and progress on the issues expected to be included in 6.6.