Menu Builder

[kongondo]

Thanks guys,

I want to put a class on the menu submenu so on nested unordered list. Is there an option for this?

 

For example <ul class="submenu">

Will look into it. Should be easy enough using $options. 

It would be nice to have compatibility for the <nav> tag - I use them in my menus instead of unordered lists.

On my to do list: See $options.

Also, I should be able to add a class and/or an ID to each menu.

You can already do this:

$options = array('menu_css_id' => 'main', 'menu_css_class' => 'navigation');
$menu = $modules->get('MarkupMenuBuilder')->render(1234, $options);

Am I missing something?

Will update docs later...

Btw, one is not tied to using MarkupMenuBuilder -> you can easily json_decode($menuItemsJSON, true) the menu items JSON and recursively traverse the resultant array using a custom PHP function or even with javascript.

Edited March 6, 2015 by kongondo

[dazzyweb]

Not a massive problem but I noticed that if I change the menu name that it doesn't render with the new name.

[kongondo]

In my testing, outputting the menu is already fast enough. However, one other thing I need to experiment with is caching the menu templates or menu_items field and see if it can be even faster...

[Martijn Geerts]

You're using tabs in your code, for constancy using spaces is better.

Thanks for creating this kongondo.

[kongondo]

Not a massive problem but I noticed that if I change the menu name that it doesn't render with the new name.

That's because at the moment, when you change the menu 'Title', only the title gets changed and not the name (i.e. on the PW page). In rendering using a title or name, it looks for the name. In that case, your new title would be first converted to a name and the module would look for a menu page with that name, which would obviously not exist (since name was not changed). Rendering by ID would still work though. But, I see no reason why I should not change this behaviour. I will make it change the name to match the title as well to be foolproof. Since menu pages are not visible in the frontend and are not really for querying, there is no harm in that. Thanks for the suggestion.

ps: If possible, could you file feature requests at the project page in Github? I won't have time to work on this today and might forget some things, thanks.

[dazzyweb]

Thanks for the great module kongondo. Just brilliant.

[Mike Rockett]

You can already do this:

$options = array('menu_css_id' => 'main', 'menu_css_class' => 'navigation');
$menu = $modules->get('MarkupMenuBuilder')->render(1234, $options);

Ah, right - missed that one. Don't think anything else is missing. I can already use this for a number of sites as it is.

[kongondo]

1. It would be nice to have compatibility for the <nav> tag - I use them in my menus instead of unordered lists.

@Mike,

Could you clarify the sort of HTML structure you envisage? With <nav> only, how do you show sub-menus? i.e.

<nav>
   <a href="link-1">Link One</a>
   <a href="link-2">Link Two</a>
   <a href="link-3">Link Three</a>
   <a href="link-4">Link Four</a>
</nav>

[Mike Rockett]

I generally follow something like this - an example from a recent site release:

<nav role="mainMenu">
	<li><a data-current href="/">Home</a></li>
	<li class="hasDrop"><a href="/who-we-are">Who We Are</a>
		<ul class="theDrop">
			<li><a href="/who-we-are">Overview & Mission</a></li>
			<li><a href="/who-we-are/certification">Our Certification</a></li>
			<li><a href="/who-we-are/management-board-staff">Management Board & Staff</a></li>
		</ul>
	</li>
	<li><a href="/what-we-do">What We Do</a></li>
	<li><a href="/connect">Connect</a></li>
	<li><a class="donate" href="/donate">Donate to our Cause</a></li>
</nav>

Essentially, I'm swapping out <ul> for <nav>.

But now that you mention it, I do see that not everyone does it that way. Some prefer to wrap their <ul> inside <nav>. Some people prefer to do it like your example. Thing with <nav> is that there is no predefined way of doing it...

Now that I'm actually looking at this, I should probably be using <ul> inside <nav>... I dunno. HTML5 went and confused things...

[Martijn Geerts]

