WordPress.org

Make WordPress Core

Opened 4 months ago

Closed 4 months ago

Last modified 4 months ago

#53235 closed defect (bug) (fixed)

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

Reported by: SergeyBiryukov Owned by: SergeyBiryukov
Milestone: 5.8 Priority: normal
Severity: normal Version:
Component: General Keywords: has-patch needs-dev-note
Focuses: Cc:

Description (last modified by 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

Attachments (1)

53235.diff (4.4 KB) - added by SergeyBiryukov 4 months ago.

Download all attachments as: .zip

Change History (8)

#1 @SergeyBiryukov
4 months ago

  • Keywords has-patch added
  • Owner set to SergeyBiryukov
  • Status changed from new to accepted

#2 @SergeyBiryukov
4 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#3 @SergeyBiryukov
4 months ago

  • Description modified (diff)

#4 follow-up: @peterwilsoncc
4 months ago

  • Keywords needs-dev-note added

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.

#5 @SergeyBiryukov
4 months ago

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.

#6 in reply to: ↑ 4 ; follow-up: @SergeyBiryukov
4 months ago

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.

Last edited 4 months ago by SergeyBiryukov (previous) (diff)

#7 in reply to: ↑ 6 @peterwilsoncc
4 months ago

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.

Note: See TracTickets for help on using tickets.