Feature : Button - Dynamic URL resolution by Vrishabhsk · Pull Request #74814 · WordPress/gutenberg

Vrishabhsk · 2026-01-21T14:25:30Z

What?

Closes Add dynamic URL resolution to Button Block #72314
Replicates the dynamic URL resolution implemented in Navigation links for button block

Why?

The Button block currently treats “select a page/post” links as static URLs, so if the linked entity’s permalink changes later (e.g., slug update), existing buttons can silently become outdated/broken.
This PR makes entity-selected Button links resilient by keeping them synced to the selected entity instead of the current editor context.

How?

Introduces a generic core/entity block bindings source (JS + PHP) that resolves an entity’s url from explicit binding args (kind, type, id) and is not tied to the current post/page context.
Updates the Button block so when a user selects a post/page/term from the existing link picker:
It creates a metadata.bindings.url binding using core/entity.
It does not persist a static url attribute for entity links (URL is dynamically resolved from the entity).
It clears the binding when switching back to a manual URL or unlinking.
Includes cleanup to remove any legacy contextual bindings that could incorrectly resolve to the current post.
Enhances the Button inspector “Settings” panel to use the same LinkPicker preview UI pattern as Navigation Link (badges + synced help text), while keeping existing toolbar link/unlink behavior intact.
Hardens ToolsPanelItem callback handling to avoid crashes when onDeselect is not a function.

Testing Instructions

Open a post or page in the editor.
Insert a Buttons block and add a Button block.
In the Button toolbar, click Link (or use Cmd/Ctrl+K).
Search for and select an existing Page (or CPT) suggestion.
Confirm:
- The Button shows the entity preview in the sidebar “Settings” panel (e.g., “Page”, “Published”) and “Synced with the selected …”.
- The toolbar Unlink control remains available.
Save the post/page.
Change the linked entity’s permalink (e.g., edit the page slug) and save it.
Return to the original post/page and confirm:
- The Button link updates to the entity’s new URL (no stale URL stored).
Unlink the Button and confirm:
- No editor crash occurs.
- The Button returns to an unlinked state and can be linked again.

(Optional) Paste/type a custom external URL and confirm:
The entity binding is removed and the Button uses the typed URL.

Screenshots or screencast

github-actions · 2026-01-21T14:25:41Z

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

Required label: Any label starting with [Type].
Labels found: [Package] Components, [Package] Editor, [Package] Block library, [Block] Buttons.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

github-actions · 2026-01-21T14:25:41Z

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

Required label: Any label starting with [Type].
Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

github-actions · 2026-01-21T14:25:43Z

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Vrishabhsk <vrishabhsk@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: getdave <get_dave@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

ramonjd

This PR tests well manually, but there are some items that make me doubt it could be ready for WordPress 7.0 beta.

For a more professional opinion, it'd be good to have @getdave run an eye over things in light of the work done in #71630

ramonjd · 2026-02-16T01:06:08Z

packages/block-library/src/button/edit.js

+					linkPanel={ isLinkTag ? linkPanel : null }
 				/>
 			</InspectorControls>
-			<InspectorControls group="advanced">


What was the reason to remove this control? Is it because there'll always be an href now?

It means users can no longer switch between <a> and <button> tags, which seems on the surface to be a regression to me.

ramonjd · 2026-02-16T01:08:13Z

lib/compat/wordpress-6.9/entity-block-bindings.php

+ * - type: post type slug or taxonomy slug
+ * - id: entity ID
+ *
+ * @since 6.9.0


I know you've been waiting for a while for reviews, thanks for your patience!

I don't know if this will make the next WordPress release, but the next version is now 7.0.0

ramonjd · 2026-02-16T01:09:05Z

lib/compat/wordpress-6.9/entity-block-bindings.php

+ * @param WP_Block $block_instance The block instance.
+ * @return mixed The value computed for the source.
+ */
+function gutenberg_block_bindings_entity_get_value( array $source_args, $block_instance ) {


It would be good to get test coverage here, e.g.,

Valid post-type and taxonomy URL resolution

Non-public post denial

Password-protected post denial

Invalid/missing args

Deleted entity handling (?)

ramonjd · 2026-02-16T01:09:58Z

lib/compat/wordpress-6.9/entity-block-bindings.php

+	}
+
+	$kind = (string) $source_args['kind'];
+	$type = (string) $source_args['type'];


Should we check if the post type exists? E.g.,

if ( ! post_type_exists( $type ) ) { return null; }

ramonjd · 2026-02-16T01:14:07Z

packages/block-library/src/button/edit.js

+		clearEntityUrlBinding,
+		createEntityUrlBinding,


I think these (and unlink()) should be wrapped in a useCallback().

They are plain closures recreated every render, which will make the useMemo recompute here.

Either that or restructure the logic somehow.

ramonjd · 2026-02-16T01:14:38Z

packages/block-library/src/button/edit.js

