[buddypress-trac] [BuddyPress] #3625: Core functions should not hook to bp_init with default priority

[buddypress-trac at lists.automattic.com]

#3625: Core functions should not hook to bp_init with default priority
-------------------------------------+------------------
 Reporter:  boonebgorges             |       Owner:
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  1.6
Component:  Core                     |     Version:  1.5
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |
-------------------------------------+------------------

Comment (by cnorris23):

 This is already confusing, but I just wanted to jump in too see if I can
 bring some clarity. First, while I don't think it's necessary, it
 definitely wouldn't hurt to load our more important business functions,
 like the ones listed by boone, a little earlier for those hooking into
 bp_init priority 10.

 Second, the biggest challenge with hooks is knowing when/where to hook. In
 the case of the wp_ajax_ hook example, it seems webraket is trying
 something like this

 {{{
 <?php
 class Webraket_Class {

         public function __construct(){

                 add_action('wp_ajax_', array(&$this,'my_wp_ajax_'));

         }

         function my_wp_ajax_() {
                 //
         }

 }

 function Init_Webraket_Class(){
         $webraket = new Webraket_Class;
 }
 add_action('bp_init', 'Init_Webraket_Class');
 ?>
 }}}

 The problem with this is that you're trying to hook a function to
 wp_ajax_, which itself is hooked to bp_init priority 10, within a class
 that's not instantiated until bp_init priority 10. While this doesn't
 preclude success (something I learned from Jeff Sayre's WordPress Hook
 Sniffer), it's doesn't mean that it will fail more times that not. In the
 case of the wp_ajax_ hook, the latest you could load your class would be
 like this
 {{{
 function Init_Webraket_Class(){
         $webraket = new Webraket_Class;
 }
 add_action('bp_init', 'Init_Webraket_Class', 9);
 }}}
 but even better would be
 {{{
 function Init_Webraket_Class(){
         $webraket = new Webraket_Class;
 }
 add_action('bp_include', 'Init_Webraket_Class');
 }}}
 or like boone stated on #3622
 {{{
 function Init_Webraket_Class(){
         $webraket = new Webraket_Class;
 }
 add_action('bp_loaded', 'Init_Webraket_Class');
 }}}

 >However when a developer only tests on /plugins and BuddyPress is loaded
 before the plugin, they won't have problems hooking into init. (until a
 multisite user drops their plugin into /mu-plugins)
 It's true that plugins in the mu-plugins folder using the init hook will
 find that BP isn't already loaded, but that's the nature of the mu-plugins
 folder. However, just because a plugin is in the /plugins folder doesn't
 mean that one will have success. It's a crap shoot, which I've learned
 from personal experience, and again, from Jeff Sayre's WordPress Hook
 Sniffer.

 @webraket I'll post some example code on #3622 on how to get your code
 working better.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/3625#comment:9>
BuddyPress <http://buddypress.org/>
BuddyPress