Fix Choose menu label when a menu has been deleted. #67009
Merged
Conversation
This file contains 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
afercia
added
[Type] Bug
|
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: +16 B (0%) Total Size: 1.83 MB
ℹ️ View Unchanged
|
|
Attempting to fix the failing test. I have a question: |
|
Flaky tests detected in f8a78c0. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12236551901
|
ntsekouras
reviewed
Nov 15, 2024
| @@ -106,12 +107,18 @@ function NavigationMenuSelector( { | |||
| const noBlockMenus = ! hasNavigationMenus && hasResolvedNavigationMenus; | |||
| const menuUnavailable = | |||
| hasResolvedNavigationMenus && currentMenuId === null; | |||
| const navMenuHasBeenDeleted = currentMenuId && isNavigationMenuMissing; | |||
There was a problem hiding this comment.
In trunk we have some similar checks and others with hasResolvedNavigationMenus && isNavigationMenuMissing. I'm wondering why that difference and mostly why isn't isNavigationMenuMissing is doing this check internally in the hook.
@afercia 's comment about Specifically in this scenario, currentMenuId && isNavigationMenuMissing is true, while menuUnavailable is false. and why we weren't passing the id here are good ones. Maybe @getdave or @draganescu have more context?
There was a problem hiding this comment.
why isn't isNavigationMenuMissing is doing this check internally in the hook
I assume you mean check for hasResolvedNavigationMenus? One of the main problems with the code of the navigation block is that it is a blueprint of all the pitfalls we've ran through as the block evolved. I remember these checks Is* and has* have been part of a "refactoring" to herd some of the repeating code.
currentMenuId && isNavigationMenuMissing
This check is very valid, I am unsure what the question is, it means: the block has a navigation id assigned but it's missing.
There was a problem hiding this comment.
The first question is how currentMenuId && isNavigationMenuMissing and hasResolvedNavigationMenus && isNavigationMenuMissing are different. Related to this is why isNavigationMenuMissing not checking this internally, so we wouldn't need the first part of the above checks.
The other two from @afercia are:
- Why currentMenuId && isNavigationMenuMissing is true, while menuUnavailable is false (this is mentioned in the PR's description.
- why we weren't passing the id
There was a problem hiding this comment.
I guess the easiest way to clear things up are via code, I find it unlikely somebody knows that by heart 🤷🏻 Particularly the menuUnavailable bit, which sounds like a bug?
As to why we're not passing the id I think the main reason is it wasn't meant to and probably evolved in a way in which it now seems that it should.
@ntsekouras by reading this test name To my understanding, despite its name, the In this PR, we need to check whether the menu is missing or not so that, to my understanding, we need to pass the ID. As an aside, I'd think the documentation of the hook is unclear and should be improved. It would be good to make clear that the ID is necessary to get reliable values about the current menu. On the other hand, I'm not sure returning values anyways even when the ID is missing makes the Any thoughts and a new review welcome 🙏🏻 |
afercia
force-pushed
the
fix/choose-menu-when-missing
branch
from
bfd0f10 to
f8a78c0
Compare
|
Rebased. |
afercia
force-pushed
the
fix/choose-menu-when-missing
branch
from
f8a78c0 to
3fa3387
Compare
6 tasks
|
I created #67828 to consider some audit and better documentation of the |
ntsekouras
approved these changes
Dec 17, 2024
There was a problem hiding this comment.
Nice sleuthing @afercia! That API could use some simplifications..
This looks good, thank you!
|
@ntsekouras thanks for your review! |
yogeshbhutkar
pushed a commit
to yogeshbhutkar/gutenberg
that referenced
this pull request
Dec 18, 2024
* Fix Choose menu label when a menu has been deleted. * Pass menu ID to useNavigationMenu. Co-authored-by: afercia <[email protected]> Co-authored-by: ntsekouras <[email protected]> Co-authored-by: draganescu <[email protected]>
yogeshbhutkar
pushed a commit
to yogeshbhutkar/gutenberg
that referenced
this pull request
Dec 18, 2024
* Fix Choose menu label when a menu has been deleted. * Pass menu ID to useNavigationMenu. Co-authored-by: afercia <[email protected]> Co-authored-by: ntsekouras <[email protected]> Co-authored-by: draganescu <[email protected]>
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.
Fixes part of #59431
What?
See #59431 (comment)
When a menu has been deleted, the settings panel shows a warning Notice. In that state, the ellipsis button to choose a menu is unlabeled. The condition to set the dynamic label fails and doesn't take into account this scenario.
Why?
All controls should always be properly labeled.
How?
It appears the condition to render the Norice:
gutenberg/packages/block-library/src/navigation/edit/menu-inspector-controls.js
Line 96 in a120f10
is slightly different from the condition(s) used to determine the ellipsis button label:
gutenberg/packages/block-library/src/navigation/edit/navigation-menu-selector.js
Lines 105 to 117 in a120f10
Specifically in this scenario,
currentMenuId && isNavigationMenuMissingis true, whilemenuUnavailableis false.I'm not familiar with this part to determine whether
menuUnavailableis incorrect in the first place and whether it should be reviewed. For now, I'm just adding one more check, which is the same one used for the Notice, to render the label 'Choose or create a Navigation Menu'. Any feedback on the currentmenuUnavailablewould be appreciated.Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast