Identify items used in current menu in menu selection panels.

[Dblii]

I use wordpress for more than 15 years i still wondering why you dont make the menu section easier, for example if someone have more than 100 categories in a woocomerce he can be lost in the categories and subcategories. It should be good idea to show BOLD wich of items are in use in the current menu preview, so can be easy use the other items. also need more flexibility in menu items column

[knutsp]

Interesting. Do mean the Customize - Menus section?

There could be some visual indication in the secondary column of items that are already in the menu being built in the left column, so that you not by accident, add the same item (category or other) more than once. Is this what you are thinking about?

There could also/instead be some textual warning that the item is already in/on the menu, so you could immediately remove the duplicated item.

Maybe not bold, but the opposite, greyed out or something else? The items are already bold.

[SergeyBiryukov]

Potentially related: #18282, #19837, #40827, #47639.

[SergeyBiryukov]

Just to clarify, is this indeed about the Customize → Menus section, or the Menus screen in the admin?

[Dblii]

I talk about appearance -> menu also there is a bug when there is more than 50 items the second pagination items looks broken from parent category

[Dblii]

Replying to knutsp: Yes EXACTLY THIS in customiser menu section or in appearance -> menu section better

Interesting. Do mean the Customize - Menus section?

There could some visual indication in the secondary column of items that are already in the menu being built in the left column, so that you not by accident, add the same item (category or other) more than once. Is this what you are thinking about?

There could also/instead be some textual warning that the item is already in/on the menu, so you could immediately remove the duplicated item.

Maybe not bold, bu the opposite, greyed out or something else? The items are already bold.

[knutsp]

Replying to Dblii:

I talk about appearance -> menu also there is a bug when there is more than 50 items the second pagination items looks broken from parent category

I believe it's most wise to address one UI per ticket. So this ticket is about Customize → Menus section only. Apperance → Menus screen in another ticket. ok?

[Dblii]

Ok

[afercia]

This ticket was discussed during today's accessibility bug-scrub.

Worth considering that adding the same item multiple times to the same menu (in different sub-menus for examples) may perfectly make sense.

To recap:

• In the Customizer, the "checkmark sign" doesn't persist. After the menu items panel gets closed and reopened, there's no checkmark and no indication which items are "already added" to the menu.
• Same in the Menus page, where the menu items are checkboxes though. Their "checked" state is already used to select them so I'm not sure how to indicate they're 'already added".

In both cases, it is a legitimate case that users may want to add a menu item to a menu multiple times.

[afercia]

Also:

• in the customizer there are audible messages for screen reader users: Menu item added, Menu item deleted
• in the Menus page, there are no audible messages

This feedback is purely visual; it's going to need to also be available to screen reader users. Perhaps by appending screen-reader-text with the text "(in current menu)" to the item.

Thanks @joedolson for the quick review 🙇
I have updated the PR to improve accessibility.

[oglekler]

@joedolson check it please, is it ready for testing?

I think the in current menu and already in current menu are pretty much synonymous; but I'll ask some screen reader users for opinions here.

If you have an opinion, @alexstine, that would be appreciated.

@AKSHAT2802 @joedolson The text "in current menu" is fine. Thanks.

In testing, I found that this has a pretty strange bug - when I attempt to scroll the list of pages, most of the items disappear. I don't have time right this moment to track this down, but I wanted to mention it in a comment now, if you want to try to explore it @AKSHAT2802.

To reproduce: I was testing in Firefox on MacOS.

Open the customizer, going to add items to a menu.

Before doing anything else, swipe on the track pad to explore the list of pages. In my test, this resulted in most items in the list disappearing. I haven't yet explored this further, yet.

Additionally, the same functionality will need to be applied in both the admin menu management and in the customizer; we want to always try and keep user experience parity between those two interfaces.

In testing, I found that this has a pretty strange bug - when I attempt to scroll the list of pages, most of the items disappear. I don't have time right this moment to track this down, but I wanted to mention it in a comment now, if you want to try to explore it @AKSHAT2802.

To reproduce: I was testing in Firefox on MacOS.

Open the customizer, going to add items to a menu.

Before doing anything else, swipe on the track pad to explore the list of pages. In my test, this resulted in most items in the list disappearing. I haven't yet explored this further, yet.

Hii @joedolson
I’ve retested this PR, and it’s working well for me. Items are not disappearing when scrolling in the Customizer, and the font weight correctly reflects the intended behaviour — unused items are bold and in-use items are normal.
(Tested on Chrome & Firefox for MacOS)
PFA:

​https://github.com/user-attachments/assets/e777f215-16ac-42bd-811a-4b0a94a2f8c5

Additionally, the same functionality will need to be applied in both the admin menu management and in the customizer; we want to always try and keep user experience parity between those two interfaces.

Thanks for the feedback. As mentioned in the comment, I thought this ticket was scoped only to the Customizer → Menus section, so this PR focuses on that interface.

I agree that parity should also be maintained in the Appearance → Menus screen. Could you please guide me on how we should differentiate the items there? 🙇 At the moment, items in that screen are displayed in normal font weight by default.

I'd say that the comment that suggests that ticket was about the customizer was actually wrong; based on the original reporter, I'd say that the ticket was about the admin menu manager. Regardless, I generally prefer to do both at the same time, to ensure that we're keeping the two interfaces in sync.

Re: differentiating on appearance.

I actually don't think we should use font weight to do this in either menu. To me, it's not very clear.

For the admin menu management, where there are checkboxes in use, perhaps we can use the same mechanism that the bulk editor uses for managing categories? It uses an indeterminate state for checkboxes. See https://core.trac.wordpress.org/changeset/57580 for how that was done.

For the customizer, there's an existing "selected" state added by the class item-added on the menu-item-handle div. That state is used to visually indicate that you have added an item to the menu; a similar state could be used to indicate that a listed item is already in the menu. I'd just use the same state, but without reducing the contrast.

[joedolson]

With no movement on the PR in the last month and 6.9's beta 1 only a week away, I'm going to move this to Future Release. It is reasonably well progressed, so I hope that it can move forward in 7.0.