Condition is not strictly checked on options-general.php file

[rakibwordpress]

In options-general.php file it is 0 is being compared with another variable which is $current_offset. As 0 is numeric value this needs to be compared.

Trac ticket:

[hellofromTonya]

Hello @rakibwordpress,

Welcome back to WordPress Core's Trac!

I'm doing some triage for open tickets against trunk to see if the defect was introduced in the 6.2.0 cycle. For this one, the code is from 3.0.0, introduced via [12507] / #11558. Changing the Version number.

Also a note for consideration:
Will $current_offset always be an integer 0? Or could it be a string '0'? The current code will type juggle to compare the values without comparing the data types.

What I'm wondering (haven't looked deeply into it):
Is there a strict requirement that 0 must be an integer data type?

If no, then === could cause a backwards-compatibility issue or break in the code when it's a string 0.

[SergeyBiryukov]

Replying to hellofromTonya:

Also a note for consideration:
Will $current_offset always be an integer 0? Or could it be a string '0'? The current code will type juggle to compare the values without comparing the data types.

This gets even more interesting, as the value can also be float or false, via wp_timezone_override_offset() hooked to pre_option_gmt_offset in wp-includes/default-filters.php.

[oglekler]

This ticket was discussed in the recent bug scrub and due to lack of activity it was decided to move it into future release.

This ticket needs some additional work and unit test as well. It can be moved to the next available milestone when it will be ready.

Props: @Clorith @costdev

[costdev]

Moving to Future Release per the above comment.

Trac ticket: https://core.trac.wordpress.org/ticket/57030

## Description

Fixes a strict comparison issue in options-general.php where the $current_offset variable was not being strictly compared as an integer. This issue could lead to unexpected behavior when comparing the gmt_offset option, especially when it could be interpreted as different types such as string or float.

### Changes Made

• Adjusted the comparison of $current_offset to ensure it is strictly compared as an integer 0.
• Updated logic to handle cases where gmt_offset may vary in type (integer, string, or float).
• Introduced unit tests to validate the behavior across different gmt_offset scenarios.

### Added Unit Tests

• Created gmtOffset.php file to house unit tests specifically targeting the gmt_offset behavior.
• Covered scenarios such as integer 0, string '0', negative float values, and invalid string inputs for gmt_offset.

[rajinsharwar]

I guess this was solved via #60700 as the strict checks have already been implemented. Maybe we can close this.

Replying to SergeyBiryukov:

This gets even more interesting, as the value can also be float or false, via wp_timezone_override_offset() hooked to pre_option_gmt_offset in wp-includes/default-filters.php.

I guess when the value is false, it currently works fine with the logic of $tzstring = 'UTC+' . $current_offset. And, I do not think the value will ever be float, given that the code is wrapped with the check of empty( $tzstring ).

In wp_timezone_override_offset() it states that it "Overrides the gmt_offset option if we have a timezone_string available". So, if the timezone is not available, I do not think a float will be returned.

Marking this as a candidate for close.

[SergeyBiryukov]

Replying to rajinsharwar:

I guess this was solved via #60700 as the strict checks have already been implemented. Maybe we can close this.

Good catch, thanks! This is now resolved in [57833] / #60700. I forgot about this ticket, sorry for that.

Replying to SergeyBiryukov:

This gets even more interesting, as the value can also be float or false, via wp_timezone_override_offset() hooked to pre_option_gmt_offset in wp-includes/default-filters.php.

I guess when the value is false, it currently works fine with the logic of $tzstring = 'UTC+' . $current_offset. And, I do not think the value will ever be float, given that the code is wrapped with the check of empty( $tzstring ).

You're right. In my testing, $current_offset is actually a string here, since wp_timezone_override_offset() returning false in case of an empty timezone string means that get_option() proceeds to retrieve the value from the database. Now that the value is cast to an integer, the strict comparison works as expected.