Skip to:

Opened 15 years ago

Closed 14 years ago

#762 closed enhancement (fixed)

BP activation sequence fix

Reported by: burtadsit's profile burtadsit Owned by: johnjamesjacoby's profile johnjamesjacoby
Milestone: Priority: major
Severity: Version:
Component: Keywords: component, skeleton



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' );
		echo "BuddyPress is not installed!";

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

Change History (10)

#1 @burtadsit
15 years ago

The above might be included in the skeleton component code.

#2 @burtadsit
15 years ago

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{
} // class OCI_BP_Groups_Site_Groups_Template
} // if exists wrapper

Might be a good thing also.

#3 @burtadsit
15 years ago


if (class_exists('BP_Core_Members_Template')){

#4 @(none)
15 years ago

  • Milestone Future Enhancements deleted

Milestone Future Enhancements deleted

#5 @johnjamesjacoby
15 years ago

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;

#6 @johnjamesjacoby
15 years ago

  • Owner set to johnjamesjacoby
  • Status changed from new to assigned

#7 @DJPaul
15 years ago

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

#8 @johnjamesjacoby
15 years ago

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?

#9 @jeffsayre
15 years ago

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.

#10 @johnjamesjacoby
14 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.