Add wp plugin download command

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

@wojsmol

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?

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.

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

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.

`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 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

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.

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.

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.

@schlessera

Hi @schlessera just wondering if there were any updates on this command?

I 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.

@tomas-mazak

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-only or so. After all, the suggestion here is for a wp plugin download plugin that does not require an active WordPress installation.

Navigation Menu

Repository navigation

Add wp plugin download command #26

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add wp plugin download command #26

Description

Activity

danielbachhuber commented on Jul 24, 2017

wojsmol commented on Jul 24, 2017

drzraf commented on Aug 20, 2017

danielbachhuber commented on Aug 22, 2017

drzraf commented on Aug 22, 2017

drzraf commented on Sep 2, 2017

andrewmclagan commented on May 22, 2019

Tawmu commented on May 14, 2020

schlessera commented on May 15, 2020

BenMiller3 commented on Jan 20, 2021

jontro commented on May 5, 2021

ThePlayerSD commented on Aug 23, 2021

gerwinjansen commented on Jan 6, 2022

NetVicious commented on Mar 18, 2025

swissspidy commented on May 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions