Block Bindings iteration for WordPress 6.7

[SantosGuillamot]

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

• Follow-ups from 6.6 and bug fixes: There were a few items that weren't included in the 6.6 iteration that will need some work. Additionally, bugs need to be addressed.
• Add UI to connect attributes with the binding sources: Basically, add the first iteration to be able to create the bindings through the UI instead of having to go to the Code Editor.
• Polish and open block bindings editor’s APIs for extenders: Core sources like "Post Meta" use some private APIs to handle bindings in the editor. The idea is to polish those APIs to enable external developers to use them.
• Experiment supporting more core sources: In order to ensure that the editor APIs fit future use cases, it'd be great to add support for more core sources, or at least experiment with them in case we want to create them in the future.
• Support anything needed by pattern overrides: We can expect some work needed to support new functionalities in pattern overrides.

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

• Don't show post meta fields that start with an underscore. (Temporary fix)
• Fix empty custom fields not being editable in bindings.
• Add warning when block attribute is connected to an invalid source.
• Rely on Text component instead of Truncate in bindings panel.
• Can't save changes to the source if custom fields are opened
• Potential filter to modify the value returned by bindings.
• Prioritize existing placeholder over bindingsPlaceholder.
• Only use canUserEditValue when setValues is defined.
• Only pass context included in usesContext from rich text component.
• Only pass usesContext properties to editor APIs.
• Refactor passing select and dispatch instead of full Registry.
• Fix editing protected custom fields in block bindings.
• Refactor e2e tests.
• Unify logic in getPostMetaFields function.
• Register bindings sources in widgets screens.
• Accept client ID as parameter for useBlockBindingsUtils.
• Don't render image when src attribute is empty.
• Bootstrap server sources earlier: Core & Gutenberg.
• Improve accessibility of bound paragraphs when using a screenreader in Navigation Mode.
• Change "This block is connected" indicator to make it accessible.
• Keep bindings editor calls in their own logic useSelect.
• Improve performance.

Nice to have

• Add indicator that an attribute is connected instead of hiding the controls.
• Add support for image caption.
• Add support for image href.
• Ensure custom field changes work fine with revisions.
• Send only edited values to the POST API requrest

UI to create bindings

For more info about the tasks, most of the discussions happened here.

• Create initial UI for connecting block attributes and custom fields.
• Block Bindings: Fix long keys overflow in bindings panel.
• Create utils to add/remove bindings in the object that can be reused.
• Decide where the bindings panel should live and in which cases it should be available: link.
• Remove experimental flag once the UI is considered ready.
• Add label argument to register meta.
• Add support for connecting custom fields in templates.
• Use post meta label from register_meta in block bindings workflows.
• Explore how permissions should work with bindings creation: link.

Nice to have

• Abstract the useToolsPanelDropdownMenuProps util.
• Add backdrop-color to connected blocks.
• Keep iterating on the UI:
  • Add a "Clear" button? See link.
  • Add a search bar?
  • Add a prompt when the connection hasn't been created yet. See link.
  • Improve UI of "read-only" panel. See link.

Polish and open editor APIs

• Improve the way sources are registered: This includes a refactoring to work as blockTypes, blockVariations, blockCollections... It also includes new functions like unregisterBlockBindingsSource and unit tests.
• Use @wordpress/warning during block registration instead of console.error and console.warn.
• Unify getValue/getValues and setValue/setValues APIs.
• Don't provide default canUserEditValue in reducer.
• Bootstrap sources defined in the server.
• Improve how the context is handled in the editor.
• Improve how the context is handled in the server.
• Allow bindings bootstrap after registration.
• How should bindings handle placeholder/fallback values?
  • Change placeholder when attribute is bound.
  • Remove getPlaceholder API and rely on key argument or source label.
• Revisit the extensibility mechanism to allow other sources to appear in the UI. See link.
• Make the editor APIs public: link.
• Add docs and types to source registration.

Support for more core sources