Officially it isn't allowed to use <nav> as list-item container. Only <ul>, <ol> or <menu> element as parents are allowed for li elements. The last one <menu> I've never seen used in the wild before. The <nav> element I find rather confusing to. I use the nav element mainly as a wrapper element for navigation elements or leave them out if I do not need them for styling. So mainly I use it for wrapping main navigation elements and that is search form input(s) included.

[kongondo]

What Martijn said...

You can wrap you whole menu with <nav> like this:

$options = array('menu_css_id' => 'main', 'menu_css_class' => 'navigation');
$menu = $modules->get('MarkupMenuBuilder');

$out = '<nav>' . $menu->render(1234, $options) . '</nav>';

In that case, the menu will use the specified list type, <ul> default or <ol>

However, if in $options you specify: 'wrapper_list_type' => 'nav', then, in order to output correct markup, MB will not wrap menu items in <li> but only <a> unless you also specified in $options some other tag other than <li>, e.g.  'list_type' => 'span'. 

What do you guys think?

[Mike Rockett]

Officially it isn't allowed to use <nav> as list-item container. Only <ul>, <ol> or <menu> element as parents are allowed for li elements. The last one <menu> I've never seen used in the wild before. The <nav> element I find rather confusing to. I use the nav element mainly as a wrapper element for navigation elements or leave them out if I do not need them for styling. So mainly I use it for wrapping main navigation elements and that is search form input(s) included.

I see. I know that <menu> is really for context menus... to be filled with <menuitem>s.

I've never really been one for standards. To me, my method is easier to understand. Maybe not for everyone else. I tend to believe that if it works well, use it. One of the reasons I use <nav> instead of <ul> is that I don't need to remove the left margin. Granted, that's a small thing, but it just feels better do do it that way. Also, that example depends on what CSS framework/reset is being used.

I think that a little flexibility would be cool. Otherwise, I'll use the method suggested. (Won't hurt much at all  )

[dazzyweb]

I see. I know that <menu> is really for context menus... to be filled with <menuitem>s.

I've never really been one for standards. To me, my method is easier to understand. Maybe not for everyone else. I tend to believe that if it works well, use it. One of the reasons I use <nav> instead of <ul> is that I don't need to remove the left margin. Granted, that's a small thing, but it just feels better do do it that way. Also, that example depends on what CSS framework/reset is being used.

I think that a little flexibility would be cool. Otherwise, I'll use the method suggested. (Won't hurt much at all  )

I like it. I never used it this way but actually makes sense in one way but in another way it kind of confuses things when using nested lists with ul.

Maybe if there was something like a <subnav> element it would  make more sense.

[Mike Rockett]

I like it. I never used it this way but actually makes sense in one way but in another way it kind of confuses things when using nested lists with ul.

Maybe if there was something like a <subnav> element it would  make more sense.

If I had a say in the matter, I'd probably go for <item> (for plain ol' items) and <subnav> (for sub-menus).

[kongondo]

Update: version 0.0.3

Updated original post.

Now in modules directory:

• Option to allow Markup in menu items as per this request (superusers only) [note: although values are sanitized via HTML Purifier, it is your responsibility to ensure correct HTML input; also, if you previously allowed HTML markup but the menu was subsequently edited by non-superusers, your HTML will be stripped off]
• Added more options to MarkupMenuBuilder render() method - first, last classes, etc.(see Read Me) and...
• Added/enhanced wrapper_list_type and list_type options. The former allows you to specify menu items outer wrapper tag, e.g. <ol>, <div>, <nav>, etc....The latter allows you to specify alternatives to <li>, e.g. <span>. Note, if no list_type is specified and you override the default by 'list_type' => '' in your options, then menu items css classes/IDs are applied to the <a> tag instead.
• Updated code to ensure menu settings saved by superusers remain even for non-superusers (e.g. menu maxLevels, selectable pages, etc.)

Note: Had an extra  jquery.asmselect-mb.js in the root folder. I have deleted this in the repository.

Note, it seems PageAutocomplete will not allow non-superusers to select pages unless they have a page-edit permission as well. Could somebody confirm/clarify? Thanks.

