number_format_i18n throws a PHP error if a string is passed

[pbearne]

In writing a unit test for number_format_i18n we found it blow up when a string is passed

number_format_i18n( 'seven' )

added a cast to force to a number (0) when a string is passed

included unit test

[pbearne]

patch with unit tests

[pbearne]

We wrote as part of the Virtual Contrib to Core seesion ​http://www.meetup.com/WPToronto/events/228399539/

[swissspidy]

That's a pretty cool event!

Please note that the value passed to number_format_i18n() needs to be a float, not an int. See #35893. Otherwise the precision (second parameter) doesn't really make sense.

That means tests are needed for floating point values, perhaps using a data provider.

Oh, and I wouldn't reset $wp_locale in the tests, as other tests might rely on this global variable. Instead, I'd recommend using custom setUp() and tearDown() methods to properly reset the object.

Let me know if you need any help with that.

[SergeyBiryukov]

Related: #17299, #19590.

[pbearne]

new unittest

[pbearne]

Added more test to use floats and ints comments etc.

[pbearne]

Both function (with case to float) and unit tests

[johnbillion]

Raising a warning here is expected behaviour. PHP notices and warnings exist for a reason - if you pass a string to number_format(), you'll get a warning because it expects a float, so there's no reason why passing a string to number_format_i18n() should silently perform type coercion to avoid triggering a warning.

[swissspidy]

I agree with @johnbillion, but I'd like to see some unit tests for this function. I'll get them in shape to commit them, perhaps in a new ticket.

[dd32]

Agreed, these PHP warnings/notices are expected and aid Developers.

[pbearne]

@swissspi if you do rewrite the unit tests do let us know what you changed so we can learn

[swissspidy]

@pbearne Sure! I added some notes in the follow-up ticket #36029.