Architecture: Interaction with mu-plugins

[peterwilsoncc]

In WordPress, a plugin placed in the mu-plugins folder isn't considered active or installed, ie

in_array( 'some-mu-plugin/plugin.php', get_plugins() ) === false
is_plugin_active( 'some-mu-plugin/plugin.php' ) === false

In my experience, a plugin dependent on another has used a callback to check if it is present:

if ( function_exists( 'wc_get_products' ) ) {
    // WooCommerce is active, dependency met.
}

How will the plugin dependencies handle such a situation gracefully?

[afragen]

In all likelihood plugin dependencies won't handle this situation.

get_mu_plugins() can retrieve mu-plugin data but to what end? A mu-plugin shouldn't have a dependency and shouldn't be a dependency as there is no, non-manual way to install it.

[aristath]

I don't think that mu-plugins is something that should be handled by the plugin-dependencies implementation...

[dd32]

There are three types of mu-plugins:

1. Those that are self-contained mu-plugins, that aren't "normal plugins"
2. Those that are plugins, but stored within mu-plugins.
3. Those that are simply loaders, which forcibly include a plugin within the "normal plugin directory"

Case 1 doesn't matter here I feel, as although I'm sure some would want to use it, it seems like a reasonable thing to skip.
Case 2 probably doesn't matter too much, because they don't get updates anyway, and authors are going to run into other issues.
Case 3 is an example where is_plugin_active() will fail to return truthful even though a mu-plugin is forcibly including it

3 can probably be worked around by filtering get_plugins to always have the plugin get loaded (rather than require'ing it), and would probably suffice as a work-around for those who want to use the functionality.. but even then, I doubt it matters much.. given plugin dependencies are for those who want things handled automatically and aren't likely to want to use mu-plugins.

[twobyte]

I think checking mu-plugins for the existence of dependencies would be extremely helpful and is a very valid use case. Rather than bundling developer plugins like CMB2 or ACF into themes and plugins, putting them into mu-plugins makes a lot of sense to manage duplicity without overwhelming the admin dashboard. With wp-plugin-dependencies, the user is prompted to install another copy of these plugins when marked as required.

[afragen]

@dd32 I think @costdev and I have written a loader that solves Case 3.

https://core.trac.wordpress.org/ticket/60504#comment:15

https://gist.github.com/afragen/9117fd930d9be16be8a5f450b809dfa8

[ecotechie]

A mu-plugin shouldn't have a dependency and shouldn't be a dependency as there is no, non-manual way to install it.

Doesn't the Worker plugin from ManageWP install an MU plugin?
https://wordpress.org/plugins/worker/

[costdev]

Doesn't the Worker plugin from ManageWP install an MU plugin?

Yes and no. It does add a loader file to mu-plugins, because (from the loader's description):

to increase performance and reliability.

Also from the description:

It is automatically disabled when disabling the main plugin.

So this seems more like a file intended for loading ManageWP - Worker earlier than "normal" plugins. ManageWP - Worker itself is installed in wp-content/plugins, and is in active_plugins.

As such, it's detected as a dependency by Plugin Dependencies: