Looks like a cleaner way to do it than the old cold I saw DJPaul post a few months back. Is the below incorrect in some way? I’ll probably move over to this way of doing things but we’re literally just about to launch a site with bp-groupwiki and the latest buddypress/wpmu (seems fine in terms of usability):
/* Check that BuddyPress is loaded before Wiki, from DJPaul */
function wiki_load_buddypress() {
if ( function_exists( ‘bp_core_setup_globals’ ) ) {
require_once (‘bp-groupwiki-main.php’);
return true;
}
/* Get the list of active sitewide plugins */
$active_sitewide_plugins = maybe_unserialize( get_site_option( ‘active_sitewide_plugins’ ) );
if ( !isset( $active_sidewide_plugins[‘buddypress/bp-loader.php’] ) )
return false;
if ( isset( $active_sidewide_plugins[‘buddypress/bp-loader.php’] ) && !function_exists( ‘bp_core_setup_globals’ ) ) {
require_once( WP_PLUGIN_DIR . ‘/buddypress/bp-loader.php’ );
require_once (‘bp-groupwiki-main.php’);
return true;
}
return false;
}
add_action( ‘plugins_loaded’, ‘wiki_load_buddypress’, 1 );
@D Cartwright – that way will not work with single WP. The way I posted will work with any version.
Unloading the plugin is not that user friendly as it doesn’t tell you why it won’t activate. Instead with a “return;” call in the code above it will still activate, but will not execute any code. That way everyone is happy, and nothing chokes.
Ah great. Thanks for clearing that up 
For the time being, our groupwiki plugin requires multiple blogs anyway so I won’t rush out to change the code. I’ll make sure that the version that is released in a week or two is correct and up to date though.
Looks like a cleaner way to do it than the old cold I saw DJPaul post a few months back.
I hope you’re not criticising that code I posted a few months ago doesn’t work fully with the newest cutting-edge version of BuddyPress?
Not at all. I was trying to provide credit for your code as I pretty much just copy-pasted it rather than work out the problem for myself.
Don’t be so touchy
( Trust me, once the groupwiki plugin is out and you see the dodgy code in there, it will be quite obvious that I wouldn’t critisize the code of the helpful people/plugin developers on here )
edit: Ah, I can’t edit my original post to make sure it’s clear that I’m not trying to be insulting about your code DJPaul. Apologies.
For BuddyPress 1.2, I’ve been using this.
function your_custom_loader() {
// Put the code that needs BuddyPress here. This could be something like...
require_once( WP_PLUGIN_DIR . '/your-custom-plugin/your-plugin-buddypress.php' );
}
if ( defined( 'BP_VERSION' ) )
your_custom_loader();
else
add_action( 'bp_init', 'your_custom_loader' );
This way it isn’t loading any files and isn’t force loading BuddyPress; instead it’s looking to see if it’s active, and if it is your plugin loads; if it’s not it adds itself to the new bp_init action at the end of the BuddyPress load cycle, and loads then.
This method also follows the philosophy that plugins should be made for WordPress but be BuddyPress aware. This way you can tuck your BuddyPress functions and features away in a special your-plugin-buddypress.php file, and only load that file when BuddyPress is already loaded and active, and without errors.
Also, you’re not adding any overhead by doing this, other than a binary check for BP_VERSION. Your plugin will load itself as usual in the WordPress plugins screen, and will only start looking for BuddyPress code when BuddyPress tells it too. This is actually how I made the BuddyPress Backpat plugin load itself.
Update:
https://trac.buddypress.org/changeset/2472/trunk
Now dependent plugins can hook their code into bp_init and know that all plugins have been loaded.
If you’re a plugin author and are writing a plugin specifically for BuddyPress you will want to load your code by doing exactly what I describe above.
Cool, that is better – although the code above is not forcing BuddyPress to load, it first checks to see if it’s active, then loads it if it is.
@JJJ
In the change sheet, I see you are calling this on “plugins_loaded” action, that too with default priority level, does that mean, we do not need setup globals/other things using “plugins_loaded” action in our plugins, and we have to stick with this “bp_init” action.
btw, It is a cool idea, I am going to test with the trunk, If it works, It will certainly help 3rd party plugin developers greatly
Edit: corrected a typo
What’s the difference between using bp_init() and plugins_loaded()?
I’ve been using plugins_loaded() on some developmental plugins.
hi Ray
plugins_loaded is the standard action which gets called when all the active plugins’s source code is included(loaded) by wordpress, so It tells you that all the plugins are ready, and you can call your functions now.
The advantage of using “plugins_loaded” action is that, it is the first action hook which gets called after your(/all other active plugins source code is loaded by wordpress) , so You can be sure your code is called quiet before anything else happens.
Investigate wp-settings.php for more.
JJJ has proposed a nice solution with the bp_init action(just introduced in the r2472).
Because wordpress does not guarantees which plugin gets loaded first( it has something like, the plugins consisting of bare files are loaded first, the the plugins which are inside their own directory loaded alphabetically, AFAIK,It might have changed recently), So a plugin which is dependent on buddypress, will have many issues detecting bp is loaded or not.
So, JJJ’s solution helps there as all the buddypress methods which are called on plugins loaded action have priority less than default(less means higher priority), so if we hook to bp_init, we can be sure buddypress is loaded and you are still calling at the same action, I am already trying my hand with this, and it seems to be working,still testing though.
btw, if you have your plugins, which uses the hook “plugins_loaded” and has priority greater than 10, i.e 11 or anything else, you don’t need to worry about this change.
Cool, thanks for the detailed explanation, Brajesh.
I want to keep compatibility with older versions of BP (for now anyway), so I’ll use plugins_loaded with a higher priority.
@r-a-y
Using plugins loaded still does not promise that the user has BuddyPress installed on their site and activated on that particular blog, so you will still want to do the check for BP_VERSION.
It’s a dizzying setup, trying to make plugins off of plugins that may or may not be there, or are there but just aren’t loaded yet, or are loaded before yours because another plugin force loaded it out of order.
Going forward from BP1.2, we can avoid all of those issues. Remember too that bp_init has priorities too. If you need to make sure your plugin is loaded before any other BuddyPress extensions are, you can prioritize it’s load the same way as any other WordPress action.
Just an FYI for everyone.
I’ve had to revert to DJPaul’s code for the plugin I’m working on currently as the method JJJ posted appears to have stopped working.
No insult intended towards anyone’s code btw.
I ran into a problem with the bp_init method of loading, and need some feedback.
‘bp_init’ is called on ‘plugins_loaded’ p10, but ‘bp_core_set_uri_globals’ runs on ‘plugins_loaded’ p3 which depends on $bp->root_components. So its not possible to add a root component using ‘bp_init’ in time for some of the setup calls.
Here is my hack to make it work right until a solution is agreed upon. You need an additional function:
function bp_foobar_setup_root_component() {
// Register 'foobar' as a root component
if ( function_exists( 'bp_core_add_root_component' ) )
bp_core_add_root_component( BP_FOOBAR_SLUG );
}
add_action( 'plugins_loaded', 'bp_foobar_setup_root_component', 2 );