Nice to have

• Create an experiment to support taxonomy meta and decide if it should be included as a core source.
• Create an experiment to support site data and decide if it should be included as a core source.
• Create an experiment to support post data and decide if it should be included as a core source.

Saving workflows

Nice to have

It isn't still clear if saving workflows should be modified or not as discussed here.

• Editing bound paragraph in post editor causes "Site Updated" message to appear.
• How/if to improve save workflows to notify users of specific post data changes?.
• Output granular post meta changes in a list.
• Add indicator for modified post meta in pre-publish flow

Backports

• Bootstrap sources defined in the server.

[fabiankaegy]

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

[SantosGuillamot]

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.

[SantosGuillamot]

I've opened a couple of pull requests/discussion that will affect the editor public APIs in case anyone wants to share feedback:

• Block Bindings: Unify getValue/getValues and setValue/setValues APIs #63185.
• Block Bindings: Improve the way block bindings sources are registered #63117.

[gziolo]

Thank you for opening the iteration for WordPress 6.7.

Add UI to connect attributes with the binding sources: Basically, add the first iteration to be able to create the bindings through the UI instead of having to go to the Code Editor.

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.

Polish and open block bindings editor’s APIs for extenders: Core sources like "Post Meta" use some private APIs to handle bindings in the editor. The idea is to polish those APIs to enable external developers to use them.

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.

[SantosGuillamot]

Update

There have been three main areas of work during the last weeks

UI to create bindings

The 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 APIs

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

• Improve the way sources are registered: This includes a refactoring to work as blockTypes, blockVariations, blockCollections... It also includes new functions like unregisterBlockBindingsSource and unit tests.
• Bootstrap sources defined in the server: Gutenberg PR and Core backport.
• Unify getValue/getValues and setValue/setValues APIs.
• Revisit how bindings should handle placeholders.
• Add docs and types to source registration.

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:

• Improve how the context is handled: In the editor and in the server.

This one is not strictly needed to open the APIs, but I consider it important, and it seems to be working.

Saving workflows

While 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.

• How/if to improve save workflows to notify users of specific post data changes?  #63425

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 steps

These are what I considered that could be the next steps for the upcoming weeks:

• Keep the discussion and the prototype around the UI going.
• Review and make decisions around the editor APIs to start merging the changes progressively.
• Solve the remaining issues listed in the opening post, especially the bugs.
• Foster the discussion around saving workflows.

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.

[bacoords]

Would love to see if this is feasible: #63763

[SantosGuillamot]

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.

[SantosGuillamot]

Update

UI to create bindings

The 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.mp4

The 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 APIs

The editor APIs are shaping nicely and most of the tasks to be able to open them have been addressed:

• Improve the way sources are registered.
• Unify getValue/getValues and setValue/setValues APIs.
• Bootstrap sources defined in the server: Gutenberg and Core.
• Improve how the context is handled in the editor.
• Improve how the context is handled in the server.

There are three main topics remaining:

• Add docs and types.
• How should bindings handle placeholder/fallback values?.
• Revisit the extensibility mechanism to allow other sources to appear in the UI. See link.

Saving workflows

So far, the feedback seems to agree on not changing the saving workflows at all.

Next steps

These are what I considered top priorities for the upcoming weeks:

1. Decide where the UI panel for connecting sources should be placed and implement the necessary changes. More context can be found here and here.
2. Explore how to integrate the UI for connecting sources properly with templates: link.
3. Split the placeholder/fallback for connected attributes discussion into smaller actionable items: link.
4. Add docs and types to editor APIs and open them for usage by plugin authors.
5. Solve the remaining issues listed in the opening post, especially the bugs.

[jhmonroe]

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

[SantosGuillamot]

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.

[SantosGuillamot]

Update

UI to create bindings

Two main topics are being discussed at this point:

