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

[foxly]

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

[foxly]

Update:

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:

->get_nav_menu_locations()
->get_theme_mod('nav_menu_locations')
->get_theme_mods()
->get_option('theme_mods_$theme_slug')

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.

-F

[DJPaul]

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

[DJPaul]

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?

[foxly]

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

^F

[johnjamesjacoby]

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