Skip to:
Content

BuddyPress.org

Opened 9 years ago

Closed 8 years ago

#2644 closed defect (bug) (no action required)

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

Reported by: youngmicroserf Owned by:
Milestone: 1.5 Priority: major
Severity: Version:
Component: Core Keywords: [needs-patch] navigation rewrite
Cc: boonebgorges@…

Description

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.

Change History (8)

#1 @youngmicroserf
9 years ago

  • Keywords navigation added; navigaiton removed

#2 follow-up: @DJPaul
9 years ago

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.

#3 in reply to: ↑ 2 @youngmicroserf
9 years ago

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.

#4 @johnjamesjacoby
9 years ago

  • Keywords [needs-patch] added
  • Priority changed from normal to major

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.

#5 @boonebgorges
9 years ago

  • Cc boonebgorges@… added

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.

#6 @boonebgorges
9 years ago

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.

#7 @johnjamesjacoby
9 years ago

  • Milestone changed from 1.2.6 to 1.3

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

#8 @boonebgorges
8 years ago

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

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.

Note: See TracTickets for help on using tickets.