#3438 closed defect (bug) (fixed)
bp_core_remove_nav_item, bp_core_remove_subnav_item not working anymore
Reported by: | sbrajesh | Owned by: | |
---|---|---|---|
Milestone: | 1.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Core | Keywords: | needs-testing |
Cc: | sbrajesh |
Description
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)
#2
@
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 http://core.trac.wordpress.org/browser/trunk/wp-settings.php#L279 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.
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().