-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Simplify and improve navigation link creation flow #73210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
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. |
|
Size Change: +165 B (+0.01%) Total Size: 2.51 MB
ℹ️ View Unchanged
|
| // be lost during the new block selection process. | ||
| useEffect( () => { | ||
| if ( isNewLink.current && isSelected && ! url ) { | ||
| if ( isNewLink.current && isSelected ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
! url check is unnecessary since ! url is already part of the isNewLink check.
|
|
||
| if ( | ||
| ! url || | ||
| ( ! url && ! ( hasUrlBinding && isBoundEntityAvailable ) ) || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ! ( hasUrlBinding && isBoundEntityAvailable ) check is necessary as bound links will evaluate as null while resolving.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we combine this and the same code on line 493 into one const?
| ( ! url && ! ( hasUrlBinding && isBoundEntityAvailable ) ) || | ||
| isInvalid || | ||
| isDraft || | ||
| ( hasUrlBinding && ! isBoundEntityAvailable ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like ( ! url && ! ( hasUrlBinding && isBoundEntityAvailable ) ) and ( hasUrlBinding && ! isBoundEntityAvailable ) should be within the isInvalid check instead of being separate conditions. Maybe this should get done AFTER the RC though?
getdave
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very close. I found one edge case which appears to be when moving from a custom link to an synced link. See screenshot.
The popover immediately opens on the new link.
Screen.Capture.on.2025-11-13.at.15-34-21.mp4
|
@getdave I can move from custom url + link popover open to a synced page and it works fine. I think there's something wrong with entity binding and tags on trunk. This screen recording is from trunk. I added a tag block to the navigation menu and it shows the purple sync icon but the sync error message appears: Screen.Recording.2025-11-13.at.11.31.49.AM.mov |
|
video.webm
If change the text from "Uncategorized" to "Cat" in the test, it passes consistently. This is the difference between a synced page (Cat) and a category (Uncategorized) It's possible this is just due to the Add Block flow and not specific to pages though |
c40506c to
1a3042a
Compare
|
Are we still targetting WP 6.9 for this? |
I think it's too big of a change. I've simplified the case to fix the most serious bug in #73368, but will save the larger ux and code change for 7.0 |
|
Let’s please change the labels accordingly 🙂 |
scruffian
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good and works as described. Just left a few nits...
| const isNewLink = useRef( ! url ); | ||
| // A link is "new" only if it has an undefined label | ||
| // After the link is created, even if no label is provided, it's set to an empty string. | ||
| const isNewLink = useRef( label === undefined ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In #73368 we use a different method to check isNewLink.
const isNewLink = useRef( ! url && ! metadata?.bindings?.url );
Should we use that here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
label is actually more reliable. It's always undefined when a new link is created, then after the link is created it becomes an empty string.
| hasChildren: !! getBlockCount( clientId ), | ||
| validateLinkStatus: enableLinkStatusValidation, | ||
| parentBlockClientId: parentBlockId, | ||
| isSubmenu: parentBlockName === 'core/navigation-submenu', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just thinking... If we combine these two blocks into one we're going to need a different way to identify submenus...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likely an attribute. isSubmenu.
|
|
||
| if ( | ||
| ! url || | ||
| ( ! url && ! ( hasUrlBinding && isBoundEntityAvailable ) ) || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we combine this and the same code on line 493 into one const?
822ac6a to
d71040c
Compare
| * Cancels editing state. | ||
| */ | ||
| const stopEditing = () => { | ||
| isEndingEditWithFocusRef.current = !! wrapperNode.current?.contains( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isEndingEditWithFocusRef.current was being set and no longer used. Removing it for cleanup.
| const textInputRef = useRef(); | ||
| const searchInputRef = useRef(); | ||
| const isEndingEditWithFocusRef = useRef( false ); | ||
| // TODO: Remove entityUrlFallbackRef and previewValue in favor of value prop after taxonomy entity binding |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for documenting this here, it will make it a lot easier to remove it when the time comes.
…ing block selection
bad68e1 to
a7aea0d
Compare

What?
Closes #73171 and #73178
In #72142, block selection was changed to happen at the END of the cycle (onClose). This helped remove some unnecessary states, but caused an issue where your block inspector controls are not available for your new nav block until you close the link ui. This PR updates block selection to happen at the earliest moment we have a stable block - the onChange event from the LinkUI.
There is one workaround in which we need to use a query selector to access the submenu link appender when a new submenu link is created. This is the only case a new link is added without using the block appender. The first submenu link item is added when pressing the submenu button on the top level navigation link item toolbar. All other instances we can let focus naturally return to the ad link appender.
Why?
Simplify the code, and shows the newly added link in the inspector sidebar as soon as possible. Allows an easier and faster navigation menu creation process.
How?
Within the onChange event from the LinkUI when adding a new link, call
selectBlockon the newly added link with the second parameter as nulll so it does not send focus to the block. This allows the link to stay focused and open, while having the sidebar inspector show the newly selected navigation link item information. This is a more similar behavior to how it was before 6.9.Testing Instructions
adding a navigation link
adding a new submenu
adding a submenu navigation link
Testing Instructions for Keyboard
Screenshots or screencast
Before
After