• Be able to create bindings in templates: This is tricky because it is hard to identify which post type each template corresponds to. So far, the pull request relies on the slug and exposes a new field in the types endpoint, but it needs to be discussed.
• Decide where the bindings panel should live and in which cases it should be available: It is still not clear how this should work. I opened a proposal to use "Preferences" to let users enable/disable the UI to create bindings, and different alternatives are being discussed there: link.

Editor APIs

Before 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

• Block Bindings: Create utils to update or remove bindings #64102
• Reuse useToolsPanelDropdownMenuProps util #64105 : Needs follow up PR.
• Can't save changes to the source if custom fields are opened: There is a proposal to fix this, but it needs to be discussed. Synchronizing legacy meta boxes and the React store changes is tricky.
• Block Bindings: Fix long keys overflow in bindings panel #64465

Next steps

These are what I considered top priorities for the upcoming weeks:

• Review the approach and merge the pull request to create bindings in templates: link.
• Review the approach and merge the pull request to make the UI to create bindings work the same way as "Advanced" control and add a preference to enable it: link.
• If there are no blockers or concerns around the suggested approach for placeholders, address the tasks indicated in the discussion: link. There are a few tasks that can be handled regardless of the decision taken because they are bug fixes.
• Review and merge the code quality and bug fixes open pull requests.
  • Block Bindings: Create utils to update or remove bindings #64102
  • Reuse useToolsPanelDropdownMenuProps util #64105
  • Fix: Store post meta changes are overridden when custom fields meta box is enabled #64505
• Add docs and types to source registration.

[SantosGuillamot]

Remaining aspects for 6.7

With 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 request

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

• Create a new "bindings" group that is placed on top of the Advanced settings. This solves the problem we face of creating a new "Settings" tab for blocks like paragraphs of headings.
• It creates a new canUpdateBlockBindings editor setting that is used to enable this or keep the "read-only" panel. By default, only admin users can create and modify bindings.
• Polish the UI and help texts.

Show list of available fields in templates - Relevant pull request

In 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 meta property to the types endpoint and call this endpoint from the template. Right now, it inherits the post type from the template slug.

Improvements to how placeholders are handled - Relevant issue

In the linked comment, I tried to sum up the current status and the necessary changes. There, I propose using the key as a special argument to simplify the implementation until we figure out what is needed. If we go that path, these would be the missing tasks:

• Fix editing locking when the value is empty.
• Change prompt/placeholder when the value is empty
• Change fallback when the value returned by the source is undefined (in templates, for example).
• Add error message when using a source that is not defined.

Add docs and types to source registration

Docs and types should be added before making the APIs public in order to ensure external sources can easily use them.

Review getFieldsList API

Right now, we are using a getFieldsList callback that let sources decide which fields are shown in the UI to create and modify bindings. I believe it can serve well as a first step for external sources to include their own fields. However, I'd like to review the name and the implementation to ensure it is ready to be public.

Additionally, I'd like to explore the possibility of moving this to the server source registration if we modify the types endpoint to make it work with templates.

Open editor APIs

Once the previous steps are done, it should be possible to open the editor APIs. Both the source registration and the different functions and selectors.

Something we should consider is if useBlockBindingsUtils should receive a clientId as optional as suggested here.

Improved how context is handled in the server - Relevant pull request

This one is supposed to be ready but it is waiting for Gutenberg packages update. Once that is done, it should be rebased and adapted.

Fix editing meta values and custom fields meta boxes bug - Relevant issue

As reported in the issue, editing custom fields of bound blocks is currently broken when the metabox is enabled. There are two possibilities explored to solve this:

• Lock editing in fields in editor if meta fields panel is opened .
• Modify the request to update metaboxes.

The first one is simpler but it only solves the problem for this specific use case, and external sources would need to adapt to this as well. The second one is supposed to solve it for all use cases, but it is unclear if it is a correct approach.

Probably the first approach is fine enough for now.

Filter to modify the value returned by bindings - Relevant pull request

