Bulk actions "Update" ignores Minimum PHP Version Requirement

[salcode]

Background

As described in the Plugin Handbook ​Header Fields, a plugin can include the Requires PHP header which is

The minimum required PHP version.

WordPress prevents a user from installing a new plugin if the minimum required PHP version is not met and prevents updating a plugin to a newer version, if that newer version requires a PHP version higher than the server is running.

Bug

Using the Bulk actions Update action updates the plugin while ignoring the minimum PHP required version.

Reproduction Steps

WP CLI is useful in reproducing this issue.

I'm also using the plugin ​https://wordpress.org/plugins/spatie-ray, which requires at these specific versions, which have different PHP minimum requirements.

Plugin Version	PHP Minimum Version
1.4.0	7.3
1.7.4	8.0

1. On a WordPress 6.3 install running PHP 7.3 (or 7.4) with WP CLI setup
2. Run the following from the command line to install the plugin at a version compatible with PHP 7.3

   wp plugin install spatie-ray --version=1.4.0
   

3. Go to /wp-admin/plugins.php and you'll see a message indicating the plugin can not be updated

   There is a new version of Spatie Ray available, but it does not work with your version of PHP. View version 1.7.5 details or learn more about updating PHP.
   

4. Check the checkbox in front of the plugin name "Spatie Ray"
5. From the Bulk actions select box, choose Update
6. Click the Apply button next to the Bulk actions select box

Expected Behavior

The plugin fails to update because the minimum PHP version requirement is not met.

Actual Behavior

The plugin successfully updates.

Notes

This issue was originally raised as a ​WP CLI issue, but the root cause appears to be here in WordPress core.

[salcode]

The WordPress UI indicating a plugin can not be installed due to the PHP minimum version requirement.

[salcode]

The WordPress UI indicating a plugin can not be updated due to the PHP minimum version requirement.

[salcode]

Choosing the WordPress plugin bulk update option.

[salcode]

Successful update of the plugin despite the minimum PHP version not being met.

Apply check_package() on bulk plugin update via the "upgrader_source_selection" filter.

This applies the same PHP minimum version checks
on bulk plugin update that are applied on a
single plugin update.

[afragen]

Probably best to apply a fix directly and not via a filter.

I’ll try for a closer look tomorrow. Good pick up.

[mukesh27]

Thanks @salcode for the ticket and PR.

The filter approach use in ​install method.

[afragen]

@salcode it would seem a similar patch is required for class-theme-upgrader.php too.

[afragen]

In digging into this I see a discrepancy between your images and what I see on an fresh local installation WP 6.3, PHP 7.4.30

[afragen]

Plugin row, WP 6.3, PHP 7.4.30

[afragen]

The checkbox is removed from ​https://github.com/WordPress/wordpress-develop/blob/7f38f687c4e45a2a28b214024c50cf145edeae0e/src/wp-admin/includes/class-wp-plugins-list-table.php#L992

Given this I'm not sure how you arrived at your situation with a checkbox present.

[salcode]

@afragen Thanks for looking at this and for the feedback.

I suspect you are seeing that screen because you were already on spatie-ray version 1.7.4 before changing your PHP version to 7.4.30.

So the version of the plugin you already have installed (1.7.4) already requires PHP 8.0, which your install does not meet, which causes

1. The first message "This plugin does not work with your version of PHP." and
2. disables the checkbox you called out in ​src/wp-admin/includes/class-wp-plugins-list-table.php on line 992*

If you run the following commands to delete the plugin and re-install it at a version that is compatible with PHP 7.4, you should be able to recreate the original issue for this ticket.

npm run env:cli -- wp plugin delete spatie-ray

npm run env:cli -- wp plugin install spatie-ray --version=1.4.0

*Note: It seems strange that the checkbox is disabled for updating the plugin based on the PHP version of the currently installed plugin (not the version available to update to). I suspect this may need its own ticket.

---

it would seem a similar patch is required for class-theme-upgrader.php too.

