Menu Builder

[Mike Rockett]

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.

Wait, I'm not using the dev branch. Whoops... (unless it was patched in the one you get from the directory?)

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...

I guess I'm just a sucker for clean code. 

[kongondo]

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.?

Hmm, interesting thought. Technically, it is not impossible - just a recursive function that only grabs one branch...I'll have think...

[kongondo]

Wait, I'm not using the dev branch. Whoops... (unless it was patched in the one you get from the directory?)

I guess I'm just a sucker for clean code. 

I'm all for clean and valid HTML too...What I meant is that I forgot to put back a space when I went from this <ul to this <$wTag.....bundling a third-party PHP class just to deal with that seems like an overkill

[Mike Rockett]

I'm all for clean and valid HTML too...What I meant is that I forgot to put back a space when I went from this <ul to this <$wTag.....bundling a third-party PHP class just to deal with that seems like an overkill

Yeah, I figured that. Just mentioned it because of the general output. To me, it isn't overkill if it's to be used to enhance everything the module outputs. Much the same way I used ParseCSV in Jumplinks - I wanted the flexibility it provides, which enhances the experience.

[kongondo]

Wait, I'm not using the dev branch. Whoops... (unless it was patched in the one you get from the directory?)

Aaah, ye that's it. It works fine in dev branch. Please test and let me know? Thanks. I tested thoroughly with different combinations of multiple classes. I want to merge to master later today.

[Mike Rockett]

I downloaded this archive, and it's still sticking ul and class together, unless I use an id.

Using 

<?= $modules->MarkupMenuBuilder->render('main', array('menu_css_class' => 'navigation')); ?>

Result:

<ulclass ="navigation">
<li  ><a  href='/'>Home</a></li>
...
</ul>

Edit: Culprit seems to be line 185 of MarkupMenuBuilder on in the archive I grabbed.

$cssMenuClass = $options['menu_css_class'] ? 'class ="' . $options['menu_css_class'] . '"' : '';

[kongondo]

Thanks, will fix soon. As for the <li>, it works fine for me...are you seeing that extra space (as in your code above...)?

[Mike Rockett]

Thanks, will fix soon. As for the <li>, it works fine for me...are you seeing that extra space (as in your code above...)?

The code is as I pasted it.

(Except the ul thing, which I changed.)

[kongondo]

Thanks, fixed. Committing shortly...

[kongondo]

Update: version 0.0.5

• Fixed markup errors reported above in MarkupMenuBuilder
• Merged version to master (updated in modules directory as well)

Edited March 17, 2015 by kongondo

[dazzyweb]

Hmm, interesting thought. Technically, it is not impossible - just a recursive function that only grabs one branch...I'll have think...

Great. Would be cool to have this feature.

[tpr]

Very nice, a must-have. Thanks!

May I ask what admin theme was used on the screenshots? Looks pretty sharp but cannot find anywhere.

[kongondo]

@tpr,

Thanks.

They are all part of the admin themes that natively ship with PW. In the first couple of screenshots, that's AdminThemeReno, followed by AdminThemeDefault using the color set 'Futura' and last screen the color set 'Warm'.

[tpr]

Thanks, I got it now. It was the Reno theme, it has to be installed first to use. Have to do some PW development soon to get back to PW basics

[kongondo]

Update: version 0.0.6

In dev branch for now

1. As per this idea, thanks @dazzyweb, added a renderBreadcrumbs() method to render, uh..., breadcrumbs. See documentation in Read Me for how to use
2. For both render() and renderBreadcrumbs(), you can also pass a Page object as the first parameter. This is in addition to the already available ways, i.e. you can also pass a menu page's title, name or id or an array of menu items built from a menu page's menu_items field.

Please test and let me know, especially playing around with the options you can pass renderBreadcrumbs(). See Read Me, including comments in the code. These options can be shared between the above two methods. Same goes for the first parameters - e.g. get a menu page and pass that once to both render() and renderBreadcrumbs(). Also added the option to prepend 'Homepage' as topmost breadcrumb item even when it is not ancestrally part of the breadcrumb.

Note

If you call renderBreadcrumbs() in a page that is not part of the menu items you will get an error if logged in as superadmin but nothing returned for all other users. E.g., say you have the following menu items:

Home
About Us
Products
Services
Contact Us

