Skip to:

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#3438 closed defect (bug) (fixed)

bp_core_remove_nav_item, bp_core_remove_subnav_item not working anymore

Reported by: sbrajesh's profile sbrajesh Owned by:
Milestone: 1.5 Priority: normal
Severity: normal Version:
Component: Core Keywords: needs-testing
Cc: sbrajesh


Just checked out revision r4926 and now the bp_core_remove_nav_item, bp_core_remove_subnav_item has stopped working.

I tried by putting these into functions.php of my theme

bp_core_remove_nav_item($bp->groups->id) also using the hard coded slug "groups" but none of these worked.
Same goes for the subnav, I tried removing the "mentions" subnav from activity using
global $bp;
bp_core_remove_subnav_item($bp->activity->id, 'mentions');

But that does not work. The code works for bp 1.2 branch though.

I am not sure of the issue yet. Just had a quick look and seemed like the nav menus are getting registered too late( can not confirm at the moment though). Will check in the evening and get back with more details.

Anyone else having the same issue ?

Change History (4)

#1 @r-a-y
13 years ago

Subnav works for me. Make sure you're using it on the 'init' action. I haven't tried it on an earlier hook.

Haven't tested with main bp_core_remove_nav_item().

#2 @boonebgorges
13 years ago

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

Confirmed that it works in BP 1.2.x and not in BP 1.5.

I have a sense that, if it was working in 1.2.x, it was only by accident. The best practice for modifying navs is to do it inside a function hooked to bp_setup_nav or later. Simply putting bp_core_remove_nav_item(), unhooked, into functions.php, seems like it's doing it wrong.

The cause for the difference is some load-order juggling that was done earlier in the dev cycle, which was necessary to abide by WP's rules (newly enforced with WP 3.1, I think) about using conditional tags like is_page() before the 'init' action. Thus, in BP 1.2.x, the bp_setup_nav action is hooked to bp_loaded, which in turn is hooked to plugins_loaded (ie before init). Now bp_setup_nav is hooked to bp_init, which is in turn hooked to init. We can't simply revert to the old way, because it will cause all kinds of problems with WP.

Looking at the way that WP loads functions.php, I think it will be impossible to be fully backward compatible here. See Your theme's functions.php is loaded before init. There is no way around this.

In sum:

  • sbrajesh is right, but the previous behavior was the result of an error. Best practice is to do your item removal inside a function hooked to bp_setup_nav, with a priority of 10 or greater.
  • We can't revert to the previous behavior, because of WP rules about load order, so we have to be satisfied with this unintentional "regression"

Later today, I'll write a short blog post on bpdevel that warns plugin/theme authors about this issue.

#3 @sbrajesh
13 years ago

Thanks Boone for the very nice explanation and the post. I was suspecting it to be the load order though I missed it thinking the bp_setup_nav was hooked to plugins_loaded. I guess, It's time to recheck the order of bp_include/loaded etc again :)

#4 @johnjamesjacoby
13 years ago

  • Milestone changed from Awaiting Review to 1.5
  • Version 1.5 deleted

Moving closed ticket out of Awaiting Review.

Note: See TracTickets for help on using tickets.