Solution for long dropdown submenu

[GulomovCreative]

What does it do?

1. Add new system setting topmenu_submenu_max_items
2. Check this setting and moves remainings items to new item with label "More"
3. Add right arrow/triangle for menu items that have children

Process gif

Why is it needed?

Description from #11939

When there's a long Extras dropdown menu, and not enough screen space, the bottom items get cut off. It's not possible to scroll down or access them.

Related issue

Closes #11939

[JoshuaLuckers]

PR’s with new functionality should target the 3.x branch

[Ruslan-Aleev]

@JoshuaLuckers This problem is not relevant for 3.x. I think better in 2.x.
Although PR with an icon in the list is present for 3.x

[JoshuaLuckers]

The maximum amount of items should also apply here.

[Jako]

It should be relevant for 3.x, too. Scrolling in menus should be made avoidable, if possible.

[Ruslan-Aleev]

@Jako Yes, literally a couple of hours found the same problem in MODX3, although I had not noticed before. Therefore, it is not clear what to do with PR.

[Mark-H]

So, I see 2 scenarios for this (really cool!) improvement.

We either approve it for 2.x, in its current form, and then when 2.x gets merged into 3.x that'll likely cause weird conflicts that need to be manually resolved.

Or, this PR is updated to target 3.x instead. That probably means a bit more work to get things looking just as nice, but it'll avoid that responsibility falling on the integrators doing a merge (which is typically complicated enough, and those integrators may not always know all the intricacies of individual PRs when doing that).

So (for completely selfish reasons :D), my vote would go to making it ready for 3.x instead. That then also adds another great reason to hurry with finishing that up for a proper release, and we could add a sensible default (maybe 10?) to the setting that controls it so it kicks in automatically :)

[GulomovCreative]

So, I see 2 scenarios for this (really cool!) improvement.

We either approve it for 2.x, in its current form, and then when 2.x gets merged into 3.x that'll likely cause weird conflicts that need to be manually resolved.

Or, this PR is updated to target 3.x instead. That probably means a bit more work to get things looking just as nice, but it'll avoid that responsibility falling on the integrators doing a merge (which is typically complicated enough, and those integrators may not always know all the intricacies of individual PRs when doing that).

So (for completely selfish reasons :D), my vote would go to making it ready for 3.x instead. That then also adds another great reason to hurry with finishing that up for a proper release, and we could add a sensible default (maybe 10?) to the setting that controls it so it kicks in automatically :)

@Mark-H I got it. I will make it ready for 3.x. Thx!

[JoshuaLuckers]

@GulomovCreative is this still on your radar? If you need any help please let us know.

[Mark-H]

Closing as the consensus is to recreate this for 3.

[Ruslan-Aleev]

Guys, maybe it's worth merge this fix into the 2.x after all? On some projects it is not possible to work with the menu in principle.