Add vendor "wpackagist-mu-plugin" to force a plugin to have type "wordpress-muplugin" without having to adjust "installer-paths"

[ollietreend]

It would be great if we could have a wpackagist-mu-plugin package namespace to serve WordPress plugins with a type of wordpress-muplugin instead of the usual wordpress-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:

{
  "name": "my/package",
  "type": "wordpress-muplugin",
  "version": "1.0.0",
  "repositories": [
    {
      "type": "composer",
      "url": "http://wpackagist.org"
    }
  ],
  "require": {
    "php": ">=5.5",
    "composer/installers": "~1.0.12",
    "wpackagist-plugin/stop-user-enumeration": "*",
    "wpackagist-plugin/limit-login-attempts": "*"
  },
  "extra": {
    "installer-paths": {
      "web/app/mu-plugins/{$name}/": [
        "type:wordpress-muplugin",
        "wpackagist-plugin/stop-user-enumeration",
        "wpackagist-plugin/limit-login-attempts"
      ],
      "web/app/plugins/{$name}/": ["type:wordpress-plugin"],
      "web/app/themes/{$name}/": ["type:wordpress-theme"]
    }
  }
}

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 normal wpackagist-plugin namespace, with the only difference being that the packages have a type of wordpress-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 the installer-paths configuration.

 Example composer.json file

Include limit-login-attempts as a normal plugin:

"require": {
  "wpackagist-plugin/limit-login-attempts": "*"
}

Or as a mu-plugin:

"require": {
  "wpackagist-mu-plugin/limit-login-attempts": "*"
}

Would this be possible?

[josephabrahams]

👍

[maiorano84]

👍

[istateside]

👍

[Grezvany13]

👍

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.

[NoelLH]

👍

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.

[johnbillion]

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.