Add wp plugin download command

[wojsmol]

Related wp-cli/scaffold-command#29 (comment)
This would be useful in deploy scripts. Descrption of my use case https://wordpress.slack.com/archives/C02RP4T41/p1500414057593480

[danielbachhuber]

Thanks for the suggestion, @wojsmol.

The wp plugin * commands require a working WordPress install, because they use WordPress APIs under the hood.

How would wp plugin download be different than using wget?

[wojsmol]

This command would be a little easier than wget or curl because the user would not have to specify the address from which to download the plugin by interacting with the wordpress.org api.

[drzraf]

adding my voice here.

In deployment scripts you may want to construct a ready-to-use wordpress image (docker/whatever) already containing the plugins (although the database is not initialized yet).

Using wp download or wp install --download-only would avoid doing by hand the complex processing that PluginCommand::install() does.

I think it's a "blocker", and the issue is moot, diging further:

• wp-cli must allow ignoring wp-config.php and not attempting a database-connection (is it already the case?)

• Snce download is going to be a subcommand or even an option of the plugin command, WordPress bootstrap should be made optional based on a subcommand/option value (is it the case?)

• Does WP bootstrap happens before or after defining wp-cli commands?

• A) WP-core dependent: install_from_repo(): install_plugin_install_status()

• B) WP-core dependent: install_from_repo(): plugins_api()

• A) can be solved easily because if download-only there is no need to check current status

• B) plugins_api() comes from wp-admin/includes/plugin-install.php. It should be possible to load this file since that's what update.php does (still, it requires wp-load.php anyway).
  So far it uses wp_remote_* and related HTTP functions + apply_filters() which is DB-independant and defined inside wp-includes/plugin.php

[danielbachhuber]

Downloading a plugin without a functioning WordPress install is best suited for a bash script or similar.

WP-CLI currently runs commands in one of two places: before_wp_load or after WordPress has loaded. Because the plugins directory path can be changed by a constant in wp-config.php, WP-CLI can't know the true plugin directory path until WordPress has loaded.

[drzraf]

`drush make` which shares a similar purpose started it's life a drush plugin, ending up in drush core then. I do understand that this requires unusual bootstrapping and that few commands would need it (`wp plugin patch` is the only other one I can this about) Still, IMO having a DB-less way to semi-bootstrap WP (= load basic wp-config.php parameter and WP functions) would be the best way to solve the issue since wp-cli+WordPress already provide 95% of what is needed of a feature that would be used in 99% in conjunction to wp-cli. (and it's actually a WordPress-related Cli-Command). It'd be painful and cumbersome to implement in a separate/external shell-script that would have to rely on PHP anyway to manually load wp-config.php separately, copying big chunks of wp-cli about download URL, path substitutions of github/gitlab URL, ...

[drzraf]

before_wp_load, command can't know the plugins directory path can be changed by a constant in wp-config.php

Ok, but a shellscripts wouldn't know it either. (It's not a strong reason for not doing that within wp-cli)

Moreover we almost do have a way to load wp-config.php's values, from PHP by define('SHORTINIT') before require('wp-config.php'); but there is indeed a core issue that this attempt a DB-connexion anyway (wp_set_wpdb_vars()) without any possibility to hijack the behavior (dead_db(), ...)
Don't you think we should rather open a core-ticket about this rather than closing a (possibily legitimate and useful) feature-request.

Building ready-to-use, continous-integration friendly WP (Docker&co) images, without having to deal with yet-another-script-tool, is and will be a increasing need when it come to plugin/theme quality/testing ir even continuous-deployment.
I think we definitely want to provision our (DB-less) WP images with
$ wp plugin download pluginX pluginY

[edit] did it: https://core.trac.wordpress.org/ticket/41783

[andrewmclagan]

I agree, seems the ops have no regard for immutable Docker workflows and thus will ignore the request. This is a modern toolset that many people have migrated to.

Think about this use-case:

1. Docker installs wp-cli
2. wp-cli installs wordpress
3. plugins
4. theme
5. Docker clears wp-cli and creates a new Image by copying all the installed files

Boom you have an immutable workflow to create a custom wordpress installation.

[Tawmu]

We're currently using composer to manage our WordPress Docker images which is less than ideal when you're managing ~40 sites and two environments for each (staging/prod) as a small team.

It's a real shame that every issue and PR I've seen in wp-cli (going back to 2013!) that would make it the tool of choice in these environments has been outright rejected with little discussion. Certainly in enterprise and large businesses immutable infrastructure is the way things are going and as it stands WordPress is incredibly hard to manage in these environments.

[schlessera]

I'll reopen this, as I plan to look into it. It will work differently than wp plugin install, but I do see the value in abstracting away the routing and the error handling.