Complete section command for MU-plugins

[daviddegliame]

Hi all, here my suggestion :

For now, the process to get mu-plugins is to 'wget' or 'curl' it. This won't benefit avantage of wp-cli abilities ( like using caching file for bulk proccess, for exemple ) An other way is to use the 'wp plugin' command with url of zip file and terminate by 'cp' or 'mv' to mu-plugins directory.

The aim is to work with Mu-plugin like do 'wp plugin' and 'wp theme'. I think it can join with : https://github.com/wp-cli/ideas/issues/12

with a new few commands to, It would help this process :

• wp mu-plugin path {plugin}
• wp mu-plugin list
• wp mu-plugin get {plugin}
• wp mu-plugin install {plugin}
• wp mu-plugin update {plugin} {version}
• wp mu-plugin delete {plugin} and so on …

[danielbachhuber]

Thanks for the suggestion, @daviddegliame.

Could you describe how you use mu plugins with a bit more detail?

For the record, here are some prior threads on this topic:

• https://github.com/wp-cli/wp-cli/issues/1341#issuecomment-54723711
• https://github.com/wp-cli/wp-cli/issues/1482#issuecomment-62742032
• https://github.com/wp-cli/wp-cli/issues/36
• https://github.com/wp-cli/wp-cli/issues/2

[entr]

For the folks that are used to Bedrock and their bedrock-autoloader this makes perfect sense but core sees mu-plugins as single php files that are directly found in WP_CONTENT_DIR . '/mu-plugins'. Not sure how a CLI commands are useful for these except for list and probably some weird install that sanitizes and handles single files only.

On the other hand wp mu-plugin path {plugin} that symlinks plugin index php from plugins to mu-plugins dir is interesting if possible. It will break the concept of mu-plugins though. Users will still be able to manage them unless DISALLOW_FILE_MODS is set to true.

[dotancohen]

I cannot speak for the OP, but I use MU plugins for plugins that are essential to site operation, and for which major functionality would suffer if they were disabled by accident. A good example is Advanced Custom Fields, which I only use for the Admin features but I would still have to field a support call if it were accidentally disabled.

I would still like to be able to update ACF (and other MU plugins) in a comfortable fashion with WP CLI, even though this feature is (rightly) absent from the WP Admin interface.

[daviddegliame]

For my first message, the main idea was to keep wp-cli process and avoid uses other bash command. that seem more cleaner code.

The second idea was to be able to use internal cache. On some server, i was bloqued when i try to get some files ( likes 403 on github repos ). and i think it good practice to avoid external request when it possible to get a local one.

Maybe the most difficult part is to deal with updates, because, each ones process probably aren't sames. So there can be "first try" without update command.

[danielbachhuber]

Few connected thoughts here:

1. To integrate more natively with the WordPress plugin update process, I think it makes more sense to install plugins to wp-content/plugins and then use some stub file in wp-content/mu-plugins to make sure certain plugins are always loaded.
2. Mu-plugins can be listed with wp plugin list --status=must-use.
3. Generally, WP-CLI shouldn't depart too far from WordPress core's plugin user experience. For instance, WP-CLI wouldn't implement a wp mu-plugin update before WordPress core offered the corresponding APIs.

If you installed mu-plugins with point 1, then you'd get pretty much everything else for free.