`plugin update` does not fail on bad file permissions

[emersonveenstra]

Running wp plugin update --all does not fail with bad file permissions:

emerson@orion-web-1:/var/www/sites/example.com $ wp plugin update --all
Enabling Maintenance mode...
Downloading update from https://downloads.wordpress.org/plugin/wordpress-seo.7.0.3.zip...
Using cached file '/home/emerson/.wp-cli/cache/plugin/wordpress-seo-7.0.3.zip'...
Unpacking the update...
Installing the latest version...
Removing the old version of the plugin...
Warning: The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.
[snipped many files]
Plugin update failed.
Disabling Maintenance mode...
+---------------+-------------+-------------+--------+
| name          | old_version | new_version | status |
+---------------+-------------+-------------+--------+
| wordpress-seo | 6.2         | 7.0.3       | Error  |
+---------------+-------------+-------------+--------+
Success: Plugin already updated.

For reference:

emerson@orion-web-1:/var/www/sites/example.com $ wp cli version
WP-CLI 1.5.0
emerson@orion-web-1:/var/www/sites/example.com $ php -v
PHP 7.2.1-1+ubuntu16.04.1+deb.sury.org+1

[jmichaelward]

It appears that there are two main issues here:

1. WP-CLI outputs a "Success" message when there are plugin failures. This is the case whether updating --all or updating a specific plugin, as in Incorrect success message when a plugin cannot be updated due to write permissions wp-cli#4929.
2. WP-CLI shows an actual new_version of a plugin when, in fact, the old version is still installed.

The function that outputs the result of the command is report_batch_operation_results on line 910 of ./php/utils.php of the WP-CLI framework. That method accepts a $failures parameter that is never set if the plugin updater runs into write permissions issues, so output skips to the else condition of that method, where there are also no successes, and thus, the message "Plugin already updated." is output.

To replicate this bug:

1. Make sure you have default file permissions set in WordPress
2. run wp plugin install jetpack --version=2.2.8 (or any non-current version)
3. Navigate to the plugins directory via the terminal and run chmod -w jetpack.
4. run wp plugin update jetpack. You will see output similar to to the above, and in the related ticket.

I propose that when this command is run and encounters permissions errors, that the new_version rendered for the plugin in the table should be the same as the old version, the "Error" status should remain, and instead of "Success: Plugin already updated." we should see "Error: Plugin update failed." Perhaps WP-CLI should also highlight any failed updates?

[kitchin]

Fixed issue wp-cli/wp-cli#3761 in the parent repo was similar. It was for installing a plugin, this one is for updating a plugin (or all plugins).

[schlessera]

Fixed via #143