Skip to:

Opened 12 years ago

Closed 11 years ago

Last modified 8 years ago

#4431 closed defect (bug) (wontfix)

BuddyPress Default Theme is Incompatible with WP 3.4 "Menus" Functionality

Reported by: foxly's profile foxly Owned by: foxly's profile foxly
Milestone: Priority: normal
Severity: normal Version:
Component: Templates Keywords:
Cc: fanquake@…, mercijavier@…


This defect was probably introduced several versions ago.

When Parent->Child relationships are created between pages in the WordPress site navigation tree, the LEVEL-0 pages are supposed to be displayed in the template's nav menu, and the LEVEL-1 through LEVEL-N pages are supposed to be displayed in drop-down menus below the LEVEL-0 navigation items.

BuddyPress 1.6, and likely several BuddyPress 1.5 revisions before it, incorrectly display EVERY page on the site in the navigation menu regardless of the page's depth in the site navigation tree. This creates a major problem for site owners, because they can only have perhaps 8 pages on their site before overflowing the navigation menu.

The attached image file demonstrates the expected behavior (using the WP Twenty Eleven theme) and incorrect behavior (using BuddyPress default theme).

Attachments (1)

BP-Defect.jpg (186.1 KB) - added by foxly 12 years ago.

Download all attachments as: .zip

Change History (10)

12 years ago

#1 @fanquake
12 years ago

  • Cc fanquake@… added

#2 @foxly
12 years ago

  • Severity changed from major to normal
  • Summary changed from BuddyPress Default Theme Incorrectly Nests Child Pages in Primary Navigation Menu to BuddyPress Default Theme is Incompatible with WP 3.4 "Menus" Functionality


BP's template code appears to be working correctly. WP is feeding incorrect nav menu HTML to the template header.

The defect can be triggered at will by:

1) Creating two nested menu pages
2) Setting the active template to "Buddypress Default"
3) Navigating to Appearance->Menus and setting "Primary Navigation" to "Main"

The defect can be reversed by setting "Primary Navigation" back to the blank option in the drop-down box.

Although far less severe than a broken parent template, this defect is more-or-less guaranteed to cause vexing support issues because:

1) The "Menus" screen implies that the user is supposed to set a primary navigation menu.
2) Taking that action breaks the user's site
3) The action that breaks the site appears unrelated to the problem it causes - it took almost two hours of back-tracing through the WP core to discover the root cause of this problem.


Technical Details:

1) Setting "primary navigation menu" causes table: wp_options key: "theme_mods_bp-default" to be set containing the key nav_menu_locations?[0]primary?

2) During the header build process in template file "header.php" at line 42, function wp_nav_menu() is called. It calls the following chain of functions:


If any "nav_menu_location" keys are set in the "theme_mods_bp-default" database key, wp_nav_menu() internally generates the navigation menu HTML and returns it to the template function, which is UNDESIRED behaviour.

If the "nav_menu_locations" key is empty, wp_nav_menu() calls the fallback_cb function "bp_dtheme_main_nav" passed as an arg in the template. This calls bp_dtheme_main_nav() located at 597 in functions.php which generates custom HTML code with the structure necessary for a multi-level menu. This is the DESIRED behaviour.


I'm going to keep playing with this one and try and find a durable solution.


#3 @foxly
12 years ago

  • Owner set to foxly
  • Status changed from new to assigned

#4 @DJPaul
12 years ago

Is this a BP bug, or not? If it's a WP issue, we can close this ticket.

#5 @mercime
12 years ago

  • Cc mercijavier@… added

#6 @DJPaul
11 years ago

foxly, you describe this as a bug in WordPress. Do you have a trac ticket on the WordPress trac which we can link to, and close this ticket?

#7 @foxly
11 years ago

It would probably be better for us to code around this one.

1) Because it's not a Wordpress bug per-se, its rooted in how BP's theme interacts with WP.

2) Because we're already re-writing the default BP theme.

3) Because our WP trac ticket would probably be ignored until well into 2015 ... :)


Last edited 11 years ago by foxly (previous) (diff)

#8 @johnjamesjacoby
11 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

Closing this. Sounds like it's a non-issue now.

#9 @DJPaul
8 years ago

  • Component changed from Appearance - Template Parts to Templates
Note: See TracTickets for help on using tickets.