[buddypress-trac] [BuddyPress] #3438: bp_core_remove_nav_item, bp_core_remove_subnav_item not working anymore

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Fri Aug 5 12:44:53 UTC 2011

#3438: bp_core_remove_nav_item, bp_core_remove_subnav_item not working anymore
 Reporter:  sbrajesh       |       Owner:
     Type:  defect         |      Status:  closed
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Core           |     Version:  1.5
 Severity:  normal         |  Resolution:  fixed
 Keywords:  needs-testing  |
Changes (by boonebgorges):

 * status:  new => closed
 * resolution:   => fixed


 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.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/3438#comment:2>
BuddyPress <http://buddypress.org/>

More information about the buddypress-trac mailing list