Feature Request: Allow Plugin to Be Installed as a MU Plugin via Composer

[timnolte]

Terms

• I have read the guidelines for Contributing to Roots Projects
• This request is not a duplicate of an existing issue
• This is not a personal support request that should be posted on the Roots Discourse community

Summary

Instead of only being able to install the plugin as a MU Plugin manually it would be nice to be able to install it that was via Composer since the WordPress Composer installers allow for this. I have my own working example of doing this here: https://github.com/ndigitals/wp-local-media-proxy/blob/main/composer.json

Specifically adding

"type": "wordpress-muplugin",

and leveraging the boxuk/wp-muplugin-loader Composer package works. Though I believe you may have your own MU Plugin loader.

Motivation

Why are we doing this?

Allow for installing as a MU Plugin but also keep it managed as a package dependence so that Composer sites can still update the package.

What use cases does it support?

There is an aspect where this package breaks PHPStan checks when used along with WordPress stubs. This is due to this package conflicting with Core functions and autoloading. However, the additional use case is to also be able to clearly see when review the Site Health tools in the Dashboard that this MU Plugin is actually running on the site. With the current Composer installation it's hidden and not obvious to general site support.

What is the expected outcome?

This can be installed as a MU Plugin and loaded, doesn't conflict with PHPStan execution with WordPress Stubs, is accurately reflected in the WordPress Dashboard Site Health.

Potential conflicts / foreseeable issues

Which MU plugin autoloader to use it a question. There is a generally available Composer package that can be used but there also seems to be a non-Composer based one that Bedroock/Roots uses for it's own stuff. This doesn't work well for non-Bedrock sites.

Additional Context

No response

[QWp6t]

As an alternative approach, you can specify a different installer-paths for this package.

To borrow from Bedrock's composer.json

   "extra": {
     "installer-paths": {
-      "web/app/mu-plugins/{$name}/": ["type:wordpress-muplugin"],
+      "web/app/mu-plugins/{$name}/": ["type:wordpress-muplugin", "roots/wp-password-bcrypt"],
       "web/app/plugins/{$name}/": ["type:wordpress-plugin"],
       "web/app/themes/{$name}/": ["type:wordpress-theme"]
     },
     "wordpress-install-dir": "web/wp"
   },

No idea if that approach will work with boxuk/wp-muplugin-loader, but you can feel free to give it a whirl and let us know.

[montchr]

There is an aspect where this package breaks PHPStan checks when used along with WordPress stubs. This is due to this package conflicting with Core functions and autoloading.

As an alternative approach, you can specify a different installer-paths for this package.

@QWp6t Unfortunately, adding the package identifier to the list of mu-plugins in composer.json does not seem to fix the conflict with phpstan+php-stubs/wordpress-stubs.

See szepeviktor/phpstan-wordpress#41 for more context.

[oxyc]

@QWp6t two issues:

1. Seems you can no longer change the paths for library package types. Even composer-installers-extneder doesn't work at the moment Package type "library" is not supported oomphinc/composer-installers-extender#26
2. The autoload composer.json property would also need to be removed or else the package gets required during the vendor autoload process.

To fix this particular case I'll just use a fork with these changes applied generoi@0903a48