In the linked pull request, it is suggested to include a filter to modify the value returned by bindings. It is missing some tests and docs.

Decide if the bindings should be shown in contentOnly mode - Relevant issue

There, it is being discussed what should be the behavior of the bindings panel when contentOnly mode is enabled. We have to keep in mind that in this other pull request, we plan to limit the possibility of creating and modifying the connections to admin users by default.

Address remaining bugs

Apart from that, there are still a few reported bugs we might want to address, although it's true they could be done during the beta phase.

[SantosGuillamot]

Update

Merged

These are the most relevant pull requests merged during last week for me:

• Remove the experimental flag of the UI to create and modify bindings: That pull request covers some UI improvements to make it ready and make it accessible only for admins by default. It also includes a setting that let site owners change this behavior. This serves as a security measure until it is clearer who should be able to manage them.
• Filter to customize the output of a block bindings source.
• Fix: Can't save changes to the source if custom fields are opened.
• Fix empty custom fields not being editable in bindings.
• Add warning in attributes connected to invalid sources.
• Change placeholder of empty connected values.
• Remove getPlaceholder API and rely on key argument or source label: This simplifies the editor APIs.

Ongoing pull requests and discussions

These are the ongoing pull requests/discussions related to block bindings and the status of them

Support connecting attributes in templates - Pull request

I 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 request

On 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 postType in block context in templates - Pull request

Not directly related to block bindings, but it could help in some of the PRs. I opened the linked pull request to discuss if it would make sense to pass the postType as context in the cases where we can inherit it from the template slug.

Add label argument to register_meta and consume it in bindings UI - Core & Gutenberg

As suggested here, and it has been a recurring request, using the meta key in the bindings UI feels too technical. I started this core pull request suggesting adding a new label property to register_meta and I created this pull request in Gutenberg to consume it in the different places.

To me, it is a great example of how the user experience could be improved and it looks much nicer this way.

The core pull request has already a couple of approvals, so it is just a matter of discussing if it is fine to include the new label argument.

Regarding the Gutenberg pull request, it is supposed to be ready. However, it will require minor modifications after the templates PR, which is the base, is merged. Basically, it needs to merge both PHP filters and resolve conflicts in the post-meta.js file.

Set show_in_rest to true when label is defined - Pull request

Related to the previous point, including a new label attribute opens the possibility of setting show_in_rest to true when it is defined. This has been a recurring complaint in the community as well. I opened the linked pull request and a core ticket to discuss that possibility.

How to define capabilities to manage bindings - Pull request

In that pull request, it is being discussed how the capabilities to manage bindings should work. There are different possibilities to consider.

As part of that, I started a pull request in Gutenberg for compatibility that should match whatever is decided there.

Fix: Improve accessibility of bound blocks when using a screenreader - Pull request

There is some discussion around the best approach to address this and if it should be abstracted to any block or just paragraph and heading.

Respect placeholder provided on the server

As discussed here, we might want to explore the possibility of respecting the placeholder provided by the server instead of replacing it with the bindingsPlaceholder.

Potentially improved the read-only panel - Pull request

In the linked pull request, it is being discussed if the read-only panel deserves some special styles, and what, or if we should wait until people start using it and we receive feedback.

---

Apart from that, there are still a few other things to keep in mind:

• Improved how context is handled in the server - Block Bindings: Add context needed by block bindings sources during its processing wordpress-develop#6456. Once the packages sync is done, it will require some adjustments and commit.
• Keep addressing the opened bugs.
• Keep polishing the UX/UI.
• Decide if the bindings should be shown in contentOnly mode - Block Bindings API/UI: Attributes Panel still shows when block is set to 'contentOnly' editing mode. #64731.
• Explore if we need to add more docs and types to editor APIs.
• Review getFieldsList API.
• Open editor APIs once we consider them ready.

[SantosGuillamot]

WordPress 6.7 feature freeze

Now 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 fields

A 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.mp4

