Make WordPress Core

Opened 2 months ago

Last modified 6 days ago

#59448 new defect (bug)

is_wp_version_compatible works unreliably

Reported by: kkmuffme's profile kkmuffme Owned by:
Milestone: Future Release Priority: normal
Severity: minor Version: 5.2
Component: Upgrade/Install Keywords: good-first-bug 2nd-opinion has-patch has-unit-tests
Focuses: Cc:


on all major WP version releases is_wp_version_compatible works unreliably.
(the root cause is, but the function needs to be fixed too)

e.g. on WP 6.3, if you pass in '6.3.0' you would get back false, which is not what you'd expect

Attachments (1)

59448.patch (1.5 KB) - added by sessioncookiemonster 4 weeks ago.
Patch for this

Download all attachments as: .zip

Change History (12)

#1 @afragen
2 months ago

  • Component changed from General to Upgrade/Install
  • Severity changed from blocker to minor

But there is no WP version 6.3.0. The version number is 6.3.

WordPress doesn’t conform to precise semantic versioning and has never used the x.x.0 format.

#2 @kkmuffme
2 months ago

Yes, that's why the other issue was opened to correct that, but that is something else.

The issue here is that 6.3 and 6.3.0 will return different results, which isn't what anybody would usually expect.

This ticket was mentioned in Slack in #core by jorbin. View the logs.

5 weeks ago

#4 @jorbin
5 weeks ago

  • Keywords needs-patch good-first-bug added
  • Milestone changed from Awaiting Review to Future Release
  • Version changed from trunk to 5.2

is_wp_version_compatible was introduced in 5.2, so adjusting the version.

As @afragen noted, 6.3.0 isn't a valid release. So the question becomes what should happen if you pass in an invalid version. I think what's best here is to assume that someone means 6.3 in this example.

I think the path forward for this is to maybe throw a doing_it_wrong or wp_trigger_error if you pass in x.y.0 and strip off the .0 so that version_compare works correctly.

The patch for this should also include tests

4 weeks ago

Patch for this

#5 @sessioncookiemonster
4 weeks ago

I threw a _doing_it_wrong, like @jorbin suggested, set the version to X.X, since I don't know when this might be added

#6 @jorbin
3 weeks ago

  • Keywords 2nd-opinion added

Thanks @sessioncookiemonster for the patch. A few notes:

  • Please make sure to use the WordPress coding standards. PHPCS should be able to help with this.
  • The string needs to be translatable. I also think it might be good to make this error as descriptive as possible, maybe something like Invalid Version string passed to is_wp_version_compatible. $version passed but $valid_request assumed.

Also, @costdev pointed out in slack that wp_trigger_error might be better to use. I'm not sure yet but would love to hear some other folks chime in.

#7 @afragen
3 weeks ago

Just a thought but what about using str_ends_with() and then rtrim() ?

Result would then need to ensure proper x.0 version for replacement.

Just thinking it might be more clear what we’re trying to do than with regex.

#8 @afragen
3 weeks ago

Last edited 3 weeks ago by afragen (previous) (diff)

This ticket was mentioned in PR #5677 on WordPress/wordpress-develop by @afragen.

3 weeks ago

  • Keywords has-patch has-unit-tests added; needs-patch removed

Some users improperly test for releases of the format x.x.0. Unfortunately there is never a WordPress release with this version number and version_compare( '5.2', '5.2.0', '>=' ) is false.

Test value sent to is_wp_version_compatible( $required ) to ensure a trailing zero (x.x.0) is fixed to be (x.x) and a wp_trigger_error() is sent.

This will correctly test the improper version x.x.0 as x.x.

Trac ticket:

#10 @afragen
3 weeks ago

Using error_log() as wp_trigger_error() results in exiting the function and therefore cannot correct the value x.0.0 to x.0 and have the script continue.

This ticket was mentioned in Slack in #core by afragen. View the logs.

6 days ago

Note: See TracTickets for help on using tickets.