Ensure consistent type for integer properties of WP_Post, WP_Term, and WP_User

[SergeyBiryukov]

Background: #52995.

Some properties of the WP_Post, WP_Term, and WP_User classes are documented as integers, so it should be a safe assumption to always treat them as such. However, that is not the case when get_post() or get_term() is called with an edit, attribute, or js context, because all values are run through esc_attr() or esc_js() in that case, and these properties are unexpectedly converted to strings.

As WordPress moves to strict type comparisons in tickets like #52627 or #52482, it is important to make the type of these properties consistent in all contexts, so that using strict comparison does not cause unexpected issues.

This applies to the following functions:

• sanitize_post_field()
• sanitize_term_field()
• sanitize_user_field()

and the following properties:

• WP_Post::ID
• WP_Post::post_parent
• WP_Post::menu_order
• WP_Term::term_id
• WP_Term::term_taxonomy_id
• WP_Term::parent
• WP_Term::count
• WP_Term::term_group
• WP_User::ID

[SergeyBiryukov]

In 50935:

General: Ensure consistent type for integer properties of WP_Post, WP_Term, and WP_User.

Previously, these properties could be unexpectedly converted to strings in some contexts.

This applies to the following functions:

• sanitize_post_field()
• sanitize_term_field()
• sanitize_user_field()

and the following properties:

• WP_Post::ID
• WP_Post::post_parent
• WP_Post::menu_order
• WP_Term::term_id
• WP_Term::term_taxonomy_id
• WP_Term::parent
• WP_Term::count
• WP_Term::term_group
• WP_User::ID

Props grantmkin, SergeyBiryukov.
Fixes #53235. See #52995.

[peterwilsoncc]

I vaguely remember something like this causing problems in the past but can't find the solution, ie whether converting to string was deliberate or a dev note was published.

I did find this ​slack discussion between @pento and @boonebgorges but not the outcome.

[SergeyBiryukov]

In 50936:

General: Ensure consistent type for integer properties of a bookmark object.

Previously, these properties could be unexpectedly converted to strings in some contexts.

This applies to the following function:

• sanitize_bookmark_field()

and the following properties:

• $bookmark::link_id
• $bookmark::link_rating

Follow-up to [50935].

See #53235.

[SergeyBiryukov]

Replying to peterwilsoncc:

I vaguely remember something like this causing problems in the past but can't find the solution, ie whether converting to string was deliberate or a dev note was published.

Could that be about the WP_Post::post_author and WP_Post::comment_count properties in #22324? They were indeed left as a string at the time for backward compatibility.

In this ticket, we're not changing the type of properties, just making sure they always match the documented type.

[peterwilsoncc]

Replying to SergeyBiryukov:

Could that be about the WP_Post::post_author and WP_Post::comment_count properties in #22324? They were indeed left as a string at the time for backward compatibility.

The slack discussion mentions term IDs, I remember because I was sitting next to a theme author who discovered the type change when they had something along the lines of get_option( 'my_special_term_id' ) === /* a term ID */ in their code

In this ticket, we're not changing the type of properties, just making sure they always match the documented type.

Excellent. In that case, I expect it's not a problem for this ticket and the solution at the time was a dev note.