My vote would be to handle the fix in class-theme-upgrader.php as a separate ticket with a separate set of testing steps as validating this fix is tricky enough 😀.

[salcode]

Fatal error displayed after updating to a version of the plugin that requires PHP 8.0, while running PHP 7.3

[costdev]

I agree with @afragen that we should handle this directly rather than use a filter. ::install() covers paths that include local file installations, so a filter is more appropriate here.

However, using the filter in ::bulk_upgrade() means downloading and unpacking a package before finding out whether it's supported.

We should be able to save on time, diskspace, memory and cleanup operations like so:

• $r should already contain requires and requires_php properties.
  • Need to confirm whether these are always set, and whether there's a default value that should also be accounted for.
• We can pass these values to is_wp_version_compatible() and is_php_version_compatible() respectively.
• If either isn't compatible, we can set $result to a WP_Error object.

Pseudo:

if not compatible with WP
    result = new WP_Error about WP version
elseif not compatible with php
    result = new WP_Error about PHP version
else
    result = $this->run( ... )

---

Removing the php-compatibility focus as this pertains to Core's compatibility with PHP versions rather than Core's handling of plugins with PHP version constraints.

Note the description of the focus:

Relating to PHP forward and backwards compatibility. A phpNN keyword identifies the PHP version that introduced the incompatibility

Previously, bulk upgrades did not verify that a plugin package was compatible with the site's WordPress version or the server's PHP version. This could lead to incompatible updates being installed, causing various compatibility issues and errors.

This change implements the following checks:

• If available, the API response's requires and requires_php values are checked for compatibility. This saves time, diskspace, memory and file operations by failing the upgrade before the package is downloaded and unpacked.
• If the API check passes, the downloaded and unpacked package is verified using Plugin_Upgrader::check_package() to ensure a plugin file is present, and the plugin's "RequiresWP" and "RequiresPHP" headers are compatible, if present. This ensures that an API/Plugin headers mismatch does not cause an incompatible plugin to be installed.

Tested locally and works.

[costdev]

​PR 5116 implements both API response pre-checks as well as ::check_package(). Reasoning is detailed in the PR's description.

Props to @afragen for co-investigation and co-testing.

[salcode]

I want to explicitly call out this ticket was originally opened based on this ​WP CLI GitHub issue and @costdev's patch corrects this WP CLI behavior, as well.

Warning: The PHP version on your server is 7.3.33, however the new plugin version requires 8.0.
+------------+-------------+-------------+--------+
| name       | old_version | new_version | status |
+------------+-------------+-------------+--------+
| spatie-ray | 1.4.0       | 1.7.5       | Error  |
+------------+-------------+-------------+--------+
Error: No plugins updated (1 failed)

Thank you both for your work on this!

[iammehedi1]

Test Report

This report validates that the indicated patch fixed the issue

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/5116

Environment

• OS: Windows 11 Pro (22H2)
• Web Server: nginx/1.25.1
• PHP: 7.4.33
• WordPress: 6.4-alpha-56267-src
• Browser: Chrome Version 116.0.5845.98 (Official Build) (64-bit)
• Theme: Twenty Twenty-Three

Prior to Applying the Patch

• Error message while updating the plugin:

• It eventually updates and leads to fatal error:

After Applying The Patch

• ✅ 'Update failed' error message comes up while bulk Update - which is correct:

Plugins Used

• Spatie Ray -Version 1.4.0

[zunaid321]

Test Report

This report validates that the indicated patch addresses the issue.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/5116

Environment

• OS: Windows 11 (22H2)
• Web Server: nginx/1.25.1
• PHP: 7.4.33
• WordPress: 6.4-alpha-56267-src
• Browser: Chrome Version 113.0.5672.126 (Official Build) (64-bit)
• Theme: Twenty Twenty-Three
• Plugins Used: Spatie Ray - v1.4.0

Before Applying The Patch

• Followed the instructions of @salcode
• ❌ Fatal error comes up after the plugin is updated in bulk

After Applying The Patch

