Topic: Plugin Devs Please Read

Plugin Devs Please Read

Andy Peatling
Keymaster

@apeatling

14 years, 9 months ago
I should highlight this again since it has changed, and it’s very important.

If you’re building a plugin that relies on BuddyPress, you MUST make sure it doesn’t break the site if BuddyPress is disabled and your plugin is left enabled. A perfect example of this scenario is upgrades.

It’s easy to do this. I’ve found a good solution is to use a loader.php file and include this code (based on code from jjj):
```
/*

Plugin Name: My Plugin

Plugin URI: http://example.org/my-plugin/

Description: My BuddyPress plugin

Version: 1.0

Requires at least: WordPress 2.9.1 / BuddyPress 1.2

Tested up to: WordPress 2.9.1 / BuddyPress 1.2

License: GNU/GPL 2

Author: Some Person

Author URI: http://example.org/me/

*/



/* Only load the BuddyPress plugin functions if BuddyPress is loaded and initialized. */

function my_plugin_init() {

require( dirname( __FILE__ ) . '/my-plugin-bp-functions.php' );

}

add_action( 'bp_init', 'my_plugin_init' );



/* Add any code here that does not rely on Buddypress */
```
So basically include any code that will not work if BuddyPress is disabled in a separate file that is only loaded when BuddyPress is active and ready. That way if BP is disabled, the code will never be loaded an won’t whitescreen an install.

Viewing 12 replies - 1 through 12 (of 12 total)

D Cartwright
Participant

@aekeron

14 years, 9 months ago

Hi Andy,

I would recommend adding this code snippet to the skeleton component/group api code/docs too if you’ve not already done so.

Andy Peatling
Keymaster

@apeatling

14 years, 9 months ago

Thanks, I’ve now added a codex page for this and linked it in various places:

https://codex.buddypress.org/how-to-guides/checking-buddypress-is-active/

D Cartwright
Participant

@aekeron

14 years, 9 months ago

Great, thanks

I know in the past, especially when first starting out, I often used those code snippets as a starting point.

Boone Gorges
Keymaster

@boonebgorges

14 years, 9 months ago

What does this do for backward compatibility of plugins? bp_init is new, right?

Andy Peatling
Keymaster

@apeatling

14 years, 9 months ago

The nice thing is by including a separate file you don’t have to do if ( function_exists() / class_exists() / method_exists() ) checks.

Andy Peatling
Keymaster

@apeatling

14 years, 9 months ago

@Boone Gorges if you want to be backwards compatible then you could also check for if ( is_defined( ‘BP_VERSION’ ) )

The bp_init action is new in 1.2 and will fire once all of BuddyPress is loaded. It’s called in bp-loader.php if you want to check it out.
John James Jacoby
Keymaster

@johnjamesjacoby

14 years, 9 months ago
A few other actions were added in 1.2 to help plugin authors hook into the correct places within BuddyPress.
```
bp_setup_globals

bp_setup_nav

bp_setup_root_components

bp_setup_widgets
```
The intent of those hooks for plugin authors, is to not load your code before BuddyPress does, potentially putting your navigation menus or global component setups out of alignment with BuddyPress. Typical WordPress priority rules apply, so it is still possible to bump your plugin ahead of BuddyPress if you need to.
calvin_42
Participant

@calvin_42

14 years, 8 months ago

Hi there!

Does the hook “bp_setup_globals” has been released for plugins in the last 1.2.2 ? I can’t make it work.

Thanks

Paul Wong-Gibbs
Keymaster

@djpaul

14 years, 8 months ago

Those aren’t working currently

Andy Peatling
Keymaster

@apeatling

14 years, 8 months ago

These won’t work until 1.3 as the priorities are not set so plugins can access them.

Carlos Santa Cruz
Participant

@cmanon

14 years, 8 months ago

Is there some document/example that works with 1.2? I’ve spend some time with the sample component 1.4 but none of the hooks seems to work.

Regards.
Jeff Sayre
Participant

@jeffsayre

14 years, 8 months ago
Here’s how I handle it for my BuddyPress Privacy Component. I have a loader file called bp-authz-loader.php. It contains all the necessary plugin metadata at the top of the file. After the metadata, I have this as the first function:
```
/**

* BPAz_init()

*

* Initialize basic constants and make sure BuddyPress

* is installed and activated. If true, then allow for

* Privacy Component to finish loading.

*

* @since 0.4

*/

function BPAz_init() {



/* Define the component's parent folder name */

define( 'BP_AUTHZ_PLUGIN_NAME', 'bp-authz' );



/* Define component's directory and URL Paths */

define( 'BP_AUTHZ_PLUGIN_DIR', WP_PLUGIN_DIR . '/' . BP_AUTHZ_PLUGIN_NAME );

define( 'BP_AUTHZ_PLUGIN_URL', WP_PLUGIN_URL . '/' . BP_AUTHZ_PLUGIN_NAME );



/* Define the directory where user settings' functions reside */

define( 'BP_AUTHZ_SETTINGS', BP_AUTHZ_PLUGIN_DIR . '/' . 'settings' );



/* BuddyPress is installed and activated, finish initialization and go! */

require_once( BP_AUTHZ_PLUGIN_DIR . '/bp-authz-core.php' );

}

add_action( 'bp_init', 'BPAz_init' );
```
I have two more functions in this file, one to register the plugin upon activation, the other to register it upon deactivation. But that is all. Just these three functions.

If BuddyPress is installed and activated, BPAz_init() will fire, resulting in the rest of my component being activated when bp-authz-core.php is loaded. I’ve tested it and it works as expected without causing BP to crash. In other words, if BP is not activated but my plugin is activated, nothing happens. This is what you want.