New function which combines primary/secondary nav menus into one

[DJPaul]

Patch implements a proposed merged nav menu function. Written for the turtleshell template pack.

BP currently renders its menus via bp_get_displayed_user_nav() and bp_get_options_nav(). It's been an annoying quirk that we've ended up with these two get_ functions which print the output rather than return it. Historically, these menus have always been visually separate in the Default theme; either vertically before 1.2, and horizontally nested since 1.2. Something that's been asked from the community is a way to produce a merged menu

This can't be done today without plugins/themes touching the $bp object. A merged menu would allow e.g. easy implementation of a multi-level, expand-on-mouseover menu -- just like the main navigation of a lot of WordPress themes.

The attached patch implements this proposed feature, and introduces a custom Walker class and bp_nav_menu(). The arguments for bp_nav_menu are identical to wp_nav_menu(), providing maximum customisation and familiarity for WordPress theme authors, and should give us reasonable future compatibility (bp_nav_menu() could become a wrapper).

[modemlooper]

This is great. I looked over code and I think the best way to allow user arrangement/removal of items (using WP admin menus) is to intercept the sort order and use a menu from the admin. BP could register a menu location maybe called user navigation, then the walker can detect if a menu is in this placement the sort the items from this menu. if no menu then it just defaults.

So, basically just using the WP menu admin as a UI for bp nav. No learning curve for an end user. It would just work like any other menu.

Thoughts?

[dcavins]

I agree that a sane way to handle menus would make BP much easier for new users. Especially if they behave like WP menus. I think Paul's going for BP MVP status with this patch.

[DJPaul]

Thanks for the positive feedback, everyone.

ticket-4629.002.patch corrects a CSS class that was mistakenly being applied, and fixes an issue where the Profile menus weren't being nested correctly. That latter problem is interesting; there's some "xprofile" vs "profile" inconsistencies going on due to how the navigation globals are built, and trying to correct that caused a lot of its own problem, so I've handled it here.

[DJPaul]

Replying to modemlooper:

I looked over code and I think the best way to allow user arrangement/removal of items (using WP admin menus) is to intercept the sort order and use a menu from the admin.

I think you'd be best to use bp_get_nav_menu_items() to do this, right? You can replace the menus' link/name/parent properties to map the details from the Menus admin screen.

BP could register a menu location maybe called user navigation, then the walker can detect if a menu is in this placement the sort the items from this menu. if no menu then it just defaults.

Sure, but this is beyond the scope of 1.7.

[modemlooper]

I'll play with this more when the walker code is solid. But yes, 1.8 is more realistic for wp menus. Because you'll need to create walkers for directory menu.

[karmatosed]

Not much to say aside from really pleased this is happening.

[modemlooper]

I'm having an issue recreating something WP already provides. Why create the function bp_nav_menu when wp_nav_menu exists? wp_nav_menu has argument for walker. Can't we just use that?

[DJPaul]

Replying to modemlooper:

Why create the function bp_nav_menu when wp_nav_menu exists?

wp_nav_menu always goes and finds a (WordPress) Menu, finds a theme location, and gets the Menu's items. That's overhead that we don't need, and there's also some logic in the WordPress function that bails out if it can't find a menu or if the menu it finds has no menu items, which we can't work around.

If/when in a future release, BP registers a menu location and integrates fully into WordPress' Menus admin screen, I think there's a reasonable chance that bp_nav_menu() could become a simple wrapper for wp_nav_menu(), but I don't think it's possible yet.

[modemlooper]

I'm basically doing what you say we dont need to make WP menus work. Not a clean way to do that without some sort of theme location. I'm registering a menu location, and then testing if a menu is there if so filter out bp_nav_menu.

[djpaul]

(In [6503]) Introduces bp_nav_menu(), which displays a merged navigation list from registered components. Fixes #4629.

BP has historically used bp_get_displayed_user_nav() and bp_get_options_nav() to render the navigation, and these menus have always been visually separate in the Default theme; either in columns before 1.2, and in rows since 1.2.

To provide more customisation for theme authors, and have both parts of the navigation displayed in the same block, this change introduces a merged menu function, with the parts from bp_get_options_nav nested appropriately under bp_get_displayed_user_nav.

[hnla]

There could be a potential issue with bbPress grabbing / hijacking the favourites submenu.

Clicking Activity > Favourites has the effect of setting the forum parent li element to the class 'current-menu-parent' where only the activity li element should have this. Result in my implementation is the submenu elements are overwriting the activity submenu items due to the class on forums li set to 'current-menu-parent'

[DJPaul]

Hnla, if you think you've found an issue, please create a new bug report. This ticket was/is an enhancement ticket, and the feature's been added.