Repository navigation
Add wp plugin download command #26
Description
Activity
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 downloadbe different than usingwget?This command would be a little easier than
wgetorcurlbecause the user would not have to specify the address from which to download the plugin by interacting with the wordpress.org api.Reacted by Omeid Matten, Justin Lipkin, RomanCherednikov and Jesus Iniestaadding 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 downloadorwp install --download-onlywould 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-climust allow ignoring wp-config.php and not attempting a database-connection (is it already the case?) -
Snce
downloadis going to be a subcommand or even an option of theplugincommand, 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-onlythere 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 requireswp-load.phpanyway).
So far it useswp_remote_*and related HTTP functions +apply_filters()which is DB-independant and defined insidewp-includes/plugin.php
Reacted by xwiz, Aleksander Prikhozhdenko and RomanCherednikov-
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_loador after WordPress has loaded. Because the plugins directory path can be changed by a constant inwp-config.php, WP-CLI can't know the true plugin directory path until WordPress has loaded.Reacted by Aaron JorbinReacted by (Rew) Andrew McLagan, Tawmu, Omeid Matten, Pedro de Carvalho, Gustavo Valverde, xwiz, Aleksandar Puharic and RomanCherednikov- `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, ...
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 bydefine('SHORTINIT')beforerequire('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
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:
- Docker installs wp-cli
- wp-cli installs wordpress
- plugins
- theme
- 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.
Reacted by Omeid Matten, Phil Fenstermacher, Anthony Lhériau, Tawmu, xwiz, Aleksander Prikhozhdenko, Aleksandar Puharic and Samuel GrantWe'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.
Reacted by Daniel Kudwien and Aleksander PrikhozhdenkoI'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.Reacted by Robin Moser, BreezeMaxWeb-NS, Taras, BenV, Joe, Joshua Schmidtke, Wojciech Smoliński, Daniel Kudwien, xwiz, Aleksander Prikhozhdenko and 3 moreHi @schlessera just wondering if there were any updates on this command?
Reacted by José Victor Catalani, Oleg Tsymbal, Justin Lipkin, xwiz, Aleksandar Puharic, Samuel Grant and Jesus IniestaI would like to add that downloading languages for plugins and core would be great as well for bootstrapping a docker image
Hey! Any update on this command being implemented?
I've been upgrading our system to use WP CLI and have hit a brick wall. The build process we have goes via an online service that has multiple IPs that it uses.
This means that we can't whitelist it (easily, could proxy, not ideal) for MYSQL and can't connect to a staging DB to install plugins, non of our plugins need a DB connection for actual installation, we just need the zipped files to be downloaded via CLI.
Just for information: @tomas-mazak created a PoC for immutable wordpress docker containers.
Downloading a plugin without a functioning WordPress install is best suited for a bash script or similar.
His wp-install.sh is doing exactly that. With the plugin directory hardcoded.
I still see value in having this officially supported by the wp-cli (including languages).
Any news on this improvement?
I will use this to update a dockerized wordpress which needs to be updated within a git repository.
Currently I use wpcli to get the plugins with a pending update, I ask wordpress API to get the url of the zip and I download it within a wget.
The problem it's there are plugins outside the official wordpress repository which are downloaded from the developer's site within a GET parameter with the license or whatever value they check to see if your license it's up to date.
With a wpcli download command I will issue it to download the updated zip of a plugin using the Wordpress core set on the path parameter of wpcli. It should work because if I update the plugin within the wordpress site it works perfectly.
Regards,
The problem it's there are plugins outside the official wordpress repository which are downloaded from the developer's site within a GET parameter with the license or whatever value they check to see if your license it's up to date.
With a wpcli download command I will issue it to download the updated zip of a plugin using the Wordpress core set on the path parameter of wpcli. It should work because if I update the plugin within the wordpress site it works perfectly.
So on an active WordPress installation you want to be able to download the new ZIP of that third-party plugin without actually updating the plugin? Perhaps we could solve that with
wp plugin update --download-onlyor so. After all, the suggestion here is for awp plugin downloadplugin that does not require an active WordPress installation.- linked a pull request that will close this issueAdd `plugin/theme download` subcommands runnable before WordPress load #527
on May 27, 2026
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