Detection of plugins in a "mu-plugins" folder

[mcamprecios]

Thanks for this plugin guys, I'm testing it out and it may save many upcoming projects.

I have a potential issue, although may be my fault. I'm customizing a Wordpress starter based on Wordplate. It it git friendly and uses composer to install plugins, providing the option of using a mu-plugins folder for Must Use Plugins. All fine...

But, it seems that qTranslate doesn't scan that folder, therefore, it doesn't notice the existance of ACF, which is a plugin that does belong to this mu-plugins.

Apparently, the usage of this mu-plugins folder is extended. In Wordplate's case, it is in the same directory that plugins. So it may be an special folder structure. I've searched the filters that are apparently used to create a different structure but they don't seem to apply:

To change the default directory manually, define WPMU_PLUGIN_DIR and WPMU_PLUGIN_URL in wp-config.php.

Not sure if this belongs to a bug or it is my fault and I should forget about the mu-plugin folder.

Massive thanks!

[herrvigg]

We use mu-plugins but only to detect i18n JSON configuration files. For the rest we rely on WP hooks that tell when a plugin is activated or deactivated, triggering functions with the modules. But we don't handle modules related to mu-plugins. It can be seen as a bug (something expected) or a new feature (no one had that need until now it seems). I'll take a look into it.

[mcamprecios]

Thanks! I don't believe it fits into a bug category either. Let me know if you want me to do tests.

Just in case, this is my variation of Wordplate, that I could use for testing: https://gitlab.com/kram08980/wp-starter

[herrvigg]

The problem with mu-plugins is it's about custom installations. See get_mu_plugins. In principle it's a unique folder of plugin files. How would a plugin like ACF appear in that folder, is it mu_plugins/acf.php? But this is not an "official" WP install of the ACF plugin. So we can't really assume what the exact path is.

Also note a function like is_plugin_active returns false for a mu-plugin as this only looks into the plugins folder. Feels if we want to support mu-plugins we should detect the plugins according to a class or function and not a plugin file. It's not well standardized in WordPress, yet another design flaw.

[mcamprecios]

Thanks for giving it a look. I'm not into Wordpress core development, so I may be missing a bigger picture. There are two things that may be creative solutions;

• Allow users to manually activate a plugin on the Settings/Language page.
• Detect plugin installations checking if they created tables on the database. Although I guess that uninstalled plugins may leave some data there, and could be missleading. But since there are a few compatible plugins, may be a way of checking out.

For my specific case, I could just move the plugin from mu-plugins to the normal folder.

[herrvigg]

My main idea is to detect plugins from a given class or function that is "graded as API" instead of using the plugin files. At the same time, we need to update the state of the modules differently for the mu-plugins. It should not be huge changes but still this would require some tests. My plan is to create this new feature in a separate branch that you could test, then we integrate in next minor release.