wp-cli: wp core download gives "unable to decompress gzipped phar archive" error

Thanks everyone who spent time tracking this down. Given this isn’t an issue with WP-CLI itself but with specific PHP distros, I think we’ve fixed it the best we can.

We’ll publish WP-CLI v1.4.0 on Tuesday, October 17th. For now, those affected can use wp cli update --nightly.

If I use arg --version it works wp --allow-root core download --version=“4.8.1”

I tracked down the guilty party to here https://github.com/php/php-src/blob/master/ext/zlib/zlib_filter.c#L124 in the zlib_filter where it returns without updating the bytes_consumed variable, as if a .tar.gz is 1 to about 10 bytes over modulo 8192 then no output might be needed (the last 4 bytes are just a checksum anyway) but the bytes have been consumed, and not reporting them as such causes the calling function to error.

As mentioned above this is only triggered for files > 4MB on distributions with the Debian patch but even so it’s surprising it hasn’t been noticed before.

@miya0001 Great, now it works …

Going with a workaround for the time being: https://github.com/wp-cli/wp-cli/pull/4371

If someone wants to try, here’s a Phar build: https://www.dropbox.com/s/taeh1mak9fvmlu6/wp-cli-nightly.phar?dl=0

The problem seems to be specific to gzip, not tar.

ubuntu@controller-us-east-1:/tmp/f$ php -r '$f=new PharData( "wp_59c3ce5c83746.tar.gz" );$f->extractTo("/tmp/wordpress");'
PHP Fatal error:  Uncaught exception 'UnexpectedValueException' with message 'unable to decompress gzipped phar archive "/tmp/f/wp_59c3ce5c83746.tar.gz" to temporary file' in Command line code:1
Stack trace:
#0 Command line code(1): PharData->__construct('wp_59c3ce5c8374...')
#1 {main}
  thrown in Command line code on line 1
ubuntu@controller-us-east-1:/tmp/f$ gunzip wp_59c3ce5c83746.tar.gz 
ubuntu@controller-us-east-1:/tmp/f$ php -r '$f=new PharData( "wp_59c3ce5c83746.tar" );$f->extractTo("/tmp/wordpress");'
ubuntu@controller-us-east-1:/tmp/f$ ls -al /tmp/wordpress/
total 80
drwxrwxr-x    3 ubuntu ubuntu  4096 Sep 21 14:55 .
drwxrwxrwt 2593 root   root   69632 Sep 21 14:55 ..
drwxrwxr-x    5 ubuntu ubuntu  4096 Sep 21 14:55 wordpress
ubuntu@controller-us-east-1:/tmp/f$ 

I’ve also created a meta issue for this: https://meta.trac.wordpress.org/ticket/3150

This will work

wp --allow-root core download --locale=sv_SE

The problem is with US files …

@gitlost sorry not to have replied sooner. the server is running PHP7.0 from Debian Stretch:

php --version
PHP 7.0.19-1 (cli) (built: May 11 2017 14:04:47) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.19-1, Copyright (c) 1999-2017, by Zend Technologies

@ZeroX66

Hm, It’s still some trouble with it. I change to this and it works with “nightly”.

Nightly is the only way to have the fix. There hasn’t been a release yet.

Hm, It’s still some trouble with it. I change to this and it works with “nightly”.

wp cli update --nightly

Is there any ETA for a new stable release or should I use the nightly version in my Travis builds for now

Not yet scheduled. You should use the nightly build.

@ZeroX66 Nightly build is working for now. 😃 https://make.wordpress.org/cli/handbook/installing/#installing-nightly-via-phar

@danielbachhuber I do not have a better idea than opening a ticket on the right tracker and request to re-create the archive.

Could it be some issue with the WP archive? wp core download --version=4.8.1 --force succeeds. wp core download --version=4.8.2 --force fails.

My hunch is that the WordPress US build is corrupt in some way.

I have an idea for a solution.

We could do a try {} catch () block within the \WP_CLI\Extractor::extract_tarball() method. We could try the PharData class first, but if it throws an exception we could fall back to using a command line exec to do the extraction. If that still fails, then throw an exception and let it bubble back up to the existing block.

@wojsmol

on enviramant with error plese check if zlib php extesion is enabled

That’s a good thought, but it appears that zlib is enabled:

php -i | grep zlib
Registered PHP Streams => https, ftps, compress.zlib, php, file, glob, data, http, ftp, phar, ssh2.shell, ssh2.exec, ssh2.tunnel, ssh2.scp, ssh2.sftp, zip
Registered Stream Filters => zlib.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, convert.iconv.*, mcrypt.*, mdecrypt.*
zlib
Stream Wrapper => compress.zlib://
Stream Filter => zlib.inflate, zlib.deflate
zlib.output_compression => Off => Off
zlib.output_compression_level => -1 => -1
zlib.output_handler => no value => no value

@ZeroX66

I think the problem might be the arguments in this line

tar xz --strip-components=1 --directory=%s -f $tarball

I don’t think that line is the problem. That line is only executed if the PharData class does not exist. The class does exist. The exception happens on $phar = new PharData( $tarball ); as was mentioned by @miya0001

So it seems that there’s some issue between the package and the PharData class. I’m not sure how to determine which of them is to blame.

on enviramant with error plese check if zlib php extesion is enabled reference https://github.com/composer/composer/issues/984

@ZeroX66 If you want to change default locale, you can set default locale to ~/.wp-cli/config.yml like following.

core download:
  locale: de_DE

@gitlost sure

PHP 7.1.9-1+ubuntu14.04.1+deb.sury.org+1 (cli) (built: Sep  2 2017 06:17:11) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.1.9-1+ubuntu14.04.1+deb.sury.org+1, Copyright (c) 1999-2017, by Zend Technologies

 PHP 7.0.21-1+ubuntu14.04.1+deb.sury.org+1 (cli) (built: Jul  6 2017 09:38:10) ( NTS )
 Copyright (c) 1997-2017 The PHP Group
 Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
     with Zend OPcache v7.0.21-1~ubuntu14.04.1+deb.sury.org+1, Copyright (c) 1999-2017, by Zend Technologies

 PHP 5.6.31-4+ubuntu14.04.1+deb.sury.org+4 (cli) 
 Copyright (c) 1997-2016 The PHP Group
 Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

Anyway i changed the locale to it_IT and now it works.

Yes, the problem is with the US package - at least the German one runs well with wp core download --locale=de_DE

The Swedish as well as @ZeroX66 wrote.