The user ID in a `WP_User_Request` is not an integer as stated

[desrosj]

Discovered this while debugging something in #43985. The value of WP_User_Request->user_id is a string, not an integer as stated by the inline documentation. This was causing some unexpected behavior in get_user_locale(), which performs a strict comparison for 0 and was causing the condition to incorrectly evaluate as false.

[desrosj]

44723.diff​ type casts the property as an integer. But, this could be a potentially breaking change. It may be better to change the documentation to indicate the value is a string.

[garrett-eclipse]

Interesting enough but if you go down the rabbit hole although the codex states WP_Post's post_author is 'A numeric string, for compatibility reasons' it's default is the numeric 0 and in wp_insert_post it's expecting an (int) but if not provided uses the return of get_current_user_id which is an int.

$post_author in WP_Post - https://core.trac.wordpress.org/browser/tags/4.9.8/src/wp-includes/class-wp-post.php#L32
wp_insert_post Codex - ​https://developer.wordpress.org/reference/functions/wp_insert_post/
$user_id in wp_insert_post - https://core.trac.wordpress.org/browser/tags/4.9.8/src/wp-includes/post.php#L3139
get_current_user_id Codex - ​https://developer.wordpress.org/reference/functions/get_current_user_id/

So it's weird it seems it's always an int down the chain so not sure why it's saying it's a numeric string.

[SergeyBiryukov]

Replying to garrett-eclipse:

So it's weird it seems it's always an int down the chain so not sure why it's saying it's a numeric string.

See the discussion in #22324 and #25092.

[garrett-eclipse]

Thanks @SergeyBiryukov I appreciate the references, I think that should equip @desrosj to continue on here. Cheers

[javorszky]

I think this is related here: https://core.trac.wordpress.org/ticket/43752

[TZ Media]

Taking the other tickets mentioned into account, I believe changing the documentations is more in alighment with how such issues were handled in the past. And as long as WP does not use PHP7 strict type hinting, return value types can't be trusted anyway and must be checked/sanitized.

[andizer]

Unit test

[andizer]

I've added a new patch with the same fix. I suppose this is what meant with a refresh.

[desrosj]

I have not been able to dig into this during this release cycle. I'm also thinking that if this is changed, it should happen early just in case this creates any unforeseen problems.

Removing myself so someone else can dig into this if they'd like in the mean time.

[johnbillion]

Replying to TZ Media:

I believe changing the documentations is more in alignment with how such issues were handled in the past.

Agreed, let's fix the documentation and retain the string ID property.