-
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
Block Bindings iteration for WordPress 6.7 #63018
Comments
@SantosGuillamot Thank you for creating this new iteration issue :) Do you think it is feasible as part of 6.7 to aim for opening up the block bindings features (and therefore block pattern overrides) to 3rd party blocks / extenders? |
I'm afraid it will probably take more time than this release. To give more context, block bindings heavily rely on the HTML API, which still lacks a few functionalities to safely interact and modify any HTML element. It needs to ensure that it doesn't create any security issues or break the page. For core blocks where the markup is controlled, this isn't a big problem, but opening it for any 3rd party block, which could have any markup, could trigger unexpected issues. Additionally, a new opt-in mechanism would need to be defined. Hopefully, if I am not mistaken, the HTML API is not far from being able to handle these use cases, so I believe it should probably be one of the top priorities for upcoming releases. In the meantime, if there is a need to support other core blocks, those could be considered. |
I've opened a couple of pull requests/discussion that will affect the editor public APIs in case anyone wants to share feedback: |
Thank you for opening the iteration for WordPress 6.7.
That sounds like a potential key highlight in the release. It was one of the most anticipated features so far based on the feedback received. In particular, it will be interesting in conjunction with the Pattern Overrides design interface.
This is another key aspect of opening the counterpart for the server-side API exposed in WordPress 6.5. It will also require some glue layer to pass some data from the server to the client to represent better custom sources that get registered only on the server in the UI. |
UpdateThere have been three main areas of work during the last weeks UI to create bindingsThe issue to discuss the potential workflows is receiving a lot of feedback, which is amazing 👏 The idea is to try to approach it progressively. Start with a basic version and keep iterating on top of that. That way, it adds value and let us test as soon as possible, which should help with the discussion. We have started working on an initial prototype in this pull request, which is not far from ready. Polish editor APIsThere have been a bunch of pull requests going on to polish the editor APIs in order to make them ready to be opened. I feel confident that it is on good track and it is a matter of making some decisions and review the existing code. So far, these are the things that need to be solved before making them public:
Most of them seems to be working. Once they are merged, I feel the APIs could be open in Gutenberg. Additionally, we have been working on:
This one is not strictly needed to open the APIs, but I consider it important, and it seems to be working. Saving workflowsWhile working on improving the saving workflows for post meta ((granular post meta changes and fixing/refactoring the logic for the “Site Updated” message), some important issues where raised that made us revert the current behavior in this pull request. For that reason, we decided to take one step back and open a new issue to gather all the context to ensure we make informed decisions and avoid more issues like these ones in the future. The idea is to discuss there how the saving workflows should work and split it into smaller tasks once it is clearer. It'd be great to get more thoughts there. Next stepsThese are what I considered that could be the next steps for the upcoming weeks:
We could also start working on experimenting with potential future core sources to ensure the editor APIs fit their use case. Although we must be aware that the editor APIs are likely going to change in the mentioned PRs. |
Would love to see if this is feasible: #63763 |
Personally, I would prefer to focus on the internals and add support for more core blocks once the right abstractions are in place and "hardcoding" is not needed. But I'm happy to help, review, or guide if this is wanted for pattern overrides and someone plans to work on that. |
UpdateUI to create bindingsThe first prototype of the UI to connect block attributes and custom fields has been merged. In the end, it was included under an experimental flag because there are some uncertainties that have been added as follow-ups to the list. 352084865-a366cf1e-035f-48ed-b70c-addb78fdd520.mp4The main aspect before removing the experimental flag is deciding where this panel should live, which isn't still clear because it might change the workflows of the paragraph and heading blocks, which are widely used. Apart from that, we have to figure out how to make it work in templates, explore how to let external sources hook into this, and keep iterating on the UI. Editor APIsThe editor APIs are shaping nicely and most of the tasks to be able to open them have been addressed:
There are three main topics remaining:
Saving workflowsSo far, the feedback seems to agree on not changing the saving workflows at all. Next stepsThese are what I considered top priorities for the upcoming weeks:
|
Perhaps this flyout should be handled more the way Preferences modal works, and more like they are proposing here (#62703) for Allowed Blocks UI? More of a common/native experience than a new flyout that isn't used anywhere else? Also a flyout won't allow as much space for scrolling if the list becomes long. Also to more efficiently share code that is used elsewhere when Core devs build a design out |
Thanks a lot for the feedback. I can see @jasmussen has answered you in the other issue 🙂 As mentioned, it is used in many places across settings/styles in the inspector controls. Actually, it is reusing the same design/components. Having said that, I believe we can iterate on the design once the workflows are clearer and we know better if a modal fits better. |
UpdateUI to create bindingsTwo main topics are being discussed at this point:
Editor APIsBefore opening the editor APIs, we need to clarify first how to handle the placeholders and whether they require an API or not. In this comment, I proposed a potential path forward that seems simple and lets us iterate on top of it, although there are a couple of concerns about it. Code Quality & Bug fixes
Next stepsThese are what I considered top priorities for the upcoming weeks:
|
Remaining aspects for 6.7With WordPress 6.7 beta 1 being on October 1st, and the last Gutenberg RC expected for September 25th, I wanted to recap what I consider the most important remaining steps to include in that release. They can seem a lot of things, but most of them are already pretty advanced. Please let's keep each discussion in its relevant issue or pull request UI to create and modify bindings - Relevant pull requestIn this initial pull request, the UI to create and modify bindings was added as an experiment. However, there were a few challenges we needed to solve before opening it. In this new pull request, some changes have been made to remove the experiment. Although there are still some aspects being discussed, these are the most relevant changes:
Show list of available fields in templates - Relevant pull requestIn templates, there is no post ID, so it is tricky to get the meta fields from the API. The mentioned pull request explores the possibility of adding a new Improvements to how placeholders are handled - Relevant issueIn the linked comment, I tried to sum up the current status and the necessary changes. There, I propose using the
Add docs and types to source registrationDocs and types should be added before making the APIs public in order to ensure external sources can easily use them. Review
|
UpdateMergedThese are the most relevant pull requests merged during last week for me:
Ongoing pull requests and discussionsThese are the ongoing pull requests/discussions related to block bindings and the status of them Support connecting attributes in templates - Pull requestI feel this one is almost ready and it improves a lot the user experience. Being able to connect blocks and custom fields in templates is great. As noted in this comment, there are just a few things to review before merging. Use default values in connected custom fields in templates - Pull requestOn top of the previous pull request, I started this one to discuss if we prefer to show the default values instead of the meta keys when connecting a block with a custom field. To me, the UX looks nicer, but it is something to be discussed. Pass
|
WordPress 6.7 feature freezeNow that the feature freeze is here and only bug fixes should be included from now on, let's do a recap of what can be expected to be part of this release. There have been multiple pull requests going on during the last weeks to polish the UI and the different APIs. That helped to ship the two most important topics of this release cycle: User interface (UI) to connect blocks and custom fieldsA quick note here, this is specific to post meta fields as the APIs to extend this UI weren’t considered stable yet. Other sources won't be able to use it in 6.7 but it is being explored in Gutenberg how this should be shaped. This release comes with a new UI that allows users to connect attributes with custom fields, making it possible to create bindings through the UI instead of the Code Editor. In the following demo, I create a template from scratch connecting blocks to movie meta fields and show how it is reflected in the frontend. Demo.block.bindings.-.template.mp4As shown in the video, it uses the default values when editing a template and, if it doesn't exist, it uses the meta label. Also as part of this release, a new This UI is controlled by a new editor setting reading a Open stable editor APIsDuring 6.6, there were some existing APIs to show and update the connected values that remained private but were being used internally in "post meta" and "pattern overrides". In 6.7, it has been decided to open the ones considered stable so other extenders can benefit from them. These are the APIs exposed: Please keep in mind that we are working on proper dev notes and documentation
Feedback wantedDuring the recent weeks/months, we tried to polish the UI as much as possible and we tried to improve all the nuances like placeholders, external sources, invalid one, etc. However, I'm sure more things will come from testing. It'd be great to get some feedback on the current workflows and on any scenario you can imagine to ensure the UI is as solid as possible. Additionally, if you are an extender and you have created your own block bindings source, it'd be great to get some testing on support for the editor to understand what is missing or if the current APIs are easy to use. Everything is open to discussion. Next stepsDuring beta phase, I expect most of the work will be around writing the proper dev notes and docs, and fixing any bugs raised after the testing. Once that is done, work on 6.8 can start. Personally, I see the biggest demands are to continue the work on the UI, making it extensible for external sources, and to allow any block to use block bindings. So I hope we can push those things further. |
Iteration of the Block bindings API tracking issue.
This issue will be used to gather the new functionalities and bug fixes expected to be included in WordPress 6.7. It will serve to share regular updates and progress.
Please keep in mind that the list of issues will change once new ones come up.
For this iteration of WordPress 6.7, the focus will be on these items (no specific order):
EDIT: I created a new section for "Saving workflows" after the issues raised and because it seems a big topic to be discussed.
Follow-ups and bug fixes
Nice to have
UI to create bindings
For more info about the tasks, most of the discussions happened here.
Nice to have
Abstract the.useToolsPanelDropdownMenuProps
utilPolish and open editor APIs
blockTypes
,blockVariations
,blockCollections
... It also includes new functions likeunregisterBlockBindingsSource
and unit tests.Support for more core sources
Nice to have
Saving workflows
Nice to have
It isn't still clear if saving workflows should be modified or not as discussed here.
Backports
The text was updated successfully, but these errors were encountered: