Use Bedrock Autoloader package

[retlehs]

Ref #299

https://github.com/roots/bedrock-autoloader

[aaemnnosttv]

Awesome to finally see this happen! ❤️

Opened a PR against the autoloader repo which still has a few things that only belong here rather than in the package 🙂

[retlehs]

@aaemnnosttv merged and updated this PR, thank you!

[austinpray]

Sweet!!

[austinpray]

👍

[austinpray]

@aaemnnosttv do you care about this? roots/bedrock-autoloader#7

[vinkla]

I'm so glad this has finally happened! Great work everybody 🙌

I've explored integrating Bedrock's autoloader into WordPlate. If we load the plugins within the pre_option_active_plugins hook there is no need to keep this as a mu-plugin. Instead we could load it from the wp-config.php file.

public function __construct()
{
    if (isset(self::$instance)) {
        return;
    }

    self::$instance = $this;

    require_once ABSPATH . 'wp-includes/plugin.php';

    add_filter('pre_option_active_plugins', function () {
        $this->relativePath = '/../' . basename(WPMU_PLUGIN_DIR);

        if (is_admin()) {
            add_filter('show_advanced_plugins', [$this, 'showInAdmin'], 0, 2);
        }

        $this->loadPlugins();
    });
}

This would mean we could remove the bedrock-autoloader.php plugin in this PR and load mu-plugins from the wp-config.php file.

What are your thoughts on this?

[austinpray]

@vinkla Thank you for taking a look! Im interested in your idea, but note that it cannot live in the constructor as a side-effect. It makes testing difficult and side-effects in constructors is a strong anti-pattern. Ref roots/bedrock-autoloader#4

Working right now so can't respond in full.

[vinkla]

It makes testing difficult and side-effects in constructors is a strong anti-pattern.

Yes, this has been a pain point for us in WordPlate as well. Testing has been hard. I'll continue digging.