Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wp core verify-checksums fails for en_GB locale #2286

Closed
rklrkl opened this issue Dec 10, 2015 · 4 comments

Comments

2 participants
@rklrkl
Copy link

commented Dec 10, 2015

I have WP 4.3.1 (yes, will be upgrading to 4.4 shortly) and WP-CLI 0.21.1 installed on an en_GB locale WordPress system. wp-includes/version.php therefore has a different checksum from, say, the en_US locale because of the additional line at the end of the file:

$wp_local_package = 'en_GB';

However, if I then run this command from the Web tree root:

wp core verify-checksums

then I get this output:

Warning: File doesn't verify against checksum: wp-includes/version.php
Error: WordPress install doesn't verify against checksums.

I've md5sum'ed wp-includes/version.php and compared it with the md5 checksum here:

http://api.wordpress.org/core/checksums/1.0/?version=4.3.1&locale=en_GB

and it matches correctly, so wp-includes/version.php hasn't been modified.
If I then run the same command, but using the 0.20.1 wp binary, I get this:

Success: WordPress install verifies against checksums.

My suspicion is that WP_CLI 0.21.1 isn't checksumming non-en_US locales correctly.

@danielbachhuber

This comment has been minimized.

Copy link
Member

commented Dec 10, 2015

You need to supply the locale:

wp core verify-checksums --locale=en_GB

@rklrkl

This comment has been minimized.

Copy link
Author

commented Dec 10, 2015

My assumption here is that the old WP_CLI version correctly used $wp_local_package to determine the locale (falling back to en_US if it isn't set in wp-includes/version.php) whereas the latest WP_CLI just defaults to en_US only unless --locale is supplied.

This seems a downgrade in functionality because I'm now going to have to scan wp-includes/version.php myself to see if $wp_local_package is set and then supply --locale with the locale value if it is - a lot more work for the end user, IMHO. I suspect most users would expect the locale to default to the WordPress locale if --locale isn't supplied, so this is quite unexpected behaviour in the latest WP-CLI for anyone not in the en_US locale. The fact that an older WP_CLI did it correctly is also quite frustrating.

@danielbachhuber

This comment has been minimized.

Copy link
Member

commented Dec 10, 2015

Sorry, my bad. Serves me to reply to Github issues on my phone :)

There's a bug in that we're checking the $wp_local_package global before it actually gets defined: https://github.com/wp-cli/wp-cli/blob/master/php/commands/core.php#L797-L807

I'll get this fixed, and then you can use wp cli update --nightly to update to the nightly release (after the build passes on the merge).

@danielbachhuber

This comment has been minimized.

Copy link
Member

commented Dec 10, 2015

For historical reference, this was actually broken by #2120

jghazally added a commit to jghazally/wp-cli that referenced this issue Feb 23, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.