wp plugin update does not respect minimum PHP requirements

[Sidsector9]

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

Props to @dkotter for reporting this internally.

Currently, the CLI allows you to update a plugin even when minimum PHP requirements are not met.
This behaviour is inconsistent with WordPress's UI.

Describe how other contributors can replicate this bug

1. Set up a WordPress environment on PHP 7.3.5
2. Install this plugin for example: wp plugin install restricted-site-access (The latest version requires PHP 7.4+). The installation fails as expected.
3. Now run wp plugin install restricted-site-access --version=7.3.0 (This plugin is compatible with PHP 7.3.5), plugin installs successfully as expected.
4. Now run wp plugin update restricted-site-access. It updates to the latest version even when the latest plugin version is incompatible with PHP 7.3.5

Describe what you would expect as the correct outcome

I expect the command to throw an error when trying to update a plugin that doesn't meet the minimum PHP requirements.

Let us know what environment you are running this on

OS:	Darwin 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:22 PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 x86_64
Shell:	/bin/zsh
PHP binary:	/Users/siddharth/Library/Application Support/Local/lightning-services/php-7.3.5+11/bin/darwin/bin/php
PHP version:	7.3.5
php.ini used:	/Users/siddharth/Library/Application Support/Local/run/2O8zTOdwT/conf/php/php.ini
MySQL binary:	/Applications/Local.app/Contents/Resources/extraResources/lightning-services/mysql-8.0.16+6/bin/darwin/bin/mysql
MySQL version:	mysql  Ver 8.0.16 for macos10.14 on x86_64 (MySQL Community Server - GPL)
SQL modes:	ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/Users/siddharth/Sites/clitest/app/public
WP-CLI packages dir:	
WP-CLI cache dir:	/Users/siddharth/.wp-cli/cache
WP-CLI global config:	/Applications/Local.app/Contents/Resources/extraResources/bin/wp-cli/config.yaml
WP-CLI project config:	
WP-CLI version:	2.7.1

[toddr]

I think this is working as expected now. Did core update?

$>php -v; wp plugin install restricted-site-access 
PHP 7.0.33 (cli) (built: Mar 23 2023 16:42:18) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies

Installing Restricted Site Access (7.4.0)
Downloading installation package from https://downloads.wordpress.org/plugin/restricted-site-access.7.4.0.zip...
Using cached file '/home/cli/.wp-cli/cache/plugin/restricted-site-access-7.4.0.zip'...
Unpacking the package...
Installing the plugin...
Warning: The package could not be installed. "The PHP version on your server is 7.0.33, however the uploaded plugin requires 7.4."
Plugin installation failed.
Warning: The 'restricted-site-access' plugin could not be found.
Error: No plugins installed.

[salcode]

@toddr I seem to still be seeing the behavior reported in this issue.

I was able to update restricted-site-access to version 7.4.0 even though I'm on PHP 7.3.5 (and I'm using WP-CLI 2.9.0-alpha). 🤔

$ php -v
PHP 7.3.5 (cli) (built: Jul 24 2020 21:39:21) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.5, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.5, Copyright (c) 1999-2018, by Zend Technologies

$ wp --version  
WP-CLI 2.9.0-alpha

$ wp plugin list
+------------------------+----------+-----------+---------+
| name                   | status   | update    | version |
+------------------------+----------+-----------+---------+
| restricted-site-access | inactive | available | 7.3.0   |
+------------------------+----------+-----------+---------+

$ wp plugin update restricted-site-access                
Downloading update from https://downloads.wordpress.org/plugin/restricted-site-access.7.4.0.zip...
Using cached file '/Users/sal/.wp-cli/cache/plugin/restricted-site-access-7.4.0.zip'...
Unpacking the update...
Installing the latest version...
Removing the old version of the plugin...
Plugin updated successfully.
+------------------------+-------------+-------------+---------+
| name                   | old_version | new_version | status  |
+------------------------+-------------+-------------+---------+
| restricted-site-access | 7.3.0       | 7.4.0       | Updated |
+------------------------+-------------+-------------+---------+
Success: Updated 1 of 1 plugins.

[salcode]

Interestingly, running

wp plugin update restricted-site-access --version=7.4.0

fails (which is the proper behavior)

$ wp plugin update restricted-site-access --version=7.4.0
Installing Restricted Site Access (7.4.0)
Downloading installation package from https://downloads.wordpress.org/plugin/restricted-site-access.7.4.0.zip...
Using cached file '/Users/sal/.wp-cli/cache/plugin/restricted-site-access-7.4.0.zip'...
Unpacking the package...
Installing the plugin...
Warning: The package could not be installed. "The PHP version on your server is 7.3.5, however the uploaded plugin requires 7.4."
Plugin update failed.
Error: No plugins installed.

but running

wp plugin update restricted-site-access

works (which is the improper behavior).

$ wp plugin update restricted-site-access
Downloading update from https://downloads.wordpress.org/plugin/restricted-site-access.7.4.0.zip...
Using cached file '/Users/sal/.wp-cli/cache/plugin/restricted-site-access-7.4.0.zip'...
Unpacking the update...
Installing the latest version...
Removing the old version of the plugin...
Plugin updated successfully.
+------------------------+-------------+-------------+---------+
| name | old_version | new_version | status |
+------------------------+-------------+-------------+---------+
| restricted-site-access | 7.3.0 | 7.4.0 | Updated |
+------------------------+-------------+-------------+---------+
Success: Updated 1 of 1 plugins.

It looks like the wrong behavior occurs when WordPress core's Plugin_Upgrader::bulk_upgrade() is called.

It appears this is a core issue and I've opened a trac ticket (Trac Ticket 59198)

[danielbachhuber]

This is fixed in WordPress trunk, and may be backported to earlier versions of WordPress: https://core.trac.wordpress.org/ticket/59198#comment:22