Add LinkControl search input to navigation link block sidebar (WIP) #71452
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
- Replace Text, Link, and Open in new tab fields with LinkControlSearchInput - Add submit button with keyboardReturn icon for manual URL entry - Add reset button with closeSmall icon when URL exists - Update CSS to make search results work properly in sidebar context - Only apply 300px min-width to URL inputs in popovers/block list blocks - Use absolute positioning for search results in non-popover contexts - Add white background and border styling for search results in sidebar WIP: Navigation link block LinkControl integration
getdave
added
[Type] Enhancement
getdave
commented
Sep 1, 2025
| } | ||
|
|
||
| // Only apply min-width to URL inputs within popovers or block list blocks | ||
| .block-editor-block-list__block .block-editor-url-input, |
Contributor
Author
There was a problem hiding this comment.
I'm not sure of the context as to why we need .block-editor-block-list__block here 🤔
getdave
commented
Sep 1, 2025
Comment on lines
262
to
281
| onCreateSuggestion={ async ( pageTitle ) => { | ||
| const suggestionPostType = attributes.type || 'page'; | ||
|
|
||
| const page = await saveEntityRecord( | ||
| 'postType', | ||
| suggestionPostType, | ||
| { | ||
| title: pageTitle, | ||
| status: 'draft', | ||
| } | ||
| ); | ||
|
|
||
| return { | ||
| id: page.id, | ||
| type: suggestionPostType, | ||
| title: page.title.rendered, | ||
| url: page.link, | ||
| kind: 'post-type', | ||
| }; | ||
| } } |
Contributor
Author
There was a problem hiding this comment.
We need to extract a share util for this to use here and in the Link UI.
getdave
commented
Sep 1, 2025
Comment on lines
+282
to
+309
| suggestionsQuery={ ( () => { | ||
| const { type, kind } = attributes; | ||
| switch ( type ) { | ||
| case 'post': | ||
| case 'page': | ||
| return { type: 'post', subtype: type }; | ||
| case 'category': | ||
| return { type: 'term', subtype: 'category' }; | ||
| case 'tag': | ||
| return { type: 'term', subtype: 'post_tag' }; | ||
| case 'post_format': | ||
| return { type: 'post-format' }; | ||
| default: | ||
| if ( kind === 'taxonomy' ) { | ||
| return { type: 'term', subtype: type }; | ||
| } | ||
| if ( kind === 'post-type' ) { | ||
| return { type: 'post', subtype: type }; | ||
| } | ||
| return { | ||
| initialSuggestionsSearchOptions: { | ||
| type: 'post', | ||
| subtype: 'page', | ||
| perPage: 20, | ||
| }, | ||
| }; | ||
| } | ||
| } )() } |
Contributor
Author
There was a problem hiding this comment.
|
Size Change: +522 B (+0.03%) Total Size: 1.92 MB
ℹ️ View Unchanged
|
- Fix displayUrl logic to properly distinguish between undefined URL and empty string - Ensures showInitialSuggestions works correctly when input is focused - Initial suggestions now appear immediately when focusing empty Link field
- Wrap URLInput with withFocusOutside HOC to properly handle focus events - Replace onBlur logic with handleFocusOutside method - Add hasFocus state to control when initial suggestions should appear - Fix event ordering issue where suggestions were hidden before clicks could be processed - Use same proven pattern as ComboboxControl for reliable focus management This resolves the issue where selecting initial suggestions in navigation link blocks was not working due to blur events interfering with click processing.
|
Flaky tests detected in 94319c7. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17404794880
|
Contributor
Author
Screen.Capture.on.2025-09-02.at.15-10-16.mp4I'm currently blocked by this bug. Essentially the "local" version of the URL isn't being reflected in the UI even though the underlying state is all set correctly. I'm suspicious of the "outside focus" handling. |
Contributor
Author
Bug Summary: Input Field Not Displaying URL After Initial Suggestion SelectionProblemWhen using
Root CauseThe issue appears to be in the controlled input state management within the component chain: Attempted Fixes
Current StatusBug persists despite correct prop values. The issue seems to be in WorkaroundTemporary |
Contributor
Author
|
This needs a rebase to
|
Contributor
Author
|
@scruffian Given #72622 should we just use the entire LinkUI here with the preview and everything rather than just the |
Contributor
I think so, but I think we don't want the dialog. |
Contributor
Do you mean showing the preview pane in the sidebar? 
|
Contributor
Author
Yes exactly this. But no popover involved. Just allow it to render "as is". I think it's probably a better experience that you think? Why? Because it solves a couple of problems such as:
I really think it's worth at least trying that route. |
Contributor
I wonder if people will dislike the "click to edit" a field that could be exposed from the start. It also makes the save flow a bit odd. For example, do you show an Apply button after they edit it to "save" this value? Will the link text also be hidden behind this field so it matches the on canvas popover? Initially I thought it could be a good idea, but I'm starting to feel like it's too much of a diversion from how the sidebar editing typically happens. The editing flow makes sense within a popover but not as much within the inspector IMO. |
Contributor
Author
It does avoid the nasty UX involved with editing link text and having to do stuff on blur and focus though. Given that it may solve several issues I wondering whether we should try both variations and test which one provides the best UX. What do you think? |
Contributor
I've been trying to think through what the one using the preview pane to enter/exit would look like in practice. I think it would need to be used as a focus-trapped modal like the on-canvas version, as it needs a save/apply button. There is a precedent for this with things like the color selector opening a popover from the inspector. But, in this case, I'm not sure why we wouldn't just inline the fields. Maybe I'm not understanding the potential benefit though. How do you see the preview pane in the inspector working, and why would it improve ux?
|
Contributor
Author
I think #73043 outlines my vision quite well now. Specifically by having the preview -> editing UI that's provided by the
We'd also
That said the above has to be offset against the UX concerns you mentioned. That's why I think exploring/prototyping both approaches (this PR does one already to an extend) might help us to make the issues more concrete. That will allow us to draw more accurate conclusions about how to proceed. |
This was referenced Nov 20, 2025
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
This PR addresses the UX improvement request for the Navigation Link block by replacing the "static"
Linkfield in the inspector controls with a dynamic variant similar to the Link UI shown in the canvas.Fixes #48072: Add LinkControl search input to navigation link block sidebar
Also related to #65699
Why
The current navigation link block shows different UIs depending on context - a popover for initial link creation and separate inspector fields for editing.
This creates a confusing and inconsistent user experience. The issue #48072 describes this in more detail.
By integrating the LinkControl search input directly into the inspector controls, users get a consistent, unified interface for both creating and editing links with search, suggestions, and rich previews.
How
Testing
Screenshots
Screen.Capture.on.2025-09-01.at.16-30-48.1.mp4
Breaking Changes
None - this is an enhancement that maintains existing functionality.
Follow ups
This approach should be extended to navigation submenu block.