BP activation sequence fix

[burtadsit]

Howdy,

If bp is activated, after plugins that depend on it's classes is activated, then the dependent plugin will crash.

This fixes the issue.

// Check for bp being loaded, if not try and load it
// Insures that bp is loaded before this plugin
if (!function_exists('bp_core_setup_globals')){
	if ( file_exists( WP_PLUGIN_DIR . '/buddypress/bp-loader.php' ) ){
		require_once( WP_PLUGIN_DIR . '/buddypress/bp-loader.php' );
	}
	else{
		echo "BuddyPress is not installed!";
		return;
	}
}

Plugins will still have to detect if the bp component that contains their base class is activated within bp also.

[burtadsit]

The above might be included in the skeleton component code.

[burtadsit]

Classes that extend a bp class still can not depend that the component that the base class lives in is activated so:

if (function_exists('groups_setup_globals')){
class OCI_BP_Groups_Site_Groups_Template extends BP_Groups_Site_Groups_Template{
[snip]
} // class OCI_BP_Groups_Site_Groups_Template
} // if exists wrapper

Might be a good thing also.

[burtadsit]

Or

if (class_exists('BP_Core_Members_Template')){

[(none)]

Milestone Future Enhancements deleted

[johnjamesjacoby]

This is what I used for the BuddyBar, so maybe this could get put into the skeleton component? If done correctly, it will still allow your plugin to activate even without BuddyPress installed or activated, and your dependency plugin won't fail, it just won't do anything. This lets BuddyPress get turned off, deleted, or updated, and not have it cause conflicts with your dependency.

Basically I just wrap the file includes or function calls that would cause conflicts around a single check for this returning true. If it returns false, don't include those files or fire those functions.

	function bp_dependency_load_buddypress() {
		if ( function_exists( 'bp_core_setup_globals' ) )
			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' );
			return true;
		}

		return false;
	}

[DJPaul]

This is not a bug in BP but in 3rd party plugins. Probably best to be documented on the Wiki? Leaving open for discussion.

[johnjamesjacoby]

There really is no way for BuddyPress to activate itself before all other buddypress specific plugins, unless all BP plugins were somehow forced to register themselves with BuddyPress first.

Like a core component versus an external component?

[jeffsayre]

There should be reserved blocks of numbers set aside for key components (plugins). These numbers would be lower in the activation sequence, therefore gaining higher priority. So, BuddyPress for instance would always be assigned a reserved activation sequence number that is lower than any 3rd-party plugin that is developed to run on top of BuddyPress. The other way to do this is parent-child dependancies. All BuddyPress plugins would be a child to the parent component.

[johnjamesjacoby]

This is no longer an issue in 1.2. No 1 specific patch addressed it but several actions were added to make life easier on external plugins.