Menu tree vs. Path tree

[Brian Rutledge]

Given a Page tree with slugs:

• section-1
• subsection-1
• page-1
• page-2
• subsection-2
• page-3
• section-2

The path for page-2 would be "/section-1/subsection-1/page-2/". However, I would rather it be "/section-1/page-2/", while maintaining the navigation hierarchy. At the moment, I'm accomplishing this by setting "Overwrite URL" to "section-1/page-2" in "Advanced settings" for page-2. But, if the slug for section-1 ever changes, I have to manually its child pages.

 

I found one related discussion from ~2 years ago. Somebody else suggested using a separate app to maintain a section tree. I see that the 3.5 roadmap includes "Multiple menus", and there's a Menus/pagetree refactor issue on GitHub.

With all of that said: can any of the developers elaborate on the future of the Page tree and Menus? Will it address the use case described above?

Thanks!

[Angelo Dini]

Hello Brian

the intended goal of Multiple Menu support is to avoid creating menu entries with reverse id's to for example render /footer/impressum, /footer/about...

you will be able to create additional menus /besides "Main Navigation" that than can be used using a template tag, for example {% show_partial_menu 0 100 100 100 "footer_navigation" %}

this will solve the issue for extra menus. It will however not solve the issue in a current tree rendering. So in your case:

• section-1
• subsection-1
• page-1
• page-2
• subsection-2
• page-3

Section 1 would be a new "Multiple Menu" node "Section 1". It's url will _not_ be rendered when parsing the menu. The path will also not be /section-1/subsection-1/page-2 anymore as it acts from its root: subsection-1/page-2. "section 1" will then only be a label. Ofc. you can still have naming/slug collisions if another menu defines that already.

Hope that helps.