Bundle sub-menu maximum not honored

That's not a bug. Only the number of bundle for entity types are limited.

In the first place we added the limitation for UI reason and we did not think that the "Content > Add Content" sub links cause any trouble. But you're right! We could do the same maybe. I will change the issue category to Feature request.

Uploaded static patch for project needs.

I will work to fix the functional JavaScript test.

I was not able to fix the tests, add the schema and settings instead.

In AdminToolbarToolsSortTest.php the testMenuUpdate() keeps failing.
I realize that menu link are /media/add/chinchilla instead /admin/structure/media/manage/chinchilla but even with changes the tests failed.

Using the xpath selector in the console is possible to find element, but test get the error:

1) Drupal\Tests\admin_toolbar\Functional\AdminToolbarToolsSortTest::testMenuUpdate
Behat\Mink\Exception\ElementNotFoundException: Element matching xpath "//div[@id="toolbar-item-administration-tray"]//a[contains(@href, "/admin/structure/media/manage/chinchilla")]" not found.

Updated patch for latest 3.x-dev

Updated MR with latest 3.x-dev version and exported static patch file to use with installed 3.4.1 module version on the project.

Thanks a lot everyone for all the work and contributions in this issue, it's greatly appreciated! 🙏

I have taken a closer look at the issue summary and the comment from Jenny (@jennypanighetti) above at #3, and it would seem the problem described can still be reproduced with the latest version of the module.

Comment #3 also suggests we should clarify the use of:
Maximum number of bundle sub-menus to display
In particular, what is considered "bundle sub-menu" and where their display should be limited.

I personally agree with Jenny (@jennypanighetti) and think the behavior should be:
1 - Consistent across all menu items where bundles are used (for example "Content types" and "Add content" should have the same limit enforced) and
2 - For all entity types as well as config entities (Views, for example).

Note the point (1) above would be closer to fixing a bug and (2) closer to a feature request.

Additionally, the label and description texts of the corresponding configuration field, would also need to be updated to be clearer and align with the implementation chosen for the setting.

The requirements for this feature should be clarified before going further into any implementation.
We would need to go back through the tickets in which this feature was initially added and try to understand what the initial requirement was.

If the initial requirement was:

In the first place we added the limitation for UI reason and we did not think that the "Content > Add Content" sub links cause any trouble.

For UI or performance reasons (maybe): trying to set a limit to the number of menu link items the module could create and most importantly, display in its dropdown sub-menus.
If there are too many bundles or menu items in a sub-menu, then, there might not be enough room on the screen to display all the items and they would overflow out of the view port (not visible).

Perhaps there could be different approaches or more generic ones that could potentially provide simpler solutions to the initial problem.
Maybe setting a limit in general to all sub-menus at a certain depth could also work?!
Something like: "Maximum number of menu links to display in sub-menus"

Or something very specific like what was done in merge request MR !30 and patches above, allowing a very granular configuration of the maximum number of menu items per entity types, but with lots of fields.

Or maybe a completely different approach, fixed with a UI solution, see:
#2917168: Make the menu dropdown as scrollable.

We would greatly appreciate to have your opinion and feedback on this comment with the suggested logic and the steps to try moving this ticket forward.

Feel free to let us know if you have any questions, comments or concerns on any aspects of this comment or the issue in general, we would certainly be happy to help.
Thanks in advance! 🙂

Thank you @dydave for an excellent summary of the situation, I agree with all your considerations and suggestions.

I would guess that the majority of users don't even know what a bundle is ... they may just notice that under some menus, the number of items are limited to the maximum number, whereas under other, all are shown -- for example Views or Roles. Until a decision has been made on which solution to go for, the text could be updated, to spell out which sub-menus are currently affected, and which are not, and I created #3554351: Spell it out which sub-menus are affected by Maximum number to display setting.

It seems that:

• The Maximum sub-menu feature adds complexity to the code
• It would require work to make it work everywhere
• Expanding and maintaining the tests as well adds extra work

... so instead of working on getting it to work everywhere, it could be considered to remove it, to simplify the code base?

Alternative solutions for handling many menu items could be a scrollable menu, or a compact display, as can be seen in #2917168: Make the menu dropdown as scrollable. and #3553200: Add support for compact display options.