+		urlBinding?.source === 'core/term-data';
+	const boundEntityArgs = isEntityUrlBinding ? urlBinding?.args : null;
+
+	const resolvedEntityUrl = useSelect(


Could this useSelect be combined with the one below? They both call getEntityRecord.

ramonjd · 2026-02-16T01:16:39Z

packages/block-library/src/button/edit.js

+			preview,
+			suggestionsQuery: getSuggestionsQuery( boundType, boundKind ),
+			help,
+			onSelect: ( updatedLink ) => {


This callback seems very similar to LinkControl.onChange - could be extracted to a shared helper?

ramonjd · 2026-02-16T01:18:33Z

packages/components/src/tools-panel/tools-panel-item/hook.ts

@@ -150,11 +150,15 @@ export function useToolsPanelItem(
 		}

 		if ( isMenuItemChecked && ! isValueSet && ! wasMenuItemChecked ) {
-			onSelect?.();
+			if ( typeof onSelect === 'function' ) {


What's the motivation behind this change?

There's a subtle difference: optional chaining would throw on non-function truthy values (surfacing bugs), while typeof silently skips them.

I only raise it because it's a shared component used in many places. If there's a good reason, this change would be better suited to its own PR.

We should defintely undo these changes, and move them to a separate PR (if there's a strong reason to apply them)

getdave

Thanks for taking this on - the UI work looks great and this is a valuable feature.

The Issue

This PR creates a new core/entity binding source, but Navigation Links already use core/post-data and core/term-data for entity resolution. I think we need to align these (at least for 7.0) because:

Maintenance: fixes/improvements shouldn't happen in two places
Consistency: blocks linking to entities should work the same way
Future: other blocks need one clear pattern to follow

That doesn't mean we can't normalize both button and nav towards a new entity source in future but I don't see that happening for 7.0 timelines.

Proposed Fix

1. Store entity data in metadata

Button doesn't have id/kind/type attributes, so store them alongside the bindings:

metadata: {
  bindings: {
    url: {
      source: kind === 'taxonomy' ? 'core/term-data' : 'core/post-data',
      args: { field: 'link' }
    }
  },
  id: 123,
  kind: 'post-type',
  type: 'page'
}

2. Update existing binding sources

Modify core/post-data and core/term-data to check metadata for entity info first, falling back to current editor context if not found.

3. Remove core/entity source

This approach keeps Button minimal while using Navigation Link's existing infrastructure.

What do you think? I'm happy to explore this if you haven't got time. Noting that the cut off for 7.0 is tomorrow 😬

Vrishabhsk · 2026-02-16T10:48:29Z

Hi @getdave 👋

If its absolutely necessary to get this included in the 7.0 release i.e. tomorrow, i would suggest you take over since it may take a bit of back and forth before this gets to the merge status
If we plan to merge it for the release after 7.0, then im more than happy to rework the PR based on the recommendations and comments.

Let me know what will be the best approach. Thanks

getdave · 2026-02-17T16:30:41Z

Hi @Vrishabhsk. Apologies but this is not going to make the cut for 7.0. We need to bring in relevant UI updates as well to ensure we're properly communicate the state of "bound" links.

Based on experience introducing the original functionality in Navigation in 6.9 there were a lot of edge cases and trying to rush this in pre 7.0 cut off today is going to make for a less stable release.

I do think this is important and we should follow up in WordPress 7.1. We can continue to work on this right away here in the Gutenberg Plugin.

Thank you again for your hard work and I'm looking forward to working with you to get this into a good place really soon.

Vrishabhsk · 2026-02-20T11:55:57Z

Hey @getdave understandable. I'll start by taking into account the proposed fixes and feedback @ramonjd has shared.

Vrishabhsk · 2026-03-03T14:36:52Z

Hi @getdave 👋, im implemented your suggestions. Here is a quick summary of it :

Key Changes

Replaced core/entity source with existing core/post-data & core/term-data sources
- Removed the separate core/entity binding source
- Now uses the same sources as Navigation Link for consistency
Entity info stored in metadata (not binding args)
- id, kind, type stored at metadata level
- Binding uses args: { field: 'link' } only
PHP filters to support Button block in existing sources
- Added gutenberg_filter_block_bindings_post_data_value filter
- Added gutenberg_filter_block_bindings_term_data_value filter
- These intercept the core callbacks to read entity info from metadata for Button block
Performance fixes
- Wrapped clearEntityUrlBinding, createEntityUrlBinding, and unlink in useCallback

Vrishabhsk requested review from ajitbohra, fabiankaegy and spacedmonkey as code owners January 21, 2026 14:25

github-actions bot added [Package] Components /packages/components [Package] Editor /packages/editor [Package] Block library /packages/block-library labels Jan 21, 2026

Vrishabhsk mentioned this pull request Jan 21, 2026

Add dynamic URL resolution to Button Block #72314

Open

mtias added the [Block] Buttons Affects the Buttons Block label Feb 15, 2026

ramonjd reviewed Feb 16, 2026

View reviewed changes

getdave reviewed Feb 16, 2026

View reviewed changes

Vrishabhsk added 5 commits March 3, 2026 13:09

Implement new entity binding

4d36d0b

Implement entity-block binding in PHP

aabc6df

Implement dynamic-link capability for button block

d7dc143

Merge branch 'trunk' into add/button-dynamic-url

1650409

Address PR feedback

2015d96

Vrishabhsk force-pushed the add/button-dynamic-url branch from c48e200 to 2015d96 Compare March 3, 2026 14:34

Vrishabhsk requested a review from a team as a code owner March 3, 2026 14:34

Vrishabhsk changed the title ~~Add/button dynamic url~~ Feature : Button - Dynamic URL resolution Mar 3, 2026

getdave requested a review from ockham March 17, 2026 20:22

Conversation

Vrishabhsk commented Jan 21, 2026

What?

Why?

How?

Testing Instructions

Screenshots or screencast

Uh oh!

github-actions bot commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jan 21, 2026

Uh oh!

github-actions bot commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ramonjd left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

getdave left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

The Issue

Proposed Fix

Uh oh!

Vrishabhsk commented Feb 16, 2026

Uh oh!

getdave commented Feb 17, 2026

Uh oh!

Vrishabhsk commented Feb 20, 2026

Uh oh!

Vrishabhsk commented Mar 3, 2026

Key Changes

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

github-actions bot commented Jan 21, 2026 •

edited

Loading

github-actions bot commented Jan 21, 2026 •

edited

Loading

getdave left a comment •

edited

Loading