bp_core_remove_nav_item(‘groups’) removes access to groups, not just navigation

[youngmicroserf]

In my installation (3.0.1./1.2.5), when I remove the group nav link from a member profile with bp_core_remove_nav_item(‘groups’) with a function in functions.php, I am no longer able to access group pages at all. I can access the group directory by entering the the URL and links to groups will be displayed there, but clicking on any of the group links will take me to the site's front page, as will directly entering the group URL.

Based on the function name and the fact that the groups directory is still displayed this seems like a bug to me.

[DJPaul]

I'm unable to recreate this on branch 1.2. bp_core_remove_nav_item() should remove the nav item menu from the navigation that appears, for example, on a member's profile page.

[youngmicroserf]

Replying to DJPaul:

I'm unable to recreate this on branch 1.2. bp_core_remove_nav_item() should remove the nav item menu from the navigation that appears, for example, on a member's profile page.

It does remove the item, both in the admin bar as well as on the profile, but it also removes the ability to access any individual group for me.

[johnjamesjacoby]

Confirmed.

Bumping the priority up if anyone wants to tackle this one, otherwise it may will probably pushed to 1.3.

This is a defect of the way the navigation is built when the menu and the tabs were consolidated early in 1.1.

The same thing will happen with any other component. If you remove 'activity' and have that component set as the home page of your profile, you also cannot access your profile.

A proper fix would require mirroring the values into a separate menu array, and then having specific functions to manipulate the display of the menus versus the tabs.

[boonebgorges]

I've noticed this before too. I always thought it was a bit funny that bp_core_new_nav_item(), which sounds like it's just about navigation, is also the only place where the screen_function for that particular tab is ever referenced.

JJJ, an alternative approach to your suggestion is to add a parameter to bp_core_new_nav_item(), something like 'show_in_nav', which defaults to true. Then, if someone wants to remove the nav item but not access to the page, then can use bp_core_remove_nav_item() and then readd it using show_in_nav = false. This is a little clunky, but it has the advantage of not making major changes to the $bp global in a dot-dot release.

[boonebgorges]

I'm thinking we're going to have to punt this to 1.3. The proper fix that JJJ outlines is going to break some plugins that exploit the current behavior of bp_core_remove_nav_item(). I also think that a proper fix will involve changing the way that the core components register their screen functions with a function that has a name that is less misleading than 'bp_core_new_nav_item'. This introduces lots of possibilities for breakage, too much for 1.2.6 I reckon.

[johnjamesjacoby]

Agreed. Too big to handle for 1.2.6. Getting the iron boot to 1.3.

[boonebgorges]

As a result of the way that top-level components are loaded in BP 1.3 (via WP pages), this is no longer an issue.
bp_core_remove_nav_item('groups'); removes only the group nav item under the profile; you can still access all group content.