[wp-trac] [WordPress Trac] #52458: WordPress version check is passing "false" value to "esc_url" causing errors (in the logs)

[WordPress Trac]

#52458: WordPress version check is passing "false" value to "esc_url" causing
errors (in the logs)
-----------------------------------------+-----------------------------
 Reporter:  jipmoors                     |       Owner:  SergeyBiryukov
     Type:  defect (bug)                 |      Status:  reviewing
 Priority:  normal                       |   Milestone:  5.7
Component:  Upgrade/Install              |     Version:  5.3
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch reporter-feedback  |     Focuses:
-----------------------------------------+-----------------------------
Changes (by SergeyBiryukov):

 * keywords:  has-patch => has-patch reporter-feedback


Comment:

 Thanks for the patch! Linking the original changeset here for reference:
 [45578] / #36369.

 Could you share the exact error message you're getting? I could not
 reproduce the issue on a clean install:

 * Passing a `false` or `null` value to `ltrim()` does in fact seem to work
 as expected on all PHP versions, including PHP 8: https://3v4l.org/XtVCn
 * The only issue I see is when passing an `array()` to `ltrim()`:
 https://3v4l.org/lXd4s. This causes a warning on PHP 7 and a fatal error
 on PHP 8.
 * Or, passing a non-array value to `array_map()`: https://3v4l.org/IOuSW.
 This also causes a warning on PHP 7 and a fatal error on PHP 8.

 Passing a non-string value to `esc_url()` is a developer error, so the
 developer should be notified of that. Patching the function itself to hide
 the warning would just pass the issue further. The function is documented
 to receive and return a string, so returning something else instead might
 have unintended side effects elsewhere. I think the current behavior is
 appropriate.

 Passing a non-array value to `array_map()` in `wp_version_check()` seems
 like something we could protect against, see [attachment:"52458.diff"],
 though I could not reproduce that scenario in my testing either, so it
 does not seem to occur often. For that to happen, the WP.org API would
 have to return a non-empty `offers` array with an empty `packages` key.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52458#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform