Multiple menus

[tsdtsdtsd]

Hi,

I still can't figure out how to create multiple navigations.

Let's say I have this structure:

Home
  About
  Products
  Contact *
  Legal *
  Other Stuff (Hidden)

Contact and Legal should be in a footer navigation, rest in default main navigation. "Other stuff" is hidden already.

Decision by template is not an option because the real structure has a lot more pages/templates and I think it's inefficient to manually ad new templates to the menu modules/templates each time. Also I have pages with the same template but which should show in different menus.

Next option is to add a field in every template to identify if this page should be rendered in top or footer navigation. Would work, but I don't like it

How do you guys beat this challange?

[Soma]

Next option is to add a field in every template to identify if this page should be rendered in top or footer navigation. Would work, but I don't like it

Why not? Actually pretty fine solution to add it in page to be able to say where it should go.

There's actually some different ways you could archive something like this.

- add a field for selecting what navigation the page should go.

- add a structure to define navigation. Special type of pages where you can select what page should have link in footer navigation.

- same but only one page with page reference field

- add the 2-3 links manually to the footer nav code. And make them hidden in admin.

- by a special template for footer pages.

[Pete]

The other option is to do a normal menu and if it's ONLY those two pages you don't want to appear then exclude them using the API selectors.

[tsdtsdtsd]

There's actually some different ways you could archive something like this.

- add a field for selecting what navigation the page should go.

- add a structure to define navigation. Special type of pages where you can select what page should have link in footer navigation.

- same but only one page with page reference field

- add the 2-3 links manually to the footer nav code. And make them hidden in admin.

- by a special template for footer pages.

Plenty of options. Thank you, I think I can work with that.

[Soma]

tsd, if you need more help just ask here. I'm sure we can find a solution that suits your needs. But first try out and think what would be best for you. Let us know what you come up with using.

[tsdtsdtsd]

I can't really describe why I don't like the extra field to choose if this page is a main or footer navigation page.

I think I will go with a extra structure for the menus. It's more flexible when you need to add new stuff or edit. I'll try it out tonight.

You're very helpful, thank you!

[nikola]

tsd, you can do something like this for header navigation (if you add extra pages to header navigation, they will show normally):

<?php
       
   echo "<ul>";
       
   $headerNav = $pages->get('/');
       
   foreach($headerNav->children as $menu) {
   $class = $menu === $page->rootParent ? " class='active'" : '';

   if ($menu->name != 'contact' && $menu->name != 'legal') {
       echo "<li><a$class href='{$menu->url}'>{$menu->title}</a>";	
      }
   }

    echo "</ul>";

As far for footer navigation you can do something like this:

<?php
       
   echo "<ul>";
       
   $footerNav = $pages->get('/');
       
   foreach($footerNav->children as $menu) {
   $class = $menu === $page->rootParent ? " class='active'" : '';
   
   if ($menu->name == 'contact' || $menu->name == 'legal') {
       echo "<li><a$class href='{$menu->url}'>{$menu->title}</a>";	
       }
   }

    echo "</ul>";
       

Hope it helps...

[ryan]

Another way you can go is to use page reference fields. Add two new 'Page' reference fields: topnav and footnav. Make them support multiple pages. Don't restrict it to a parent or template. Select 'PageListSelectMultiple' as the Inputfield for them. Save, and add them to your Homepage template.

Now edit your homepage. For the 'topnav' field, select all the pages you want as part of your top navigation, and for the 'footnav' field select all the pages that should appear in your footer navigation. Drag to sort them in the order you want.

Edit your main markup file (or head/foot includes) and use the following code to output that navigation:

<?php
foreach($pages->get("/")->topnav as $item) {
   echo "<li><a href='{$item->url}'>{$item->title}</a></li>";
}

…repeat the same for the footer nav, except iterate the footnav (rather than topnav) field.

