Open ollietreend opened 8 years ago
👍
👍
👍
👍
There's only one "major" issue with just changing the installer-paths (by workaround, or when adding a custom type), which is that mu-plugins won't be loaded from directories.
To make it work it also requires a plain PHP file which includes the main plugin file.
eg. I have w3-total-cache installed in the mu-plugins folder, but I had to manually add a PHP:
<?php
include 'w3-total-cache/w3-total-cache.php';
This means that composer needs to figure out which file contains the plugin data (eg. Plugin Name), and then include that into a newly generated file.
👍
There's only one "major" issue with just changing the installer-paths (by workaround, or when adding a custom type), which is that mu-plugins won't be loaded from directories.
To make it work it also requires a plain PHP file which includes the main plugin file.
eg. I have w3-total-cache installed in the mu-plugins folder, but I had to manually add a PHP:
<?php include 'w3-total-cache/w3-total-cache.php';
This means that composer needs to figure out which file contains the plugin data (eg. Plugin Name), and then include that into a newly generated file.
This sounds quite difficult! I am open to reviewing a PR that does this but don't expect it to be something Outlandish can prioritise any time soon without some external help.
I think the include
problem should be addressed separately.
There is still a use case for forcing a plugin to be a mu-plugin when installing it. This allows you to type composer require wpackagist-mu-plugin/foo
and it will be installed into the correct mu-plugins directory without you first having to add its composer-installers path to composer.json. This would be really useful because I'm sure, like me, plenty of people type composer install wpackagist-plugin/foo
and then facepalm that it gets placed into the plugins directory but you actually want it as a mu-plugin.
It would be great if we could have a
wpackagist-mu-plugin
package namespace to serve WordPress plugins with atype
ofwordpress-muplugin
instead of the usualwordpress-plugin
.I understand that the current workaround to force wpackagist plugins to be mu is to adjust the
installer-paths
configuration to include the name of your package.I'm working on a custom plugin which I intend to include on my WordPress site with composer. However, my WordPress plugin has dependencies on other WordPress plugins. I have declared these dependencies in my plugin's
composer.json
file, however I'm unable to force the root composer project (i.e. the WordPress website itself) to install these plugins as mu-plugins.Here's my
composer.json
file:It seems that the
composer/installers
package and related configuration has no effect in this package.composer/installers
is configed from the root package, which makes sense because there's where the installing is done.Currently I need to add the required plugins to the root package's
installer-paths
configuration in order to force them to be mu-plugins. This means my root package needs to be aware of the nested dependencies of packages that its pulling in – which is messy, and will quickly become unmanageable.I suggest an alternative. It would make more sense to have a new namespace
wpackagist-mu-plugin
which mirrors the normalwpackagist-plugin
namespace, with the only difference being that the packages have atype
ofwordpress-muplugin
.That way we'll be able to specify that a plugin is mu in the very place that we define it as a requirement. Not only will it solve my problem, but it'll make everybody's
composer.json
files DRYer since there will be no need to add package names to theinstaller-paths
configuration.Example
composer.json
fileInclude
limit-login-attempts
as a normal plugin:Or as a mu-plugin:
Would this be possible?