[ wp-includes/functions.php - number_format_i18n() ] - fallback in case number is not a float

[riccardodicurti]

Good morning everyone, while working on a project on php 8, I found that a plugin was passing number to number_format_i18n() that was not a float and this led to an error.

In my opinion, it would therefore be better to add a check or a cast to float in order to avoid potential errors.

Thanks in advance.

Trac ticket: Core: 62474

Currently in WordPress 6.6, passing non-numeric values to number_format_i18n() can trigger PHP errors in PHP 8. This PR adds float-type casting to safely handle all input types.

[abcd95]

Hey @riccardodicurti, Thanks for bringing this up.

I was able to reproduce this issue. The problem occurs when non-numeric values are passed to number_format_i18n().

Reproduction Steps:

Run:

number_format_i18n("abc"); Throws error

Screenshots

• Before the patch -
• After the patch -

Please let me know if we can do better!

[riccardodicurti]

Ciao @abcd95, I think this should be perfect. I tested the patch myself, and it works as expected. Thank you.

[swissspidy]

Why not just fix the type in your plugin? Core dorsn‘t usually paper over ddvdlopers‘ issues like that by adding casts everywhere. It‘s your responsibility to pass the expected type to a function.

[SergeyBiryukov]

Hi there, thanks for the ticket!

This was previously discussed in #17299 and #35840, and the consensus was that we should not hide warnings caused by developer errors, unless there is a strong reason. It would just make debugging harder.

If a valid parameter generates a warning, we should certainly fix that. However, in case of an invalid parameter, I think the warning (or an error on PHP 8.0+) is to be expected.