Installing/updating plugins via URL that don't have .zip in filename

[coreyworrell]

Seems to be an issue where wp-cli won't install or update a plugin via URL when using a "dynamic" URL that doesn't look like a .zip file URL, ie: http://site.com/download.php?file=blah&key=whatever

[szepeviktor]

Try to use quotes on the command line

wp plugin install "http://site.com/download.php?file=blah&key=whatever"

[coreyworrell]

@szepeviktor that doesn't help, wp-cli is looking for a filename that ends in .zip only, to differentiate between a slug and a local/remote zip file.

[danielbachhuber]

Here's the check: https://github.com/wp-cli/wp-cli/blob/master/php/WP_CLI/CommandWithUpgrade.php#L126

@coreyworrell When you make a HEAD request against the URL, does it return the proper content disposition headers? This is an alternative we could consider.

local ➜  wordpress-test.dev git:(master) http HEAD https://downloads.wordpress.org/plugin/rest-api.2.0-beta5.zip
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-control: private
Connection: keep-alive
Content-Disposition: attachment; filename=rest-api.2.0-beta5.zip
Content-Length: 136651
Content-Type: application/zip
Date: Sun, 25 Oct 2015 16:50:48 GMT
Last-Modified: Fri, 23 Oct 2015 15:27:51 GMT
Server: nginx

Also, as a short-term workaround, you can download the file using wget or curl, and then install.

[coreyworrell]

@danielbachhuber yes, the headers are set just like that example. If you want to save a HEAD request though, you could simply check for a / in the argument, that would mean it can't be a plugin slug, and then check for :// to determine if it's a local or relative path (to specify a local path in the current working directory, one would have to prefix it with ./ which is a common practice anyways).

[coreyworrell]

I would say that you could also just set a flag that explicitly states that the argument you're passing is a remote url, but that won't help much when doing wp plugin update --all, since the arguments are coming from WP itself.

[danielbachhuber]

If you want to save a HEAD request though, you could simply check for a / in the argument

But you can also install a zip file from the same directory wp plugin install myplugin.zip

WP-CLI already accommodates zip archives behind access keys (e.g. http://site.com/archive.zip?file=blah&key=whatever). I'm not really convinced it should support downloading arbitrary URLs, and hoping they're zip archives. I think it's a reasonable assumption to inspect the extension.

As I mentioned before, you can use wget to download the file for your specific use case:

wget -o plugin.zip http://site.com/download.php?file=blah&key=whatever
wp plugin install plugin.zip

[coreyworrell]

I'm not really convinced it should support downloading arbitrary URLs, and hoping they're zip archives. I think it's a reasonable assumption to inspect the extension.

You're excluding many external/commercial plugins with this though. And yes the workaround works manually, but when doing wp plugin update --all that plugin (like ACF Pro and many others) will always fail the update and require a manual wget and all. Updating WP-cli is much easier/better than convincing many plugin authors to change their perfectly valid URL structures.

Instead of checking for / you could check for a . (period) instead. That will determine if it's a slug vs a url/path. None of the 1000s of WP plugins (https://plugins.svn.wordpress.org) have a period in their slug, and looks as if WP prevents that.

[danielbachhuber]

And yes the workaround works manually, but when doing wp plugin update --all that plugin (like ACF Pro and many others) will always fail the update and require a manual wget and all.

Ah, I didn't realize this caused premium plugin updates to fail.

Instead of checking for / you could check for a . (period) instead. That will determine if it's a slug vs a url/path.

This is an imprecise check. We'll need to do a HEAD request on the URL, which I think is more precise than checking the extension because it also checks whether the remote asset is available.

[coreyworrell]

I agree. But it doesn't have to be wp-cli's responsibility too check if a resource is available before attempting a download. One more idea could be to check if the passed string contains https?:// (or even just :// to allow other protocols), if it does then it's a URL to a .zip file (if it leads somewhere else then someone else messed up, not wp-cli), if not then it is a local file path or a plugin slug, which you can just test via is_file. Saves a request and is pretty bullet-proof.

[coreyworrell]

@danielbachhuber any update on when this will be handled? I can submit pull request if needed. Thanks.

[danielbachhuber]

any update on when this will be handled?

Nope.

I can submit pull request if needed. Thanks.

Please do! Here's our contributing directions: https://github.com/wp-cli/wp-cli/blob/master/CONTRIBUTING.md