-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connecting block attributes and custom fields & Block Bindings API for WP 6.5 #53300
Comments
Initial experimental MVPWe can start with a simple experimental version, that can be activated through Gutenberg → Experiments, to kick off the project. We can aim to just:
<!-- 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.
For this first experimental MVP, I would leave out of the scope:
|
By the way, the 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 Anyways, I believe the case here is slightly different than the Apart from that, blocks using the old |
I've opened the PR to allow connecting the |
@mcsf should be the best person to contact, in case you need to know the details. Here is the initial implementation #2740. |
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:
|
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). |
@SantosGuillamot, @Poliuk I have added a tracking issue for partial syncing, which is going to have some overlap with this work. |
I wanted to share an update on the work done till now: DoneThe 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.mp4Apart 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 stepsThe potential immediate next steps could be:
|
To reflect the general nature of the feature that goes beyond just custom fields, @SantosGuillamot and I propose to call it "Block Bindings".
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. |
Majorly agree with thinking beyond custom fields here, binding could be useful for other use cases too |
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:
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. |
Initial version for WordPress 6.5We 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. GoalAs 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.mp4These 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 releaseThe 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 UIThe idea is that users can add the binding through a new "bindings" block attribute. A couple of things that are important at this point:
With that in mind, this is the list of things to consider:
2. Include a basic UI to create these bindings where we can read the metadata valueWe can start with a basic dropdown as the one shown in the video without the possibility of editing its value.
3. Add the possibility to edit the value of the meta field directly through the Editor
4. Add support for more core blocks we consider importantOnce 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:
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 |
@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
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
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 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. |
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. |
@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 🙂
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 could make sense 🙂 Adding it to the list of things to consider.
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.
Totally agree here. We have to ensure that whatever we provide works as smooth as possible with plugins like ACF.
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
@decodekult That looks great! All the feedback we receive, regarding the UX, things to consider, or the development, is more than welcome 🙂 |
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!
Specifically with your question on ACF here, yeh -
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. |
I updated the previous #53300 (comment) to make it clearer that the list of supported attributes applies to all registered sources: - It is important to remember that, in this initial version, only a few block attributes can be connected:
+ It is important to remember that, in this initial version, only a few block attributes can be connected with all types of registered sources: |
Now that we are past the Beta 1 cut off point I'm removing this tracking issue from the 6.5 Project board. From now on the board should only contain individual bugs that we want to still fix before 6.5 gets released. |
@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! |
@dinhtungdu in order to have other blocks besides the featured image, title, and content editable we need to solve #59290 |
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. |
Update - Changes made during WordPress 6.5 beta phaseNow 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.
Apart from that, some resources to understand better the custom fields and bindings were created:
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. |
Potential plan for WordPress 6.6Now 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:
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:
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. |
@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. |
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. |
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 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. |
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.
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:
Having these changes in place would make it easier to open Block Bindings to new core blocks. |
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. |
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:
|
Part of:
Related to:
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.
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:
Fixes/updates for Gutenberg 17.6 RC (Tuesday 30th)
WP_Block_Bindings_Registry
class like others likeWP_Block_Type_Registry
are doing: link.Fixes/updates for WordPress 6.5 beta 1 (February 13th)
strcasecmp
reported here.WP_Block_Binding_Source
class and handle validation there: link. PR: #6042 / Core changeset: 57562setAttributes
. PR: #58806Fixes/updates during beta phase
queryId
in context: link. Solved as part of Core / Gutenberg PRuse-bindings-attributes
hook and improve its implementation. As part of that, we should address link. PR with the refactoring: #58895WordPress 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
RichText
identifier to check if we should make it non-editable: link.And work on new aspects like:
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:
site_url
+field_id
.The text was updated successfully, but these errors were encountered: