Button entity URL bindings via post-data/term-data args#76875
Draft
Button entity URL bindings via post-data/term-data args#76875
Conversation
Extend core/post-data and core/term-data to resolve entities from binding args (id + postType / taxonomy). Wire Button LinkControl with entity bindings; store entity metadata in args, not block attributes.
Do not set lockUrlControls when the URL is bound via core/post-data or core/term-data with args.id; LinkControl updates bindings directly.
github-actions
bot
added
[Package] Editor
getdave
changed the title
|
Size Change: +635 B (+0.01%) Total Size: 7.73 MB
ℹ️ View Unchanged
|
Contributor
|
I think we should also allow a binding to attachments. |
fetchLinkSuggestions returns kind "media" for attachments; treat like post-type attachment in bindings and sync LinkControl value from args.
scruffian
reviewed
Mar 28, 2026
| ); | ||
|
|
||
| if ( $is_navigation_block ) { | ||
| $post_id = null; |
Contributor
Author
There was a problem hiding this comment.
Lower down we use $post_id in get_post(). Whilst for now each if branch sets this value, that might be forgotten if someone adds a new branch leading to errors.
It's just a code hygiene thing really...
Contributor
Author
✅ Fixed |
getdave
commented
Mar 28, 2026
Comment on lines
+43
to
+46
| // Align with LinkControl / navigation attribute shorthand. | ||
| if ( 'tag' === $taxonomy ) { | ||
| $taxonomy = 'post_tag'; | ||
| } |
Contributor
Author
There was a problem hiding this comment.
@scruffian @jeryj @talldan This is getting spread around the codebase. Should we try and stop it happening?
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Fixes #72314
What
This pull request extends the
core/post-dataandcore/term-datablock binding sources so they can resolve values against a specific post or term when that entity is identified in bindingargs(numeric id pluspostTypefor posts ortaxonomyfor terms, together with the bound field such aslink). Resolution still falls back to the existing Navigation block attribute path, then to block context, when those args are not present.It wires the Button block so entity links chosen in LinkControl use those sources: entity identity lives in
metadata.bindings.url.args, not in new block attributes. The link UI remains usable so users can switch to another entity, unsync to a custom URL, or unlink; updates go through LinkControl andupdateBlockBindings, not contextualsetValues.Why
Navigation Link and Navigation Submenu already bind URLs to a specific entity, but the entity reference is stored in block attributes (
id,kind,type, etc.) and the post/term sources rely on a dedicated exception for those blocks. Button cannot follow that pattern safely: it has no entityidattribute, and itstypeattribute is reserved for the HTMLbuttonelement type, so overloading it for post type or taxonomy would be wrong.Storing the entity reference in binding args matches the direction discussed in Block Bindings Shape Concerns (#72426), including this comment on placing entity metadata in binding args rather than assuming every block defines an
idattribute or introducing fragile composite attributes. This also addresses Add dynamic URL resolution to Button Block (#72314).How
Editor and PHP compat layers apply a consistent precedence per binding: when
argssupply a post or term id and the discriminating slug, use that record; otherwise use the Navigation attribute branch, then context. Inline comments document whypostTypeis required on the JavaScript side (core-data entity keys forgetEditedEntityRecord) and how PHP can validate or resolve by id.Button adds a small helper to build and clear URL bindings from LinkControl values, enables
handleEntities, and avoids locking URL controls for post/term entity URL bindings so behavior stays aligned with Navigation Link for editing the link after it is set.Testing
href.npm run test:unitforpackages/editor/src/bindings/test/post-data.js,packages/editor/src/bindings/test/term-data.js, andpackages/block-library/src/button/test/build-button-url-entity-binding.js.Related: #72426