Block Bindings: Set blocks as read-only UI. #72534
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cbravobernal
added
the
[Type] Bug
|
Size Change: +20 B (0%) Total Size: 2.19 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 5482aff. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18689733060
|
cbravobernal
added
the
Backport to WP 6.9 Beta/RC
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
ntsekouras
reviewed
Oct 23, 2025
| */ | ||
| const getAttributeType = ( blockName, attribute ) => { | ||
| // Temporary workaround for datetime attribute. | ||
| if ( attribute === 'datetime' ) { |
Contributor
There was a problem hiding this comment.
I'm not very familiar with block bindings, but this feels quite fragile and it doesn't even check blockName.
Is the root issue that bindings support datetime type, where block attributes don't? If yes, are there similar cases for other types that makes the handling harder?
Should we think of an API to handle this more gracefully?
Contributor
Author
There was a problem hiding this comment.
I though about moving that "check" to the post-data source. And show only those values based on attribute type and block name, instead of handling in the block bindings UI.
Is the root issue that bindings support datetime type, where block attributes don't? If yes, are there similar cases for other types that makes the handling harder?
The root issue is that datetime is not a type. Post-date block only accepts datetime format as a value, and the attribute is a string type, which means that can be anything ( url, phone number, email, etc).
Should we think of an API to handle this more gracefully?
Yes, is one of the reasons we are considering to punt the UI to 7.0
Contributor
Author
There was a problem hiding this comment.
I edited the PR to set the UI as readonly. It was discussed with @mtias as a possible solution for this bug.
Contributor
Author
There was a problem hiding this comment.
It's important to notice this issue too:
#72534 (comment)
Contributor
|
Not related to this PR, but saw it while testing. In custom date the 
|
cbravobernal
force-pushed
the
fix/non-compatible-data-showing-block-bindings-ui
branch
from
5482aff to
498b3b9
Compare
cbravobernal
changed the title
Contributor
Author
It is logic as the attribute can be bound, and, for that option, is not connected. You should be able to connect it to a source if available. If we are setting now the UI for this block as readOnly, it may be confusing, as you cannot do anything with it. |
ntsekouras
reviewed
Oct 24, 2025
| const { Menu } = unlock( componentsPrivateApis ); | ||
|
|
||
| const EMPTY_OBJECT = {}; | ||
| const READONLY_BLOCKS = [ 'core/post-date' ]; |
Contributor
There was a problem hiding this comment.
I don't want to be a bottleneck here and will defer to others with more experience around bindings to review/approve.
Having said that, my thoughts remain the same about hardcoding exceptions. In some cases this might get out of hand and with no solution for the root issue.
If we're tracking the root issue and we really want a temp solution for 6.9, I guess it would be okay, but we should also add comments about it. If it's not for 6.9 it might be better to explore further.
My last thought is if we go with this temp workaround, is there any point in showing the UI at all? Could we hide the Attributes panel altogether?
Contributor
Author
There was a problem hiding this comment.
Yes. I think hiding is a better option. Before making any decision, I want to test what happens with the old UI with post-date binding enable. If it is causing issues too, then the UI implementation is not the problem, the problem is a more architectural decision. (Blocks should have an API to decide per attribute if the UI should be hidden, readonly o functional.)
You are not being a bottleneck @ntsekouras , thanks for all the feedback, is important to find the side effects and decide what to do before RC1, and this helps us to make a decision.
Contributor
Author
There was a problem hiding this comment.
My testing results is that, even with the old UI, the moment we have registered a post meta (which shows the UI in Core), or any source in Gutenberg (with the old getFieldsList property), we will have the same issues.
Area2.mp4
cbravobernal
removed
the
Backport to WP 6.9 Beta/RC
Contributor
Author
|
Closing in favor of #72716 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Fixes #72446
Right now, block bindings UI filters the editorUI data by type, comparing with the attribute type.
For
post-dateblock, the bound attributedatetimeis a string, but it should only acceptdatetimedata, not any string like is doing right now.That makes that we can connect the post-date block
datetimeto any string type, like anurl. Causing aninvalid dateerror. As shown in the screenshot:Screen.Recording.2025-10-21.at.18.50.48.mov
How
Some blocks may use block bindings internally, and don't want to connect to other sources. Also they may want to not allow the user to interact with the Editor UI.
Problems
We should provide a good UI for this option, set up at the block or even at the attribute level, instead of hard-coding it into a variable.