Skip to:
Content

#4629 closed enhancement (fixed)

New function which combines primary/secondary nav menus into one

Reported by: DJPaul Owned by:
Milestone: 1.7 Priority: normal
Severity: normal Version:
Component: Core Keywords:
Cc: hugoashmore@…

Description

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).

Attachments (2)

ticket-4629.001.patch (12.9 KB) - added by DJPaul 18 months ago.
ticket-4629.002.patch (13.1 KB) - added by DJPaul 18 months ago.

Download all attachments as: .zip

Change History (16)

DJPaul18 months ago

comment:1 follow-up: modemlooper18 months ago

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?

comment:2 dcavins18 months ago

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.

DJPaul18 months ago

comment:3 DJPaul18 months ago

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.

comment:4 in reply to: ↑ 1 DJPaul18 months ago

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.

comment:5 modemlooper18 months ago

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.

Last edited 18 months ago by modemlooper (previous) (diff)

comment:6 karmatosed18 months ago

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

comment:7 follow-up: modemlooper18 months ago

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?

comment:8 in reply to: ↑ 7 DJPaul18 months ago

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.

comment:9 modemlooper18 months ago

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.

comment:10 DJPaul17 months ago

  • Milestone changed from Awaiting Review to 1.7

comment:11 djpaul17 months ago

  • Resolution set to fixed
  • Status changed from new to closed

(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.

comment:12 hnla13 months ago

  • Cc hugoashmore@… added

comment:13 hnla12 months ago

  • Keywords 2nd-opinion needs-testing added
  • Resolution fixed deleted
  • Status changed from closed to reopened

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'

comment:14 DJPaul12 months ago

  • Keywords 2nd-opinion needs-testing removed
  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.