When adding a new menu link, restrict the available parents to the current menu

great work, I just did some performance profiling on this, shaved off 3000 milliseconds on my test case.
queries were down too, this is an improvement over the sansdesordre solution I created earlier.

I have about 3000 menu links, looking to squeeze some better performance, this is a significant improvement so I'm taking it while we look for even more performance.

this is also a usability improvement so yay!

if you want, I can provide some before after profiling stats.

when using xhprof , 3000 menu items, rebuild cache then load the add node or edit node page for the first time before cache is built, major expensive page load, xhprof of course slows things down.

say 30 seconds before patch

after patch: 27 seconds.

without xhprof module, cut this in half, still a significant improvement and also is a usability improvement.

patch reroll for D9.1.x

This will prevent people changing which menu a link is in, unless there's another place that can be done?

There are some other core issues discussing this (which I can't find, but will try to link here if I do), as well as an (old) contrib project trying to solve the performance problem. https://www.drupal.org/project/hierarchical_select

Applied patch #10 and it works fine.

Before patch:

After patch:

RTBC +1

This will prevent people changing which menu a link is in, unless there's another place that can be done?

Yes however most of the time this patch is a usability improvement (decluttering drop down), contrib can deal with changing a menu a link is in.
also is a performance and scalability improvement.

alternatively, make moving menu links to different menus require a special permission

quote of @catch:

unless there's another place that can be done?

Yes I did this in another place, I created a module called sansdesordre to deal with this usability issue however when I discovered this patch it also improves performance and I have done XHProf profiling on it and with 3000 menu links I get a 10% improvement in some cases when using this patch.

So I'm switching from a contrib solution to this core patch as it both improves performance/scalability AND improves usability whereas my contrib solution only improves usability.

Patch #10, fixes the issue. Only the 'Parent link' is visible to the current menu.

Moving to RTBC.

catch: unless there's another place that can be done?

joseph.olstad: Yes I did this in another place

No I mean unless there's another place in the Drupal admin UI to change the menu a link appears in. As the patch currently stands, it's taking something that was possible in the UI and making it impossible. Tagging for product manager review.

@catch, yes understood, this change would require a new interface option to move menu link to another menu. However I would say the main reason for needing this would be mistakes made due to the current interface being confusing and leading to mistakes being made (putting menu links into a menu other than the one currently being edited). If we change this behavior there'll be less mistakes being made from the content side, usability, performance and scalability benefits.

However I would say the main reason for needing this would be mistakes made due to the current interface being confusing and leading to mistakes being made

I think the main reason is more likely to be moving default menu links provided by modules from the 'main' menu to the footer or user account menu or similar.

@catch, yes I do see the utility of being able to move a menu link using the GUI from one menu to another.

With that said, it's an edge case in comparison to the most common uses of the menu ui and at worst the current implementation is a performance drain when loading the node form that has the 'menu' option enabled. I measured a 3 second improvement using the above patch with a site that has about 2500 menu links and 2500 translations. I'm not sure how many people want 2500 menu links in a drop down. My use case is a bit special in that we're generating (on purpose) disabled menu links (for breadcrumb and friendly url pathauto) for a certain content type who's links fit under another.

Scalability is important and as sites grow the current out of box interface gets more and more cluttered and slower to use.

What I would like to see is a more targetted UI and the use case of 'moving a menu link' from one menu to another should be very low priority and more of an edge case that perhaps might be best suited for contrib to deal with.

Seeing as we have no test coverage for moving menu links around it seems like it was probably an afterthought at best.

***EDIT***
we're using the above patch in combination with the following patch:
#3202930: MenuTreeParameters::onlyEnabledLinks is ignored when building the menu tree render array

performance profiling results (test case: rebuild cache, then visit the add node form)
before patching, wall is 30 seconds on a 5000$ high-end server with 7000 mb/s nand pcix4x
after patching with both mentioned patches, wall drops to 3 seconds on the same server

approx 56000 queries to the db, performance tested on a non-admin role (access query on each menu link)

PM me and I can send you the link to the performance test results
***EDIT***

just emphasizing this:

huge difference in performance results when using the administrator role vs a non-admin role, much more queries for access when using a non-admin role

most of our content people are NOT admins so they get the slow results.

With that said, huge improvement when using the two mentioned patches.

performance baseline testing focused on a clean cache

#10 works for me

This patch seems to be a huge UX improvement as well as performance. If changing a link to a different menu is an important feature, I guess having a separate field to choose the menu makes more sense than a parent link with all menu's / all menu links. The administration menu alone adds enough links to make the dropdown really unfriendly for regular editors.

Successfully tested #10 against 9.4.x. I had troubles applying the patch against 9.4.x:

$ git branch
* 9.4.x
$ git apply ./D91x-3110371-4.patch
error: patch failed: core/modules/menu_ui/tests/src/Functional/MenuUiTest.php:703
error: core/modules/menu_ui/tests/src/Functional/MenuUiTest.php: patch does not apply

So I rerolled it.

Another option: https://www.drupal.org/project/menu_lock

#27 patch Applied Successfully and working fine for me on Drupal 9.4.

@fengtan
Thanks for the #27 patch successfully applied in 9.4
for ref sharing screenshot ............

#31 @vikashsoni there's no benefit in providing screenshots after a prior comment has already done so (#30) in this case, they happen to be empty images, too.

Just a reminder to everyone here, this functionality can also be resolved by contrib however the core patch is higher performance.

For those interested in the contrib solution, I just published a Drupal 10 compatible release.
https://www.drupal.org/project/sansdesordre

Also, the contrib module only optimises the menu for non-administrators whereas the core patch optimises for all roles.

With that said, the core patch gives you better performance so I recommend the core patch however for those that may not be worried about performance or have very small sites with small amounts of content and few menu links there is a contrib solution.

While the performance issue of the menu parent select field is definitely an issue on large sites, I don't think this actually needs product manager review. The current approach is not workable because it is a significant feature regression.

Marking as a duplicate of #191360: Scalable menu selector which has the scope we need of improving the widget (rather than just removing part of its functionality). Thanks!

Actually #2346973: Improve usability, accessibility, and scalability of long select lists is the best issue here -- I recommend focusing on that, since we need this same fix for other select fields too.

Oops, half-typed re-title.

The current approach is not workable because it is a significant feature regression.

@xjm, I think there's a legitimate bug here, but the issue went a little off track by mixing in performance and scalability concerns.

What's the bug?

In short, if I'm on the /admin/structure/menu/manage/main/add route (note the main route param), I shouldn't be able to create a new menu link in the footer menu, but I can.

To expand on that: imagine if you're editing the Main navigation and you follow the Add link button. Now also imagine that you probably have a menu link with the same name in both the Main navigation and Footer menu. On the create form, you accidentally choose the link in the Footer menu because you (understandably) assumed that you're adding a link to the Main navigation. Worse, after you click save, you'll be redirected back to the Main navigation overview and you'll be presented with a green status message saying "The menu link has been saved," however you will not see your newly created menu link since it was actually added to the Footer menu.

@gabesullice, yes you've nailed it, it's also a performance issue, if one of your menus has 3000 links like ours, most of them disabled and used by menu_breadcrumbs, then you're going to have performance issues that are solved with this patch and the other patch I mentioned.

Agreed with #39, there's a genuine usability issue with the menu create form that's separate from the scalability one.

When you're in admin/structure/menu and want to add a new content menu link, you're presented with possible parents of every menu item in every menu on the site, this can be hundreds. In my case, the menu I wanted to add to had five items. Fat-fingering the scroll, or missing a -- and you can be lost somewhere in admin/config with no obvious way to get back to the menu you're actually trying to change.

If we do #2346973: Improve usability, accessibility, and scalability of long select lists it would make the massive select list more manageable, but it'd still be unnecessarily long due to all the irrelevant menus in there.

If we only make this change on create, then if you really do want to change your mind, you can just back out and go to a different menu and add the link here, so there's no functionality regression only the usability improvement. As discussed above it's impossible to make this change on edit, it needs the long list of options and a scalable widget for that.

Patch looks fine I think but needs test updates - we should probably expand the coverage so it handles both the create and edit cases.

Agreed with @catch. Not sure if it even is a duplicate in any sense, 1.) because there are already interesting patch attempts here in it and 2.) the other one is on a bigger scope than menus only and can be seen as related or parent but not as replacement IMHO.

This seems totally reasonable. I'm marking this as a bug since this is certainly a usability issue that could prevent someone from finding the correct parent.

Checked the latest MR and the solution looks good, and I don't see how this could be a regression. 💯 I think we just need a test case to confirm it works and that it continues to do so.

Removing needs tests tag as it seems they were added in the MR with some assertions to existing tests.

This change seems like a no brainer and works as described!

Updated change record slightly with screenshots and branch numbers.

Opened a follow-up to address this in the edit menu links use case: #3384373: The menu UI selector is not scalable.

Committed c90f093 and pushed to 11.x. Thanks!

Great to see this one go in! Usability and a significant performance win.
Thanks @omkar.podey for the work on the automated tests.

Hey, could you please make this patch working with Drupal 10.2?

Thanks @idebr