renderBreadcrumbs() would only work (duh!) if called from the template file of AND viewing one of those pages. This is because the method works by first matching the 'pages_id' of a menu item with the $page->id (current page) and builds the breadcrumb from that.

External menu items can be part of the breadcrumb as long as they are not the current item (of course) - which they can never be anyway since clicking on them will load external URLs

[dazzyweb]

Thanks kongondo, seems to work fine but I have one or 2 queries or suggestions for a couple of issues I have.

There are times when it would be useful to display breadcrumbs for pages that are not in the main header menu created. Do you think there is a way around this with some kind of option?

So as a simple example if we have the following menu created with Menu builder:

HOME

ABOUT

-who are we?

-Our history

FAQ

CARS

CONTACT

ABOUT page would have children in the menu created and work fine with the renderBreadcrumbs method.

'CARS' would have 50 children in the page tree but I might not want to show these children as a sub menu so they would not be included in the menu created but I might still want to show breadcrumbs if going to the page 'Audi' or 'Jaguar' such as Home / Cars / Jaguar which could have been accessed from some different link or list.

Do you think it is possible to have some kind of option whereby the breadcrumbs or normal render method  recognises the children of the 'CARS' page in the normal pages tree without actually having them in the menu created by menu builder?

Another point connected with this is if I am at the page Jaguar (Home / cars / Jaguar) it would be useful with the normal menu render method to be able to still add a 'current' class to 'CARS' in the menu so it could still be highlighted as the parent page even though the page Jaguar is not in the menu created with menu builder. It would also be useful to be able to add a 'current' class to ABOUT page when viewing sub pages of the ABOUT page which are in the menu created by Menu builder.

[kongondo]

@dazzyweb,
 
OK, I might have found a way to achieve both of these. Although I think it is possible to include intermediate natural parents (i.e. PW parentage) that are also not in the breadcrumbs, I think I will stick to immediate parent only. Same goes for the 'current' class. What I mean is this....let's say your 'jaguar's had child pages as well, maybe 'model A', 'model B', etc., that are also NOT part of the MB menu, following your request, you would something like this: Home / cars / Jaguar / Model A. The problem I foresee is what if an intermediate parent was part of the MB menu but not in a 'natural' position? I we were to include it in the breadcrumbs, it could end up in the wrong position (from the breadcrumbs point of view). I hope this makes sense and maybe this is an edge case. Anyway, unless convinced otherwise, I am limiting this to the immediate parent, e.g. Home / cars / Jaguar /. Thoughts?
 
Edit:
 
No, scratch that. I'll make the depth to which one wants to display non MB items that are natural children of the current MB item configurable, e.g. 

append_child => 0//default - no child appended = Home / Cars
append_child => 1// append the immediate child = Home / Cars / Jaguar
append_child => 2// append immediate child and grandchild
etc...

Beyond that...how you structure your menus is up to you

Edited March 23, 2015 by kongondo
Changed mind...

[dazzyweb]

Another thought I have of doing this is the following though I am not sure if there are any complications making this.

What if each separate page added to the menu had an option added to it in the menu builder(where title, url, css options are etc..) such as 'include this pages natural children from page tree' with a second option with it with a yes/no to display children in normal render method? The breadcrumbs could then normally display all levels as the pages would be included in the built menu with the option of not displaying with the normal render method if not wanted there.

This could actually be useful in other ways as well if normally wanting to include natural children under a page without actually having to manually put them all there especially if there are many.

If this is set up in such a way whereby all natural children are included such as the way a selector works then I assume when adding another page as a child in the normal page tree that it would then be included as well automatically in the menu builder if set up such a way. This could be quite useful making the menu builder much more flexible.

[kongondo]

I think your 'another thought'  is a better approach since it allows for more granularity, i.e. it targets individual menu items rather than the first approach which targets the whole menu in terms of including natural child pages. I don't think there is a need for the second option 'yes/no' though unless am not getting it? By using the 'include natural children' option, you imply that you want them to be displayed. 

The way I think I'll do it:

'include_children' => 0//default = no
'include_children' => 1//yes, but only in menu, i.e. render()
'include_children' => 2//yes, but only in breadcrumbs, i.e. renderBreadcrumbs()
'include_children' => 3//yes, in both

//number of child nesting levels to show IF include_children > 0
//include_children_levels => 1//default, i.e. show only immediate children [or child in case of breadcrumbs]
//include_children_levels => 2//etc....show up to grandchildren/grandchild, etc..

The include_children can be tricky though....One might end-up with lots of sub-menus! But this is is optional, so up to the developer really.

Apart from some coding issues I may not have thought of yet, the visual MB aspect has to be considered. Those natural child pages will not be included in the saved menu items, hence will not be displayed in the menu tree in the back-end (ProcessMenuBuilder). They will only be included in the front-end output during runtime. That may confuse your editors, but nothing you can't educate them about, and this is optional anyway.

Edit:

Or...in the spirit of flexibility and granularity....in MB admin, also add an include_children_levels text (int) box next to an include_children checkbox. Then in the front-end, render() and renderBreadcrumbs() will be guided by:

if the setting include_children_levels is empty AND you have an $options = array ('include_children' => xx,  'include_children_levels' => zz), the level set in $options takes precedence and is applied overall except for menu items where the setting include_children_levels is NOT empty; an explicit level set at menu item level will override any $options setting. Would such a workflow work for you?

Edited March 23, 2015 by kongondo

[dazzyweb]

I don't think there is a need for the second option 'yes/no' though unless am not getting it? By using the 'include natural children' option, you imply that you want them to be displayed. 

Yes but sometimes not displayed in the main menu but only breadcrumbs.

The yes/no option was to give flexibility for the editors so that a choice could be made on whether to have the children displayed with the 'normal render method'(in main menu for example) or not for each page that has children. Since there can be times when I don't want them displayed on the main menu(only in breadcrumbs) and this option can be different for each page added in the menu builder. In the example I made before the car brands would not be shown in the main header menu but would be shown in breadcrumbs so option chosen would be set to 'NO'. The about page would have option set to 'YES'(which would be default) so the children of about page would be displayed in the main menu and breadcrumbs.

Choosing to 'include natural children' and 'YES' would include the children in both normal menu and breadcrumbs, choosing 'NO' would only include in breadcrumbs. Having this option with each page(menu item) enables each page added to the menu to have different options if they are displayed in main menu or not.

Maybe I am not understanding the 'include_children' option fully but wouldn't this then end up overriding all the options chosen for each individual page(menu item) by the admin for the normal render method(main menu)? This would then disable the ability to have one page on main menu displaying it's children and one page in the menu not displaying it's children.

Apart from some coding issues I may not have thought of yet, the visual MB aspect has to be considered. Those natural child pages will not be included in the saved menu items, hence will not be displayed in the menu tree in the back-end (ProcessMenuBuilder). They will only be included in the front-end output during runtime. That may confuse your editors, but nothing you can't educate them about, and this is optional anyway.

That's fine, I think that is the best way anyway since if there were many children it could make the menu builder quite crowded & unworkable. This way would actually make it much cleaner to use.

[kongondo]

Ah, I see (see also my edited posts above). Your yes/no is targeted at editors whereas my include_children with its options is targeted at developers. Giving editors the choice makes more sense and I'll adapt that instead. So, just to make sure we are on the same page:

1. Editors control inclusion of natural children (default is exclude - this setting is not saved)
2. Editors control whether natural children are shown in menu or breadcrumbs or both (This can a set of 3 radio buttons - any selection also implies include children; no selection implies don't include - or I could add a fourth button but it's already crowded in that menu setting as it is!! if one wants to edit the setting. No, better yet, I'll use a drop-down with 3 options - 'menu', 'breadcrumbs', 'both'. No selection = default and means 'don't include natural children')
3. Editors control this per menu item (i.e. per PW page)

What do you think about my levels question though? Sticking to immediate children is pretty straightforward. Do you see a need for grand-children? This is more relevant for breadcrumbs, e.g. if you wanted Home / Cars / Jaguar / Model X where both 'Jaguar' and 'Model X' were not part of a MB menu...

[dazzyweb]

Ah, I see (see also my edited posts above). Your yes/no is targeted at editors whereas my include_children with its options is targeted at developers. Giving editors the choice makes more sense and I'll adapt that instead. So, just to make sure we are on the same page:

1. Editors control inclusion of natural children (default is exclude - this setting is not saved)
2. Editors control whether natural children are shown in menu or breadcrumbs or both (This can a set of 3 radio buttons - any selection also implies include children; no selection implies don't include - or I could add a fourth button but it's already crowded in that menu setting as it is!! if one wants to edit the setting. No, better yet, I'll use a drop-down with 3 options - 'menu', 'breadcrumbs', 'both'. No selection = default and means 'don't include natural children')
3. Editors control this per menu item (i.e. per PW page)

Looks good

What do you think about my levels question though? Sticking to immediate children is pretty straightforward. Do you see a need for grand-children? This is more relevant for breadcrumbs, e.g. if you wanted Home / Cars / Jaguar / Model X where both 'Jaguar' and 'Model X' were not part of a MB menu...

Would be good to have levels and I can see a need for grand-children sometimes.

I think that levels could be useful as well for the main menu at certain times when using include_children so as to limit the amount of levels shown for example in a drop down menu. But then the levels needed to be shown in main menu could then differ to the amount needed for breadcrumbs so would maybe need different include_children_levels for main menu and breadcrumbs.

Or...in the spirit of flexibility and granularity....in MB admin, also add an include_children_levels text (int) box next to an include_children checkbox. Then in the front-end, render() and renderBreadcrumbs() will be guided by:

if the setting include_children_levels is empty AND you have an $options = array ('include_children' => xx,  'include_children_levels' => zz), the level set in $options takes precedence and is applied overall except for menu items where the setting include_children_levels is NOT empty; an explicit level set at menu item level will override any $options setting. Would such a workflow work for you?

So an options default would be set to all menu items in one swoop and then can be tweaked at admin level? It is an interesting thought. The more I think about it the more I see it could come in handy.

[kongondo]

Would be good to have levels and I can see a need for grand-children sometimes.

I think that levels could be useful as well for the main menu at certain times when using include_children so as to limit the amount of levels shown for example in a drop down menu. But then the levels needed to be shown in main menu could then differ to the amount needed for breadcrumbs so would maybe need different include_children_levels for main menu and breadcrumbs

OK, we should have these separate...I need to reiterate that MB will not control the number of such children to show at any level.....although I want to leave that to the developer (or editor?), I may need to limit maximum number of pages returned in that 'find'. I imagine a situation where an editor working on some other part of the site inadvertently adds tens of child pages (e.g. under CARs and under Jaguar, etc...)...Coupled with a levels of say 3, you suddenly end up with 3 x XX number of pages to find for one or more menu items! Can easily chock memory...Not sure how to implement this at the moment...maybe make it configurable at developer (template file) level...something like max_children at each level...

So an options default would be set to all menu items in one swoop and then can be tweaked at admin level? It is an interesting thought. The more I think about it the more I see it could come in handy.

Exactly...would save you a few clicks...

Edit:

Below is how I envisage the order of priority of $options (API/template file) setting vs. admin-level settings. There's 4 possible admin-level settings for each menu item in respect of whether to show its natural children. Show in: (1) Menu (2) Breadcrumbs (3) Both (4) Never. In addition there's the number of levels to show in respects of choices 1-3.

Desc order of priority for final display

1. $options = array('include_children' => 0)//overrides everything set at admin level. No natural children displayed anywhere
2. Any explicit admin-level setting: 1- 4//Natural children displayed/not displayed as per choices 1-4 FOR ONLY THIS menu item irrespective of what is set in $options (apart from a '0' setting as shown in point #1 above)
3. $options = array('include_children' => 1|2|3)//overrides ONLY EMPTY admin-level settings: Show natural children of all items without an admin-level setting ONLY in menu [1] (render()) OR breadcrumb (renderBreadcrumbs()) [2] OR both [3]
4. Empty admin-level setting: no natural children displayed anywhere

Edited March 23, 2015 by kongondo
order of priority description

[bbeer]

Is it possible to use this in a Multi Language Site.

Tried to use it, but in the menu title I get Array and in the outputs as well, it outputs Array, instead of the menu title. When changing language it buts.

Thanks in advance.

[kongondo]

@bbeer,

No, it's not multi-lingual in that sense. The reason you see an array is because the various titles (in the different languages you have installed) are held in an array. When saving, since I have not implemented ML support, PW does not know what to save. That is what I am assuming. I have never worked in a ML site before so this is new to me too. I am looking into it. I'll ask in the forums (Soma probably will pick it up ). So far my searches have come empty, i.e. how to save a field (in this case a page title) in a ML environment. Hopefully I'll find an answer here: https://processwire.com/api/multi-language-support/multi-language-fields/

Edited March 26, 2015 by kongondo