Fix WordPress requirement check for unavailable plugin updates#531
Fix WordPress requirement check for unavailable plugin updates#531TowyTowy wants to merge 1 commit into
Conversation
When an update is present in the update API's `no_update` list with a newer version than the installed copy, `get_item_list()` derives the `update_unavailable_reason` that `wp plugin update`/`wp plugin list` surface. The WordPress-version branch compared the installed WordPress version against `$requires`, which by that point holds the *installed* plugin's own "Requires at least" header (line 972-974 fallback), and used `>=` instead of `<`. As a result the "This update requires WordPress version X" message was emitted whenever the site met the plugin's own minimum (almost always true) rather than when the site actually failed the update's WordPress requirement, producing a nonsensical reason for updates that are unavailable for other reasons (e.g. paid plugins), and hiding it when the plugin's own header exceeded the running WordPress version. Compare the running WordPress version against the update's own `requires` value with `<`, matching the correct behavior already used for themes in ParseThemeNameInput::get_all_items(). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Hello! 👋 Thanks for opening this pull request! Please check out our contributing guidelines. We appreciate you taking the initiative to contribute to this project. Contributing isn't limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation. Here are some useful Composer commands to get you started:
To run a single Behat test, you can use the following command: # Run all tests in a single file
composer behat features/some-feature.feature
# Run only a specific scenario (where 123 is the line number of the "Scenario:" title)
composer behat features/some-feature.feature:123You can find a list of all available Behat steps in our handbook. |
github-actions
Bot
added
bug
command:plugin-update
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Pull request overview
Fixes incorrect “requires WordPress version …” unavailability messaging for plugin updates surfaced via the update API’s no_update list by comparing against the update’s own requires value (and using the correct comparison direction), aligning behavior with the existing theme handling.
Changes:
- Correct WordPress version requirement check in
Plugin_Command::get_item_list()to compare$wp_versionagainst$plugin_update_info->requiresusing<. - Add a Behat scenario asserting the WordPress-requirement warning is not emitted when the site already meets the update’s
requires.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/Plugin_Command.php | Fixes the WordPress-version gating logic for update_unavailable_reason when updates come from no_update. |
| features/plugin.feature | Adds regression coverage ensuring the incorrect WordPress requirement warning is not shown when requirements are satisfied. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if ( isset( $plugin_update_info->requires ) && version_compare( $wp_version, $plugin_update_info->requires, '<' ) ) { | ||
| $reason = "This update requires WordPress version $plugin_update_info->requires, but the version installed is $wp_version."; | ||
| } elseif ( ! isset( $plugin_update_info->package ) ) { | ||
| $reason = 'Update file not provided. Contact author for more details'; |
|
cc @mrsdizzie since you worked on the original implementation here. |
Description
When a plugin update appears in the update API's
no_updatelist with a newer version than the installed copy,Plugin_Command::get_item_list()computes theupdate_unavailable_reasonthatwp plugin updateandwp plugin listsurface. The WordPress-version branch had two problems:$requires, but by that point$requireshas been reassigned to the installed plugin's own "Requires at least" header (the display fallback a few lines above), not the update's required version ($plugin_update_info->requires).>=(requirement met) to gate the "requirement not met" message.The net effect: the message "This update requires WordPress version X, but the version installed is Y" was shown whenever the site met the plugin's own minimum — almost always true — so updates that are unavailable for other reasons (for example paid plugins served via
no_update) reported a nonsensical WordPress-version reason (Y ≥ X). Conversely, when a plugin's own header exceeded the running WordPress version, the genuine reason was suppressed.This compares the running WordPress version against the update's own
requiresvalue using<, matching the behavior already implemented correctly for themes inParseThemeNameInput::get_all_items().Introduced in #440.
How to reproduce
Install a plugin, then have the update-check API return the plugin in
no_updatewith a newernew_versionand arequiresvalue the site satisfies.wp plugin update <slug>warns "This update requires WordPress version …" even though the installed version meets that requirement.Testing
Adds a Behat scenario in
features/plugin.featureasserting the WordPress-requirement reason is not emitted when the site already meets the update'srequires. PHPStan (level 9) and PHPCS pass. (No standalone PHPUnit exists for command logic; the repo covers this via Behat, which needs a live WP install.)Disclosure: prepared with assistance from Claude (Anthropic); reviewed and verified before submission.