Skip to:
Content
Pages
Categories
Search
Top
Bottom

Plugin Devs Please Read


  • Andy Peatling
    Keymaster

    @apeatling

    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

    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

    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

    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

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


    Andy Peatling
    Keymaster

    @apeatling

    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

    @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

    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

    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

    Those aren’t working currently


    Andy Peatling
    Keymaster

    @apeatling

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


    Carlos Santa Cruz
    Participant

    @cmanon

    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

    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.

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘Plugin Devs Please Read’ is closed to new replies.
Skip to toolbar