• Followed the same instructions.
• ✅ The folllowing message comes up after the update is initiated in bulk:
• 'Update failed: The PHP version on your server is 7.4.33, however the new plugin version requires 8.0.'

Supplemental Artifacts

Before the plugin is updated:

Fatal error shows up after the plugin is updated:

After the patch is applied, the message shows up:

[costdev]

​PR 5116 has 4 confirmed tests, removing needs-testing.

@johnbillion @azaozz I'm happy to commit this one, but as I wrote the PR, would one of you have time to give it a final review? 🙂

[costdev]

In 56525:

Upgrade/Install: Check plugin compatibility during bulk upgrades.

Previously, bulk upgrades did not verify that a plugin package was compatible with the site's WordPress version or the server's PHP version. This could lead to incompatible updates being installed, causing various compatibility issues and errors.

This change implements the following checks:

• If available, the API response's requires and requires_php values are checked for compatibility. This saves time, diskspace, memory and file operations by failing the upgrade before the package is downloaded and unpacked.
• If the API check passes, the downloaded and unpacked package is verified using Plugin_Upgrader::check_package() to ensure a plugin file is present, and the plugin's "RequiresWP" and "RequiresPHP" headers are compatible, if present. This ensures that a mismatch between the API response and the plugin file's headers does not cause an incompatible plugin to be installed.

Props salcode, afragen, mukesh27, iammehedi1, zunaid321, johnbillion, SergeyBiryukov, costdev.
Fixes #59198.

Committed in 56525.

[johnbillion]

@costdev Do you think this warrants backporting to older branches? As more and more plugins increase their minimum supported PHP version it could help prevent bricking sites on older branches.

[costdev]

@johnbillion Certainly in terms of making the older branches more resilient, this could be beneficial to include in the next security/maintenance release. However I'm not sure what the criteria is for non-security backports.

Note that:

• Plugin_Upgrader::bulk_upgrade() was introduced in 2.8
• Plugin_Upgrader::check_package() was introduced in 3.3
• is_wp_version_compatible() and is_php_version_compatible() were introduced in 5.2, so something like these should be used for earlier versions:

// WordPress.
version_compare( explode( '-', $GLOBALS['wp_version'] )[0], $required, '>=' );

// PHP.
version_compare( PHP_VERSION, $required, '>=' )

[johnbillion]

Let's reopen this for discussion about backporting.

[nicolefurlan]

With 6.4 RC1 ~2 weeks away, let's keep this discussion going so that we can get any backporting changes in, if we think that is possible and important. (cc component maintainers @costdev and @afragen)

[audrasjb]

I think it would indeed be nice to backport it to previous releases.
I will backport to 6.3 right now, but for older branches, we'll probably need to adapt the changeset/resolve conflicts with other branches. Probably better to create the changesets ahead of the release.

[joemcgill]

I think including this change in the current major release (6.3) makes sense. Adding more resiliency to the upgrade process for previous versions seems like a separate discussion to me.

[audrasjb]

In 56787:

Upgrade/Install: Check plugin compatibility during bulk upgrades.

Previously, bulk upgrades did not verify that a plugin package was compatible with the site's WordPress version or the server's PHP version. This could lead to
incompatible updates being installed, causing various compatibility issues and errors.

This change implements the following checks:

• If available, the API response's requires and requires_php values are checked for compatibility. This saves time, diskspace, memory and file operations by

failing the upgrade before the package is downloaded and unpacked.

• If the API check passes, the downloaded and unpacked package is verified using Plugin_Upgrader::check_package() to ensure a plugin file is present, and the

plugin's "RequiresWP" and "RequiresPHP" headers are compatible, if present. This ensures that a mismatch between the API response and the plugin file's headers does
not cause an incompatible plugin to be installed.

Props salcode, afragen, mukesh27, iammehedi1, zunaid321, johnbillion, SergeyBiryukov, costdev, nicolefurlan, audrasjb, nicolefurlan.
Merges [56525] to the 6.3 branch.
Fixes #59198.

--

_M 6.3
M 6.3/src/wp-admin/includes/class-plugin-upgrader.php