As 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 label argument has been included in register_meta to be able to consume human-readable text instead of the key.

This UI is controlled by a new editor setting reading a new edit_block_binding capability, which is mapped to edit_post (if editing a post) or edit_theme_options (if editing a template). This means that by default admin and editor users can create and modify bindings, but this can be overridden with block_editor_settings_all or map_meta_cap filters.

Open stable editor APIs

During 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

• APIs to register/unregister/get sources in the client: Some functions were added to be able to register, unregister, and get the block bindings sources. Similar to what already exists on the server. This helps extenders decide how a block attribute should behave when it is connected to that specific source.
• Utils to update and remove bindings: Provides some helper functions to update the bindings property in the metadata attribute. These could be handy for extenders creating their own UIs and they are being used by post meta and pattern overrides.
• PHP filter to customize the output of a block bindings source: Provide flexibility for developers that just want to modify the output of a specific source.

Feedback wanted

During 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 steps

During 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.

[afercia]

This release comes with a new UI that allows users to connect attributes with custom fields,

I have a concern about the usability of the new UI. I always test the Bindings API by registering 9 post meta, always the same for testing purposes. Actually I use a code snippet I stored for this purposes. It's only 9 sources. In real life users may have dozens and dozens of post meta registered.

My concern is that the UI presents the available sources all together and not filtered by the type of expected value.
For example, when I want to bind an image url, I woudl expect the UI to show me only the sources that are compatible with an URL. Instead, it shows everything also values like normal text and the like that clearly isn't valid for an URL Screenshot:

In the example above, only one of the sources is suitable for an image URL. All the other ones are still presented in the UI and that's very prone to confusion and errors. Not to mention this list could actually contain dozens and dozens of sources.

There is nothing that prevents users to click, for example, on a value that is text and set is as the image url.

I'm not sure this would be a good user experience and I tend do think this list of values, as is, is hardly usable.
At the very least, it should be filtered, only listing values that are compatible with that specific block attribute.

[SantosGuillamot]

Thanks for the feedback. I agree the UI needs to keep improving, and things like limiting the list of fields, adding a search, or filtering by type are part of the roadmap. Please keep in mind that this is the very first UI, which, in my opinion, is much better than having to go to the editor. And if someone prefers keeping only the code editor option, they can disable this UI.

Functionalities like showing only the "suitable" fields make total sense, but they might require a deeper exploration of how they should work. They will probably require an improvement on the block attributes and custom field types. For example, there is no "URL" type right now in the fields definition: link. It could be hardcoded for this particular case, but I personally would like to make it work for any block attribute/custom field.

[gziolo]

@afercia, great feedback. It's something that has been discussed several times, and we are moving in that direction. Some related issues that would allow to provide more semantic meaning to attributes to make the filtering possible:

• Explore adding media related roles to block attributes #65186
• Exploring how Patterns can be connected to Schemas #41606

So, we essentially would need changes in both places:

• a way to provide a stronger contract of the subtype of the attribute in its schema
• a way to annotate the entry coming from the block-binding source to inform its compatibility with subtypes defined for the attribute

@ntsekouras and @mtias, do you have any insights to share how it could be implemented?

[afercia]

Thanks for the feedback. I agree the UI needs to keep improving, and things like limiting the list of fields, adding a search, or filtering by type are part of the roadmap. Please keep in mind that this is the very first UI, which, in my opinion, is much better than having to go to the editor.

I totally understand this is the very first UI iteration. However, I'm not sure I agree with releasing to the public an UI that is clearly unfinished and unpolished at a point that it will be hardly usable for users. I think WordPress should not release unpolished features as that doesn't contribute making the editor be perceived as a stable software.

[ntsekouras]

So, we essentially would need changes in both places:

• a way to provide a stronger contract of the subtype of the attribute in its schema
• a way to annotate the entry coming from the block-binding source to inform its compatibility with subtypes defined for the attribute

