How do you all handle navigations for your program pages? Presuming each program has a unique navigation, how do you manage that in the backend?
Do you have a different group for each program, each with its own main nav that your template uses?
Do you create individual navs in a single group (like Academics or similar)? If so, how do you associate the proper nav with the proper pages?
We currently have all programs and their sub-pages in a single, really big nav, and each program page is set to “start a new section”. But we have hit the limit set by a PHP config. We cannot add any more items to the nav (and are currently missing some programs that should be in there). So I am trying to figure out what alternatives I have.
I don’t really want to create a distinct group for each program if I can help it. But I don’t see any other way to break the huge nav into smaller chunks and be able to programmatically include the proper navs on the proper pages.
I have reached out to support about this. I’m just curious how other schools handle this. For example, Beloit seems be structured similar to our site. @mischlern, how does Anthropology (as an example) have its own nav? Is it in its own group?
The Beloit College site was set up to be very distributed, with the assumption that the various campus offices would regularly make page edits, add story/event content, etc. Thus, in most cases, each “minisite” is defined as a group.
Editor permissions are defined per group, with a few instances of extending page edit access to other directories per individual.
We also have some instances of using the “new section” option, in cases where there is a large office with distinct parts, significant overlaps in content like staff profiles, etc. For example:
Library & Information Technology Services - /lits/(Where’s the /offices/…?)
I believe there is an interest in leadership to try and achieve a more centralized approach, at least for the core marketing pages (Academics, Admissions, Student Life, etc), where a single large group managed by a central office would make sense. That said, I’m assuming we’d still want the individual groups for offices to add and promote their content, but perhaps given less emphasis (i.e. marketing on “www”, campus sites on “campus” subdomain). Ideas too big for me to have sit down and worked out in full, just yet.
In general though, even without a need to use groups for permissions, it’s not too difficult of a framework to work in (assuming group switching works as intended). I can imagine a transition to it could be somewhat painful, say if tags were being used to show stories in specific programs rather than group sharing…
Does that help? Any specific questions or concerns?
Thanks for that info. That is more or less how we organize things, too. We have tons of groups for all offices and departments on campus. We just don’t have groups for individual academic programs/majors/etc. Sure, we could create them, but with over 100 programs, it would be a fair amount of work. I’m starting to think I may have no choice, though.
Would it help to split undergrad/grad programs into two separate navs? That would keep them farther from the ~500 link length restriction we’re running into with the Navigation editor, and then the template might just need updating with say, a little XPHP logic to select whether it shows the Undergrad vs Grad parent nav? Maybe there’s something I’m missing there but it seems like there should be a solution in between “one big nav” and “100 separate navs.” Let us know. Thanks!
@karl, that would certainly help, but I can’t think of a way to use XPHP to select the proper nav. There is nothing in the page names or URLs that could be used to programmatically determine whether they are Underdrad or Grad.
Ah. “Programs” is vague for me at least, potentially meaning “departments”, “major/minor offerings”, or “dual-degree and other academic support”.
Looks like I’m fated to create something like what you have, though I appear to have at most 120 items at the moment. Good to know that the system can manage up to 500.
Allow me to echo Karl’s idea, which I think may be a good one: is there a way to break the list into 2-4 meaningful segments?
@mischlern the nav editor is limited to 555 nav items because each item in the nav has 9 hidden inputs. 555 x 9 = 4995, which is just under the 5000 max_input_vars PHP setting. We have 105 programs, but each one has multiple pages associated with it, all of which are in the nav. So you could hit that limit sooner than you think.
I would love to break the nav into three sections - Undergrad, Grad, and Certificates - but as I said above, I don’t know how to automatically place the correct nav on the correct pages once I do that. I hope there is an easy solution that I am just not thinking of at the moment.
Ah, that is a good distinction to know. My initial plan for offering pages would be a single page for each, but I’ll keep that in mind in case things develop otherwise…
For your case, I’ve been assuming the task would be to break up one complex group navigation and distribute them across 2-4 groups. For instance, if adding a “Undergraduate” group with root “/academics/programs/undergraduate/”:
Likely: Home / Academics / Academic Programs / Undergraduate / Chemistry / Chemistry 4-Year Plan
From there, you could use the GID or group name to change how things are presented across the various pages. For instance: defining what the base breadcrumbs are, or where “Apply” links go, etc.
I doubt I’m understanding your implementation well at all, but to share another thought in passing: if the new group root locations do not have their own content/page to display, the user could potentially lead back to the Programs page, pre-filtered for the division attempted. For instance:
Then we could have an undergrad programs group, and a grad programs group. But that’s not the way we built it, and I doubt anyone here would want to change that.
So we’re stuck working with the structure we already have and trying to find a way to make it work.
The best solution I can come up with is to add a custom field to the pages editor in that group to select what type of program the page belongs to. Then the template could use that field’s value to select the proper nav.
I’m not sure that’s any better than just creating groups for each academic program though. Both would require significant work upfront, so I want to be sure I choose the best option before committing to anything.
It sounds like it’s going to be a significant lift, likely to “touch” every page, regardless of the approach. I fear the 2-3 things on my queue very likely to do the same.
Assuming the primary issue is “too many pages in a single group”, I think breaking into the multiple groups is the step to take:
Specifics of your exact setup notwithstanding, it seems to me an ideal solution in general:
Splits the total pages across 2-3 groups, with this nav issue being unlikely to come up again.
Likely to improve SEO with the addition of terms like “undergraduate” and “graduate” into your URL structure. (+1 for the marketing folks)
Moving directories using the File Browser may help minimize some of the work– not sure at this scale– but rebuilding the navigation in the new groups and defining redirects may balance that back out.
For identifying pages within a group for nav or other changes, what about page tags? Would let you define all the pages at once in the “Your Pages” section, rather than editing each one by one to complete a custom field. Tags still not ideal, since then someone has to remember to add a tag to each page added hereafter. Maybe would need to check for the 2-3 key tags and display a message in the page editor (frontend and details) if none exist on a page to prompt editors to add one?
(Aside: in our last CMS, I recall need a value for each page. If a page didn’t have a value set, the code would scan up the navigation, parent to grandparent and onwards, until it found a set value to use, or nothing and defaulted. If such a thing is possible here– seems unlikely working with real page files– you could define a value for the root page of each program (Biology), then have all the subpages use that value without having to define it for each page.)
Good news – for our forthcoming LW release (coming out later today) we’ve managed to find a way to rework some of the innards of the Navigation manager such that we can increase the supportable links in a single nav from ~550 to 1,200 before we run into PHP form limits. Hopefully this should give you plenty of headroom to manage what you need in a single mega-nav for a long while! More coming soon in the release notes later today.
Too many nav items. Too many pages may contribute to it, but distributing the pages isn’t the only solution. Since there does seem a solution on the way, I’ll share some last thoughts for the general record:
For the backend specifically, could opt to not list the sub-pages in the navigation view to save space. Though, it may make it hard to access them to make changes, or hard to remember what pages each program has for review. (I suspect this may be what you were wanting to do, with pages out of navigation needing some alternative definition. If so, maybe not not approach…)
Could try to minimize the number of sub-pages, merging any content possible into the root program page, going for a “infinite scroll” feel, leveraging anchors to access specific sections, etc. Fewer pages, fewer items in navigation, but also potential impacts for SEO, UX, etc.
In the end, go get that update and be free of the limits! Thank you Karl & Co. for saving Jon from any more of my brainstorming (and that other thing).
I fear the 2-3 things on my queue very likely to do the same.