Multiple instances

[tivnet]

@justintadlock:

Hi Justin,

How would you recommend handling this:

My plugin has Butterbean version 1.2.3 and works fine, alone. However, there is another plugin, and it loads its own copy of BB, version 1.0.0. Their version will break my code because it's old. My version will break my code because it's new :)

That can be done?

Thank you! -- Gregory

[justintadlock]

That's why the instructions show how to load it only on your own post type screens. I built ButterBean for the purposes of including with a custom post type.

Obviously, there'll be folks who use it in their own interesting ways. And, they're more than welcome to do this. However, I'd recommend custom namespacing in those cases.

Of course, I'm open to any ideas.

One problem is that WordPress.org is no longer allowing frameworks into the plugins repository. If it were allowed, the ButterBean plugin version would always be loaded first. See: https://make.wordpress.org/plugins/2016/03/01/please-do-not-submit-frameworks/

And, until WordPress core builds in proper dependency management, this will always be a question that comes up in regards to frameworks and libraries.

[tivnet]

no longer allowing

Exactly. That was the only solution with ReduxFramework, and that's why I am asking...

load it only on your own post type screens

OK. Hope, everyone will do the same... Wonder if you can "force" that in your code... :)

custom namespacing in those cases

(sigh)

There is also a "builder" way: sed s/Justin/Gregory/g for all BB files :)

[justintadlock]

One solution is to include a "loader" class that would change names and load priorities with each release. Then, I could hook it to plugins_loaded (or some hook) with a high priority like 9999.

Something like:

class ButterBean_Loader_100 {

    // inside __construct() method. decrease priority with each release.
    add_action( 'plugins_loaded', array( $this, 'setup' ), 9999 );
}

That would always make sure the latest version is used. Of course, back-compat would be paramount in a situation like that.

I'm not really a big fan of that method, but it's possible. I'd rather only use that method as a last resort.

load it only on your own post type screens OK. Hope, everyone will do the same... Wonder if you can "force" that in your code... :)

Technically, I could. However, that will eliminate the possibility of using ButterBean as a standalone plugin. That's not something I'm open to because I'm running it on my own sites like this.

I don't like the idea of forcing developers into using something only one way though. But, I'll have very strongly recommended methods for including it in plugins.

There is also a "builder" way: sed s/Justin/Gregory/g for all BB files :)

Sorry, I don't know what that means.

[tivnet]

One solution is to include a "loader" class

I like this. Great idea.

I don't know what that means.

Emulate namespacing by prefixing all class names with something unique before embedding. Can be automated. Ugly, but probably solves all problems.

[slaFFik]

loader class

It seems, that's what CMB2 is doing. https://github.com/WebDevStudios/CMB2/blob/master/init.php#L64

[m-e-h]

https://github.com/jtsternberg/wp-lib-loader

[justintadlock]

Could it be something as simple as this?

    // Version 1.1.0

    add_action( 'init', 'butterbean_loader_110', 9998 );

    function butterbean_loader_110() {

        if ( ! defined( 'BUTTERBEAN_LOADED' ) ) {
            define( 'BUTTERBEAN_LOADED', true );

            require_once( 'path/to/class-butterbean.php' );
        }
    }

    // Version 1.0.0

    add_action( 'init', 'butterbean_loader_100', 9999 );

    function butterbean_loader_100() {

        if ( ! defined( 'BUTTERBEAN_LOADED' ) ) {
            define( 'BUTTERBEAN_LOADED', true );

            require_once( 'path/to/class-butterbean.php' );
        }
    }

[justintadlock]

I'm going to consider this closed for now. If anyone runs into trouble with testing this, just let me know.