gmazzap
commented
7 years ago WP Starter MU plugins handling is definetively something that needs improvements.
For version 3, I experimented a different approach (available in version-3 branch), but I'm not happy with it.
I like very much the idea of dealing with MU plugins at build time.
What I don't like is to have a "loader" for each installed plugin.
Since Composer was not even a thing a quite common practice that worked well was to have a single "loader" MU plugin that loaded all MU plugins in folders.
Usually such MU plugin used glob or the like to load MU plugins from subfolders of MU plugin folder, but WP Starter could benefit of build routine to have a static array to read file names from.
Something like:
<?php
/*
* Plugin Name: WP Starter MU plugin loader
*/
// Array of plugin files to load created by WP Starter at build time
$mu_plugin_files = array( ... );
array_walk($mu_plugin_files, function($file) {
wp_register_plugin_realpath($file);
include_once $file;
});Being a static array the loading would be fast and we would also benefit of opcache for even better performance.
Creating this MU pugin at build time from a template would be trivial, the trickiest part would be how to build the $mu_plugin_files array.
Just relying on the Composer type (that's what currently WP Starter does) has proven to be suboptimal and that was the reason I tried a different approach for version 3.
Since WP only allows single files as MU plugins, many developers, even ones inclined to use Composer in their plugins, just give up using folder (and include a composer.json in there) for MU plugins, because of the additional overhead to load them from folders.
The approach I took for what's in version-3 branch is:
1. if a composer.json is there, go to step 1a, otherwise go to step 2.
1a. If the type in composer.json is wordpress-muplugin go to step 1b. if the type in composer.json is wordpress-plugin go to step 1c. otherwise skip the folder.
1b. check for PHP files in the folder. If there's only one PHP file, assume it is the MU plugin file and queue it to be loaded. If there are more files, look for the file who has plugin file header (that's not mandatory for MU plugins) and if found queue it to be loaded. If both 2 previous attempt failed skip the folder.
1c. Being a regular plugin, plugin file header is mandatory, so look for the file who has plugin file header. If found, queue it to be loaded, otherwise skip the folder.
2. Scan the folder for a file who has plugin file header. If found, queue it to be loaded, otherwise skip the folder.
Using above workflow to build the $mu_plugin_files would allow to load from subfolder of MU plugin folder:
- MU plugins that natively support Composer
- MU plugins that does not natively support Composer
- Regular plugins that natively support Composer
- Regular plugins that does not natively support Composer
Since the (slow) directory scanning happen at build time, we don't affect website performace.
Supporting to load regular plugin as MU plugins allow for some intersting use cases, but also has some gotchas.
In fact, many plugins rely on "activated hook" to do stuff necessary for them to work. We could manage to trigger those hooks comparing the array of plugin being loaded with the activated plugins array in database, but that would not be 100% reliable.
The other alternatives would be:
- support regular plugin as MU plugin clearly stating in documentation that plugins that rely on activation/deactivation hook will not work
- give up supporting support regular plugin as MU plugin
dnaber-de
franz-josef-kaiser
WPStarter loads MU plugins in sub directories via the
WCM\WPStarter\MuLoader\MuLoaderthat acts on the actionmuplugins_loaded. This leads to a problem when a mu plugin registers itself an action listener tomuplugins_loaded. So instead of handling MU plugins on runtime, what about dealing with them on build-time?WPStarter could add an additional step that crawls the MU plugin main files and places a file for each directly to the MU plugins directory. This file just contains the plugin header and includes the original mu-plugin file in its sub directory.
Here's an example:
The WPStarter project requires the package
acme/acme-mu-pluginwhich is of typewordpress-muplugin. Composer installer moves the package towp-content/mu-plugins/acme-mu-plugin/. Now WPStarter creates awp-content/mu-plugins/acme-mu-plugin.phpwith the following content: