Opened 16 months ago
Closed 14 months ago
#59198 closed defect (bug) (fixed)
Bulk actions "Update" ignores Minimum PHP Version Requirement
Reported by: | salcode | Owned by: | costdev |
---|---|---|---|
Milestone: | 6.3.2 | Priority: | normal |
Severity: | critical | Version: | |
Component: | Upgrade/Install | Keywords: | fixed-major |
Focuses: | Cc: |
Description
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 |
- On a WordPress
6.3
install running PHP7.3
(or7.4
) with WP CLI setup - 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
- Go to
/wp-admin/plugins.php
and you'll see a message indicating the plugin can not be updatedThere 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.
- Check the checkbox in front of the plugin name "Spatie Ray"
- From the
Bulk actions
select box, chooseUpdate
- Click the
Apply
button next to theBulk 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.
Attachments (6)
Change History (38)
@
16 months ago
The WordPress UI indicating a plugin can not be updated due to the PHP minimum version requirement.
This ticket was mentioned in PR #5087 on WordPress/wordpress-develop by salcode.
16 months ago
#1
- Keywords has-patch added
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.
#2
@
16 months ago
Probably best to apply a fix directly and not via a filter.
I’ll try for a closer look tomorrow. Good pick up.
#3
@
16 months ago
- Version 6.3 deleted
Thanks @salcode for the ticket and PR.
The filter approach use in install method.
#4
@
16 months ago
@salcode it would seem a similar patch is required for class-theme-upgrader.php
too.
#5
@
16 months ago
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
#6
@
16 months ago
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.
#7
@
16 months ago
@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
- The first message "This plugin does not work with your version of PHP." and
- 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 😀.
@
16 months ago
Fatal error displayed after updating to a version of the plugin that requires PHP 8.0, while running PHP 7.3
This ticket was mentioned in Slack in #core by salcode. View the logs.
16 months ago
#9
@
16 months ago
- Focuses php-compatibility added
- Keywords needs-testing added
- Milestone changed from Awaiting Review to 6.4
- Severity changed from normal to critical
#10
@
16 months ago
- Focuses php-compatibility removed
- Keywords changes-requested added
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 containrequires
andrequires_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()
andis_php_version_compatible()
respectively. - If either isn't compatible, we can set
$result
to aWP_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
This ticket was mentioned in PR #5116 on WordPress/wordpress-develop by @costdev.
16 months ago
#11
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
andrequires_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.
#13
@
16 months ago
- Keywords changes-requested removed
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.
#14
@
16 months ago
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!
This ticket was mentioned in Slack in #core-upgrade-install by costdev. View the logs.
16 months ago
#18
@
15 months ago
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
After Applying The Patch
Plugins Used
- Spatie Ray -Version 1.4.0
#19
@
15 months ago
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
#20
@
15 months ago
- Keywords needs-testing removed
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? 🙂
#24
@
15 months ago
@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.
#25
@
15 months ago
@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.8Plugin_Upgrader::check_package()
was introduced in 3.3is_wp_version_compatible()
andis_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, '>=' )
#26
@
15 months ago
- Keywords fixed-major added; has-patch has-testing-info commit removed
- Resolution fixed deleted
- Status changed from closed to reopened
Let's reopen this for discussion about backporting.
#27
@
14 months ago
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)
This ticket was mentioned in Slack in #core by costdev. View the logs.
14 months ago
#30
@
14 months ago
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.
The WordPress UI indicating a plugin can not be installed due to the PHP minimum version requirement.