OK, I’m sure I’m simply being incredibly thik, but I’ve been fiddling around for two hours trying to get this absolutely simplest and most basic of CMS menu function to work, namely: get a separate subnav to display all pages under a root element.
If any page in the “B” tree is open (including the root “BBB” and the third-level “bb1”), the Custom Menu Wizard should simply display all of B’s subnav elements, i.e.
It should not display anything to with “A” or “C”, it should not hide “b1” if “bb1” is selected, it should simply display all below “BBB”.
What I have now is
[custom_menu_wizard menu=9 children_of="root" fallback_parent=1 start_level=2 depth=2 depth_rel_current=1 include="parent" contains_current=1]and then I have to hide the root element in CSS or something similarly silly.
Can anybody point me as to where I go utterly astray here? Thanks!
No, you’re not being thick : unfortunately, what you are asking for is currently not possible with CMW v2*.
Why? Well, at the moment the when-to-display options (as opposed to the what-to-display ones) are very limited – in that they only relate to the end result of the what-to-display options.
So, for example, you can currently select what-to-display as being, say, “children of B”, but then the only when-to-display option is for the current menu item to be contained within that output (which excludes B itself).
What you need to be able to do – whether or not it’s the “simplest and most basic” function – is initially set the B branch as being the prime selector, set the output as being conditional upon that branch containing the current item, then filter the final output to not show the branch’s top level.
Where does that leave you? At present, CMW alone just won’t do what you need, so you can either style the output as you have been, or use CMW in conjunction with something like Dynamic Widgets.
However, version 3 of CMW – which I am currently testing – will give you the functionality you’re after, but the problem (for me!) is that it’s a fairly radical change of approach in that it switches from “children of ITEM” to “branch starting with ITEM”. Automatic conversion from v2-style configuration to v3-style configuration is proving to be nigh-on impossible, which means that the widget still needs to support the legacy setups as well as the new-style configs.
If you would like to help me out by trying v3 (pre-release) then I will gladly send you a zip of the code?
Thanks a lot wizzud for your detailed explanation – much appreciated indeed!
I’m currently building a client site using CMW – do you think v.3 might be ready for production (within about 2 weeks)?
I might be crazy, but I think I’ve got v2 doing what you describe. I’m using:
Children of[curent item]… starting level….for depth….relative to current item[true]
Fallback[switch to current + incl parent + with siblings]
Output [incl. parent + siblings + ancestors]
- if 2.0 is current + widget shows: all root items plus immediate children of 2.0 to 1 level. Perfect. (1 + 2 + 2.1 + 2.2 + 2.3 + 2.4 + 3)
- If 2.1 is current + widget shows: 2.0 + 2.1 (+ 2.1.n) + 2.2 + 2.3 + 2.4 (“correct CMS hierarchical” + but isn’t showing all root items which IMO + would be proper)
- IF 2.1.1 is current + widget shows the same items – good. It’s not uber traversing parent siblings + but same issue with no root items
What I cannot seem to have is the 2nd item above, with all root items showing. IMO, unless you’re talking a massive site, all root items should always appear as they are always relevant to navigation. That’s why they’re root items (right?!!!)
The widget is fantastic. I think there are a couple of approaches to cover fringe cases that might be helpful – I don’t know if they’re doable…
- A “simple solution”: “always show root items”. This would beat the hierarchical issue I’m currently experiencing, but might not solve at the 4th+ levels.
- Probably the “real solution” (if doable): instead of a fallback for “switch to current parent item”:
- Include parent boolean (ie: divorce this setting from ‘switch to parent’)
- Include parent’s siblings boolean
- Include ancestors (should this even be optional! always on!)
- Include ancestor siblings up to what level of depth (0,1,2,3,4,5)
- (crazy talk option) Ancestor sibling depth (0,1,2,3,4,5)
For option 2 – including parent + parent siblings + ancestors + ancestor siblings (1, being my root) would do exactly what I’m personally after. But forget that it would help me, I think this is the logical solution if it is doable. It would amount to “drill down as far as you want, and expand the ancestral levels as much as you desire”.
Item 2e is just me dreaming 🙂 I doubt it would be used in 99.999% of cases. But theoretically, you might want ONE level of subs on all ancestors.
Forgot to add: you could also just add an option for “items to always show, regardless of filter”.
This would probably be the easiest of all to implement!
For 3 level deep menus, you’d only have to add “with siblings” to “include ancestors” to get the full hierarchical+roo rendering.
Thanks Spanka. I’ll give your suggestions some serious consideration (without making any promises!)…
- The topic ‘Simplest of CMS menu functions’ is closed to new replies.