Edited March 9, 2015 by kongondo

[dazzyweb]

Note, it seems PageAutocomplete will not allow non-superusers to select pages unless they have a page-edit permission as well. Could somebody confirm/clarify? Thanks.

Yes I see that as well. Not sure if this is related to some other permission but 'selector' doesn't appear as well even with page-edit permission.

The rest works great.

[kongondo]

Selector not appearing is by design (seems I added that to the ReaMe only and not the OP). Currently, it is only visible to superusers although was wondering whether to make that permission-based as well...could be user created permission that would be stored together with the menu's settings...

Edited March 11, 2015 by kongondo

[dazzyweb]

Selector not appearing is by design (seems I added that to the ReaMe only and not the OP). Currently, it is only visible to superusers although was wondering whether to make that permission-based as well...could be user created permission that would be stored together with the menu's settings...

Always good to have the option.

[MuchDev]

I just have to chime in with nothing helpful other than to say how thrilled I am to see this. This is going to be such a fantastic tool for content creators. 

[kongondo]

Always good to have the option.

OK...on my TODO. I have expanded it to other features, not just the selectors. See this also. What are your thoughts about controlling ability to delete menus too? Any other controls I am missing? Thanks.

[dazzyweb]

OK...on my TODO. I have expanded it to other features, not just the selectors. See this also. What are your thoughts about controlling ability to delete menus too? Any other controls I am missing? Thanks.

That would be useful as well. I can't think of anything else at the moment.

[kongondo]

Update: version 0.0.4

Added 7 permissions to control visibility/access to advanced settings by non-superusers as discussed above. Currently this is only available for testing in Menu Builder dev branch.

Note that you have to create the permissions yourself and add them to a role. Please thoroughly read the updated README about how to use these permissions; depending on your situation, you may not have to create any of the permissions.

In summary, these control:

1. Locking/unlocking menus (menu-builder-lock)
2. Trashing and deleting menus (menu-builder-delete)
3. Use of selectors to add pages as menu items (menu-builder-selector)
4. Use of markup/HTML in menu item titles/labels (menu-builder-markup)
5. Specifying of PW pages that are selectable as menu items in the page fields AsmSelect and PageAutocomplete (menu-builder-selectable)
6. Editing of nestedSortable settings, e.g. maxLevels (menu-builder-settings)
7. Ability to change the page field (AsmSelect vs PageAutocomplete) to be used when selecting PW pages to add as menu items (menu-builder-page-field)

Please test and let me know, thanks.

[dazzyweb]

Just a thought and I am not sure how much this is needed but I am thinking about rendering breadcrumbs and wondering what would be the best way to render breadcrumbs based on the menu structure. Maybe I didn't think about it enough but there seems to be a possibility of complications rendering breadcrumbs when the menu structure is different to page structure.

Is there some way to have a feature whereby breadcrumbs could be output based on the menu structure with of course homepage being one step higher in the hierarchy of pages that are on the same level.?

[Mike Rockett]

I'm busy moving a site over to PW, and using MenuBuilder for the main nav. Unfortunately, I'm getting this markup:

<ulclass ="navigation">
<li  class=" current"><a  href='/'>Welcome</a></li>
...
</ul>

Which is broken... Would it not be better to use some kind of HTML builder? Perhaps something like this?

[kongondo]

I'm busy moving a site over to PW, and using MenuBuilder for the main nav. Unfortunately, I'm getting this markup:

<ulclass ="navigation">
<li  class=" current"><a  href='/'>Welcome</a></li>
...
</ul>

Which is broken... Would it not be better to use some kind of HTML builder? Perhaps something like this?gh

We'll that's strange...I thought I had dealt with this.....Old code must have crept in. I'll look into it, thanks for reporting. No need for the HTML builder ....for the <ul, it's just a missing space I forgot to put back after switching to configurable menu wrapper and for the <li> just a space to trim...I'll update tonight...

Edited March 17, 2015 by kongondo