[DX][UX] Mega-menus in core

[klonos]

So here's a crazy/cool thought: ...as pointed out in #2207, our recently added SmartMenus library (that handles core drop-down menus) also supports mega-menus:

mega-menus in core for 1.6.0!!! ...all it needs AFAICT is a mega-menu class added to the <ul>, a "Mega menu item" content type in core or alternatively a simple textfield that allows full HTML (or both options) and then we can have the menu UI allow embedding existing content as mega-menu items 😜

[jenlampton]

I'm not sure this is an 80% use-case. How about we let a solution evolve in contrib first, and slate it for core once we're sure it's wanted?

[laryn]

@klonos This would be very cool -- with ability to add blocks into a submenu for example (so you could add a Views block under a menu item, etc.)

[klonos]

My thoughts precisely @laryn. I was actually thinking about adding the login block as a mega-menu item on the account menu as a solution for #2207 (since #2163 removed the sidebar from the home page along with the login block).

[laryn]

@klonos I've never used these but wonder if these modules could plug into this concept, perhaps with some modification/cleanup:

https://www.drupal.org/project/menu_views
https://www.drupal.org/project/menu_attach_block

[klonos]

@laryn I have used both of these modules before and actually on multiple occasions. Menu Views especially was super handy in one site where I needed to automatically add created content to a specific menu, without exposing the menu options to content editors. You see, when creating a content type, you have the option to select which menus will be available to content editors ("Menu settings" vertical tab) and you can also set a default parent menu item:

...BUT unfortunately, you cannot "lock" the default menu item nor can you set a "please select one" value that would prevent the users skipping the selection of proper menu parents.

So the site had a series of top-level menu items in their primary navigation (I can't remember the exact use case, but for the sake of this example lets say "Animals", "Birds", "Fish", "Team", "About"). The site owner had specifically requested one single content type for adding all animals and the separation to animals/birds/fish was done by a vocabulary with fixed terms rendered as a drop-down menu options when creating animal nodes. There was a single view with 3 displays for the animals, birds and fish and another view listing user profiles. The goal was to have all added animal nodes "automagically" go under the respective top-level menu item depending on which kind of animal it was and of course all user profiles tagged as team member under the "Team" menu item. So, I have set the default parent to be the primary nav menu for the animal content type and content editors were supposed to a) select the appropriate animal type from the taxonomy menu (required in order to place the animal in the correct page of results rendered by views) AND b) also select the appropriate menu parent (so that the animal entry goes under the proper menu parent). As you can imagine, users would select the proper animal type (the taxonomy field was required, with no default value set), but would skip selecting the corresponding menu item (because menu settings are "buried" under the menu vertical tab). The result: "polluted" primary navigation menu with animal entries at its top level. At this point I pointed to the site owner that this would have been avoided if there were 3 separate content types for each animal type. Each would have their own default parent menu item predefined and it wouldn't matter if content authors skipped the menu settings step. Also, taxonomy fields can be set to be required, so users could not skip the selection of animal type (or there would be validation error), but I could not do something similar for the parent menu.

Menu Views to the rescue... the view with the 3 separate displays was already there, so all I had to do was to replace the menu items for animals, birds and fish so to be rendered by the respective display of the view:

Simplicity and perfection! I disabled the menu placement settings for the animal content type altogether since menu_views would take care of things now (and since I couldn't get users to not skip this step). Win!!

[klonos]

Previous comment was totally OT, but to answer your question @laryn they are related modules/features. I would place them in the list of #1839 😉

[klonos]

This was brought up during the theming-focused VUG meeting today.

We should look into initially getting the minimum support for it implemented in core, so that one can create menu-item-based mega-menus (which is the simplest form of mega-menus). Then we can iteratively improve, and add support for adding blocks on the mega-menu, and perhaps also provide a Layouts-like UI for them.

PS: in D7 land, the TB Mega Menu module provides a UI for managing mega-menus:

Here's a video that demos the module: https://www.youtube.com/watch?v=WnuhbFwsJ3M

[klonos]

Related work: #3755

[jenlampton]

I'm just going to throw it out there that I don't think mega-menus are a 80% use-case.

[klonos]

Sure. This could very well be a contrib candidate. It's just that I'd hate to have this have the same fate as in D7, where there were so many menu-related contrib modules and 3rd party JS libraries, that it was confusing for Drupal newcomers to know which one to go with. This is now such an easy problem to solve with drop-down menus in Backdrop core.

PS: UI-wise, I always thought that if we got the field groups UI right and got that into core, then it would be relatively easy to use a similar, table-drag UI for specifying mega-menu columns. It would not be as "fancy" as a Layout-style menu builder, but it would still get an MVP out there.

[jenlampton]

But if field-groups become mini-layouts....

[klonos]

...then mega-menus can also be managed mini-layout-style 😉

[klonos]

Just reporting on what I see becoming a trend in D8: https://www.drupal.org/project/menu_item_extras

I was reading up on these 2 articles/how-to's posted in the module description in d.org:

• Creating a Mega Menu using Layout Builder in Drupal 8
• Get a Fieldable Drupal Menu: Menu Item Extras Overview

Screenshots from the first article:

In the example above I have used the optional Menu Blocks module to add submenus of the Drupal Admin menu (Structure and Configuration) to the first two columns (default core menu blocks do not allow the parent to be selected, but the Menu Block contrib module adds that). In third column the Search Form block was added, and below that is an "Inline Block" using the core Basic Block type to add static text to the menu item.

[ghost]

I'm +1 for having this in contrib, not core.

[klonos]

Agreed. There has been very little interest in this since I originally posted this back in 2016. Lets leave for contrib. If we change our mind in the future, we can revisit this.