I'd like to pose a couple of use cases that don't really fit well with having "main" as the only menu that can be used for an off-canvas block:

1) We have one site that has a very basic, plain, non-megamenu on the home page. Then there are two landing pages focused on different audiences (one for "employers," one for "job seekers"). The site's "main" menu is used site wide for sidebar navigation, and then the "employer" and "job seeker" menus are used go create megamenu blocks that appear only on the two landing pages. We'd like for those blocks to have the off-canvas functionality for mobile users. There will only ever be one ultimenu block on a given page, but it's a different menu on each page.

2) We have an older site that was built with an older megamenu module. The "main" menu was, again, used for sidebar navigation, and has a different structure than we want on the megamenu. A separate "megamenu_main" menu was created for the megamenu navigation. Now that we want to switch the site over to Ultimenu, we can't really do so without moving all the current navigation from the main menu to a new "sidebar_main" menu, and then rebuilding the megamenu navigation on the "main" menu.

How difficult would it be, do you think, to allow for specifying alternate menu names for the off-canvas menu? The administrator would need to be aware that they can use only one of them on any given page. Any block created with one of the allowed menus would offer the "off-canvas element" and "on-canvas element" configuration options.

Does that sound at all practical? Or desirable?

Comments

wrd-oaitsd created an issue. See original summary.

gausarts’s picture

gausarts commented

Good idea, thanks.

> How difficult would it be?
IMHO, easy :) See below.

> The administrator would need to be aware that they can use only one of them on any given page.
Yes, complication should be informed.
Is it one for any given "page" or "site"?
This will determine the scope to provide the option for menu selection, whether at Block UI (Make this block offcanvas), or Ultimenu UI (Select the menu for offcanvas) respectively.

Once decided, perhaps, like this:

  • Add the option above with fallback "main" menu as needed.
  • Anywhere, replace if menu == main with: if the selected menu xor this block is offcanvas, provide CSS class or data attribute containing "main", like the current. Aside from the selected menu specifics.

To minimize works, and disruptions:
Currently keyword "main" is consumed by CSS and JS, it should be preserved regardless the selected menu name. So we rely on PHP, not client thingies, to supply the consistent "main".
Might need a recheck if anything else.

Let me know your thoughts.

wrd-oaitsd’s picture

wrd-oaitsd commented

Block UI, I think. In our case, we would have two Ultimenu blocks in the main navigation region, one of them with page-based display restrictions of:

/employers
/employers/*

...and the other with display restrictions of:

/job-seekers
/job-seekers/*

Is it a complication if the site is actually using the default "main" menu, as a normal system menu block, located in another region? It's looking to me like the "main" keyword is never used without a "ultimenu-" prepended to it, so I'm guessing this won't be an issue.

gausarts’s picture

gausarts commented

> Block UI
Ok, multiple mega main menus, then. Ultimenu does support multiple megamenus. Technically should not be an issue. Perhaps details are like this:

  • Add proper checks to make the new option as the new priority over the hard-coded main menu,
  • Then fallback to old behavior with regular main menu if nothing passed from the current ultimenu block for BC.
  • To make it easy, we should store the option (Make this as Ultimenu offcanvas) and the Block entity menu name from Block UI into global variables/ config entity when the block is saved. So that codes anywhere can call this, and compared to the current displayed Ultimenu name at hook pre_render, etc. Here is the sample for saving the menu entity reference:
    https://git.drupalcode.org/project/ultimenu/-/blob/8.x-2.x/src/Plugin/Bl...

> Is it a complication if the site is actually using the default "main" menu, as a normal system menu block, located in another region?
As long the above correct check is provided (if offcanvas menu is BLAH (taken from config entity above) or equal to this menu when at pre_render code block), no problem. Problem is when those multiple non-main Ultimenu blocks co-exist on the same page. Not sure if LIFO helps, the last selected menu wins. Also we should store them as array to allow proper checks once. Each Ultimenu block chosen as offcanvas display is merged into existing variables.

Ultimernu offcanvas main menu can co-exist with normal system main menu, no problem. They are different derivatives of the same main menu.

> It's looking to me like the "main" keyword is never used without a "ultimenu-" prepended to it, so I'm guessing this won't be an issue.
You are right, the above was just quasi. A combo of 'main' and 'ultimenu-main', I think:
https://git.drupalcode.org/project/ultimenu/-/blob/8.x-2.7/src/UltimenuM...
https://git.drupalcode.org/project/ultimenu/-/blob/8.x-2.7/src/UltimenuM...

wrd-oaitsd’s picture

wrd-oaitsd commented

OK -- I probably won't get a chance to try to do anything with this until next week, but when I get some free time I'll see if I can get some of this done. Thanks!

gausarts’s picture

gausarts commented
Status: Active » Postponed

Got it, thanks.

gausarts’s picture

gausarts commented
Status: Postponed » Fixed

2.x was retired.
3.x was out with some mobile fixes.

The OP feature request was in 3.x, but not 2.x.

Feel free to re-open if still an issue. Be sure to mark it 3.x.

Thank you.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.