Merge active mu-plugins to global "active_plugins"

[radeno]

Hi,

thank you for this module. WP have function to check if plugin is active https://developer.wordpress.org/reference/functions/is_plugin_active/ I think regular and must use plugins lists should be merged together, something like this:

            add_filter('option_active_plugins', function ($value, $option) {
                return array_merge($value, self::$cache['plugins']);
            }, 10, 2);

Sadly there is no option how to block installing same plugins in UI. WP using little bit messy function https://developer.wordpress.org/reference/functions/install_plugin_install_status/ and there is not any filter hook :/.

[jessuppi]

Thank you @radeno for this interesting suggestion.

Yes, you're right. It is a bit silly that WP Core cannot check if a plugin is installed already as a MU (Must-Use) plugin before allowing it to be installed as a regular plugin. However, even if it did, it seems reliant on their namespaces, which are easily (often) altered anyways...

Another potential issue I guess is the difference between checking "active" vs "installed", like the questions posed in this thread (since MU plugins = always on):

https://wordpress.stackexchange.com/questions/320538/how-to-distinguish-if-a-plugin-is-not-installed-or-just-not-active

Anyway, I'm not sure what Autoloader can do about this. Because even if Autoloader can add all the MU (Must-Use) plugins to the wp_options Transients or something it might have some other unintended effect in WordPress, later on... I'm not sure. Because as far as I understand the list of active plugins is meant for "regular plugins" and not MU (Must-Use) ones.

[radeno]

@jessuppi i know there MU-PLUGINS are always active and that is that point. We use mu-plugins as fundamental plugins which can't be deleted, disabled or corrupted even if client account has highest authorization.

Main reason is that mu-plugins contains necessary required functionality. Doesn't care if it is standard WP plugin (manually copied, though composer.json and wpackagist.org), custom coded plugins, or small scripts.

And that is point. Mu-plugins are not loaded in the same way as regular plugins and your script emulate that behavior. I think WP should know which plugins are active.

[jessuppi]

And that is point. Mu-plugins are not loaded in the same way as regular plugins and your script emulate that behavior. I think WP should know which plugins are active.

I'm not sure the majority of developers would agree with this, because even though Autoloader enables "normal" plugins to be loaded as MU plugins, it is not emulating normal plugins because the load order of WordPress means they still load "before" everyone else loads.

I guess the real question is: what is the point (and use cases) of the "active plugins" list that WordPress saves to the database? E.g.

• prevents plugins of the same namespaces to be activated
• allows other plugins, themes etc to be aware of what plugins are activated
• enables DevOps tools like WP-CLI to activate plugins
• etc

There are surely dozens of micro-cases. But ultimately I think all roads lead back to conflicts, since you can't activate or deactivate MU plugins, they are "always on" whenever present. So I think maybe the only common use case I can think of offhand is preventing users from accidentally installing certain plugins that are already installed as MU plugins, but this kinda comes down more to proper DevOps configuration of your environment (like using our Plugin Blacklist).

Plus, our Autoloader sort of depends on developers not making foolish decisions perhaps, like not installing WooCommerce as a MU plugin without safeguards, etc.

I don't know. I think maybe the best solution would be WP Core adding a separate option in the database to list "active MU plugins" or something. Even if we implemented something like that on our own, it would be pointless without a more universal awareness of such a feature.