In the sites that I develop, I almost always have the footer nav hard coded in the main markup file (I don't usually need it to be dynamic). For when I need the topnav dynamic, I'm usually sticking to the site's root level structure for the navigation (iterating the non-hidden children of the homepage). You may need all this stuff to be dynamic, in which case there are a lot of options. But I just wanted to mention that you should only make stuff dynamic that needs to be. When stuff can be hard coded in a template file, it consumes fewer resources. So if you stick to a policy of hard coding stuff that changes rarely and doesn't need to be dynamic, then you'll benefit from better performance, use less energy, save more trees, etc.

[thetuningspoon]

It seems like you should be able to accomplish this by restructuring your pages into something like this:

Home

Top Navigation

Page 1

Page 2

Page 3

Bottom Navigation

Page 4

Page 5

Page 6

404

Admin

Trash

And then looping through the children of each. I guess the problem with this is that you'd end up with ugly URLs like www.yoursite.com/top-navigation/page-1

Is there any way around that?

[Pete]

Is there any way around that?

The simplest method has been mentioned - having an extra field for the template to choose whether or not it appears in the header or footer menu.

Personally, my take on that would be to assume that all pages will appear in the header menu and have the extra field simply be a checkbox labelled "show in footer menu".

That way you can easily output a header menu excluding pages with that checkbox selected, and output a footer menu for those pages with the checkbox selected.

This is of course just variations on what others have said further up the page, but with field widths being adjustable now, you could even do something like make the page title field be 80% wide, have the checkbox 20% wide and then when editing pages the checkbox will appear neatly at the top-right of the edit screen and not take up a lot of space at all (which I'm guessing is the original poster's main issue with it?)

[thetuningspoon]

When I said "Is there any way around that" I was specifically referring to avoiding having the parent name added to the URL structure. Your solution is a good one as well, but it seems like it would be simpler, easier to visualize, and more scalable to just be able to divide up your menu structure. Then you could easily implement as many menus as you want.

[Pete]

Hmm... I'm not sure there is a way around that to be honest. I originally thought of URL segments, but they only apply to things after the end of a URL.

I think the only way to do that would be some sort of custom module to override the way PW handles URLs, but that would be far more trouble than it's worth I suspect given the number of much easier alternatives available.

[Soma]

Your content structure shouldn't be trying to completely reflect the menu structure how you want to appear on page through hierarchy. You're mixing things up. Just looking at your structure something feels wrong. The most elegant way, is to have a setting on page or various other options.

You could have a menu structure and a content structure. Then have a page ref field to select the page you want to render for a menu entry. Then use $page->render() to render the referenced page. And the url will be the one from the menu. Not sure how this would affect the handling on the menu heighlights. But I think there's ways to get it working. But at the end there would be some sort of base "dir" that you don't want to have in the address, so you're at the same point again. Although some clever custom handling of the urls outputted would maybe make it possible.

While this can be a desired situation to divide the structure but not have the structure reflect in the address, it would require URI routing. This could be done through htaccess, although this would require adapting the navigation urls you output from PW, think of headaches. Another way would be to have PW allow for configuring URI routes like in CI for example http://codeigniter.c...l/routing.html. Not sure how this all would work internally well regarding urls and the page finder functions etc. Though I also would like to hear from Ryan what he thinks about this subject, and if he sees anything possible like URI routing in the future in PW, as this subject popped up already in an other thread at least once.

[diogo]

And then looping through the children of each. I guess the problem with this is that you'd end up with ugly URLs like www.yoursite.com/top-navigation/page-1

Is there any way around that?

I agree with the others that this is not the right approach. But still, this can be answered, and there is a way around:

The name of the page on the tree is defined by the title, while the url segment is defined by the name. So, this would be as easy as having different name and title.

[thetuningspoon]

Your content structure shouldn't be trying to completely reflect the menu structure how you want to appear on page through hierarchy.

Hmm... what should it reflect then? I thought that was the whole idea of keeping the menu structure and content together, as opposed to CMSs like Joomla and Drupal which require you to link your content with a separate menu item either during its creation or after.

Edit: If you do go the checkbox input field route, is it possible to give the checkbox a default value? For example, have a Main Menu checkbox that is checked by default and a Footer Menu checkbox which is unchecked by default? Ideally, I'd rather my clients not have to go through an extra step to get their content to appear.

[diogo]

Hmm... what should it reflect then?

I would say that you can compare it with the separation of semantic markup and css, the tree structure should reflect the content logic and not the navigation. imagine that one day you want to change the way the content is presented on the webpage... that all the navigation would be rethinked... with this structure, you would have to keep the tree reflecting something that doesn't corresponds to the real situation.

Best, would be to organize the tree by content logic, and make the navigation work as you want on templates.

[thetuningspoon]

I would say that you can compare it with the separation of semantic markup and css, the tree structure should reflect the content logic and not the navigation. imagine that one day you want to change the way the content is presented on the webpage... that all the navigation would be rethinked... with this structure, you would have to keep the tree reflecting something that doesn't corresponds to the real situation.

Best, would be to organize the tree by content logic, and make the navigation work as you want on templates.

Personally, I think that a well constructed content structure should make for a good navigational structure and vice versa. Separating them results in bizarre situations like you have in Joomla where articles can be categorized but it has no practical effect on how the site handles the content on the front end. This, in my experience, results in a difficult mental model that frustrates clients to no end. So It seems to me that PW has been developed to eliminate that sort of confusion. When you output your navigation onto the page, you basically spit out the content structure, with maybe some minor adjustments or repetitions here and there, but you're not picking and choosing pages one-by-one and forming a completely different navigational structure. I see this as a strength of PW. And PW makes it very easy to reorganize your content structure, so I don't see that as a concern.

I would be really interested to hear Ryan's take on this.

Edit: I do understand what you guys are saying--that the separation of navigational elements doesn't necessarily correlate with a difference in the underlying content structure. That being said, if your navigation is well thought out, the links in these navigation sections should have something in common with each other that makes them fit to be together. In other words, something about their content should dictate their placement and grouping. So while my previous example fails in that I use a physical page location as my parent item, I could just as easily group these items like so:

Home

Cars

Page 1

Page 2

Page 3

Boats

Page 1

Page 2

Page 3

404

Trash

And have the children of Cars show up in my main nav with the children of Boats in the footer. In this case, having /cars/ or /boats/ in my URL structure would not be so bad, because it is describing the content.

[diogo]

If your content structure is well thought, you will automatically have a logical structure for the frontend as well as for the backend. What I'm saying is that you don't really have to think about it as "navigation1" and "navigation2", but as "products" and "articles" instead.

[thetuningspoon]

If your content structure is well thought, you will automatically have a logical structure for the frontend as well as for the backend. What I'm saying is that you don't really have to think about it as "navigation1" and "navigation2", but as "products" and "articles" instead.

Exactly. Gotcha.

[Soma]

Diogo already said it better than I could ...

What would gives you the reason to put a place of a content into a container called "/footer-navigation/"? Will those be special pages completely separate from the "main" navigation? So what if you find a more meaningful name that would put meaning to the content placed inside? mb /services/ ? ... In 99% of the projects I've worked on the so called footer, meta or service navigation are just a few "hard" coded into the template links that won't change a lot anyway. Also not areas where one would often add pages.

It's true that the content structure reflects the navigation 1:1 that what makes it easy to recognize as it represents the websites structure. Not layout related informations. Your approach is solely coming from the desire to give a visual structure to the editors to work with. That's what I meant by mixing up.

SO thinking about it a little more, I think some sort of visual named "separator" that can be but in between the pages inside the hierarchy might be a better solutions to this.

It's just the way PW works with it's hierarchical approach, and not every case and desire others might have, has been put into thought by Ryan or others. It's pretty much he's effort alone all of what you see in PW atm and done for he's needs and clients. It's still evolving and I think there will be some sort of solutions coming up. Just have to either wait or get active and try to get things discussed/done.

[diogo]

And have the children of Cars show up in my main nav with the children of Boats in the footer. In this case, having /cars/ or /boats/ in my URL structure would not be so bad, because it is describing the content.

Bingo

[thetuningspoon]

Well, the main goal of my suggestion to divide up the tree was to make it easier for both the developer and the client to achieve the desired output, not just the for the visual effect on the back end.

I see either of these approaches (using categorization or adding checkbox fields in the templates / hard coding) as being viable solutions, depending on the circumstance and the type of website being built. So I really don't have an issue with it, and I don't think Ryan should necessarily change it, unless there's a good practical reason which fits with the logical structure of the rest of the application.

I didn't realize that the main issue you guys had with my suggestion was with the names I used and not so much with the concept I go into more detail on that in my previous edit above.

I'm still wondering about this, though:

If you do go the checkbox input field route, is it possible to give the checkbox a default value? For example, have a Main Menu checkbox that is checked by default and a Footer Menu checkbox which is unchecked by default? Ideally, I'd rather my clients not have to go through an extra step to get their content to appear.

[ryan]

If you do go the checkbox input field route, is it possible to give the checkbox a default value? For example, have a Main Menu checkbox that is checked by default and a Footer Menu checkbox which is unchecked by default? Ideally, I'd rather my clients not have to go through an extra step to get their content to appear.

Default values are something we'll likely have at some point, but I'm a little conflicted about it. I like the idea that when you create a new page and assign no values to it, it doesn't place any values in the database. There's a clear distinction between set and not set. There's a nice simplicity to that. So I translate that to the way I name and use fields. If I have a checkbox that I want to enable some behavior, I'll name it toggle_behavior and if I have a checkbox that I want to disable some behavior, I'll call it toggle_no_behavior or toggle_disable_behavior. You end up with a smaller and faster database if you are naming and using fields in a manner that veers towards the empty state being the more common one, and assigning any defaults at runtime rather than storing more duplicate 'default' values in the database. But I also recognize that these benefits are more technical than functional, which is why I say we'll likely have them at some point.

[thetuningspoon]

Yeah, I realize that if I want the main menu display to be the default, I could just change the label to "Don't display in main menu" and change the code in the template to correspond. But if I have a list of a bunch of different menus and some of them are stated as "dont's" and some as "do's," that could start to get confusing for the editor.

Fair enough, though. I didn't think of it from the technical side. For now, that will do fine.

[ptjedi]

Why not? Actually pretty fine solution to add it in page to be able to say where it should go.

Exactly. I just implemented a solution like that using checkboxes as global fields.

It would be nice to have multiple-select fields to minimize creating a checkbox per menubar.