@gziolo that sounds right. We'd need to implement the media roles first and then use the same roles to annotate entries from sources. We'd need to update register_meta to add such info(roles) and this is also related to the DataForms and DataViews projects, as we'd like to be able add custom fields in lists and edit them.

[SantosGuillamot]

I'm not sure I agree with releasing to the public an UI that is clearly unfinished and unpolished at a point that it will be hardly usable for users.

I personally don't agree with this statement. The feedback I personally received is that it is highly useful for users. It is for sure that the UI needs to evolve and include things like searching or filtering by type as suggested, but I think the existing implementation goes in the right direction, and, in my opinion, it doesn't look unpolished.

If the problem is that the list of fields could get too long, we can include a height limit so users scroll over it. If you believe this shouldn't ship without filtering by the field type, this would need to be postponed to 6.8.

As I said, I personally believe the UI is good enough for a first version, it adds value to users, and it doesn't look unploished, but I'd love to know more opinions on this. Pinging folks that have been involved in discussions related to this: @WordPress/gutenberg-design @justintadlock @annezazu @ryanwelcher @ndiego

[ndiego]

As I said, I personally believe the UI is good enough for a first version, it adds value to users, and it doesn't look unploished, but I'd love to know more opinions on this.

I was just using this over the weekend to build out an archive grid for a "staff" CPT, and it was fantastic. I would characterize the feature as limited, not unpolished. I had about 10 pieces of post meta, and it did not feel overwhelming. Building out the Query Loop and just adding in all the post meta bound to Paragraph blocks using the UI was a breeze. This is a great first iteration and I have no concerns about adding it in 6.7.

My main frustration, if you could call it that, was not being able to bind data to more blocks. For example, I wanted to be able to bind a staff_facebook_url meta value to the link attribute in a Social Icon block. Looking forward to 6.8 😉

[afercia]

I personally don't agree with this statement. The feedback I personally received is that it is highly useful for users. It is for sure that the UI needs to evolve and include things like searching or filtering by type as suggested, but I think the existing implementation goes in the right direction, and, in my opinion, it doesn't look unpolished.

Please let's not mix together different considerations. I haven't stated in any way that this feature isn't useful for users. I do agree it;s an useful and long waited feature.

My concern is that the UI isn't ready as is. In my opinion it's unpolished and confusing. Releasing to the public an UI that isn't finished has a cost in terms of learning curve, trust, and reputation. From a functional perspective, the UI allows users to select values that are incpmatible with the expected value type. I'd say this fact alone is a valid concern as there's no 'validation' of the expected data type.

[justintadlock]

I'd agree that the UI and UX is limited but not unpolished. We shouldn't let the perfect be the enemy of the good here.

The worst thing I think we could do is hold off on this feature, allowing it to linger in front of a small audience of developers before we figure out what works best at the UI level. Usage is like oxygen for ideas.

I have no serious concerns with this for 6.7 given its state as a "v1.0." Let's ship, get feedback, and iterate.

[afercia]

given its state as a "v1.0."

Disagreement in a large open source project is perfectly fine. To me, it's surprising that after more than seven years of development the block editor is still treated as 'beta software' where unfinished UIs and features get released to the public and then iterated. That has a cost in terms of trust and adoption. I would like to see the block editor be a more stable product but I do realize that's a broader discussion related to process and product management that should be addressed at a higher level. Just my 2 cents.

[artemiomorales]

I hear @afercia's concerns, though I also think shipping and iterating is the best move.

If the problem is that the list of fields could get too long, we can include a height limit so users scroll over it.

This seems like a good improvement on par with a bug fix that we could aim to ship in 6.7.

[gziolo]

#66174 landed that contains changes that limit the options exposed in the Attributes panel. The majority of the block attributes that can be connected with Post Meta source have string or rich-text type. When selecting the Post Meta to connect with the attribute the options available are filtered so the types match. In effect, when the id attribute for the Image block is about to be connected, it can be only connected with Post Meta that have number type.