WordPress.org

Make WordPress Core

Opened 11 months ago

Closed 11 months ago

Last modified 11 months ago

#52298 closed defect (bug) (wontfix)

Using ID as type string instead of int

Reported by: malthert Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: reporter-feedback
Focuses: Cc:

Description

Currently all params/return treat IDs (e.g. post id) as type int.

However, this causes loads of typecasts, since by default all WP functions retrieve things as strings. (get option, wpdb, get transient, cache get, ...), which means we always need to typecast when retrieving ids. There is currently no way to retrieve a post ID as int in WP, which means we ALWAYS have to typecast it.

Secondly, we dont do any numeric operations using IDs anyway (thus there is no advantage of it being an int)

Change History (4)

#1 in reply to: ↑ description @SergeyBiryukov
11 months ago

  • Keywords reporter-feedback added

Hi there, welcome back to WordPress Trac! Thanks for the ticket.

Replying to malthert:

There is currently no way to retrieve a post ID as int in WP, which means we ALWAYS have to typecast it.

Could you elaborate a bit more? Most of the functions like get_the_ID() or get_post() return the post ID as int, this is done via sanitize_post(). Changing the ID to a string instead would be a backward compatibility break.

#2 @malthert
11 months ago

And if you look at the code, you see that there is a typecast happening in sanitize_post(_field) for the ID field:

$int_fields = array( 'ID', 'post_parent', 'menu_order' );
if ( in_array( $field, $int_fields ) ) {
	$value = (int) $value;
}

Which confirms, as I stated, there is currently no way to retrieve the post ID as an int, that does not require typecasting. Which means that using a string would make infinitely more sense (given the reasons in my first post)

Changing the ID to a string instead would be a backward compatibility break.

It wouldn't, since the specifics of int only matter when using mathematical operations - these are the reasons when PHP7.4+ will give a notice.
However post IDs cannot be logically used for any mathematical operations commonly (there may be some fringe cases, but again these should be handled by these fringe case owners)

Changing post ID params to string, perhaps with a temporary in between of string|int would not cause any major compatibility issues.

#3 @johnbillion
11 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed
  • Version trunk deleted

Changing this would break every plugin and theme that uses strict types or strict comparison (===).

A post ID is an integer. It's a BIGINT in the database. It's typecast internally because it's read from the database as a string, which is unfortunate, but that ship sailed fifteen years ago.

#4 @malthert
11 months ago

Changing this would break every plugin and theme that uses strict types or strict comparison (===).

If you take a look at what is around in the WP ecosystem (plugins), this is handled so inconsistently that even add filters often change the ID to type string (due to missing typecasting).
Given your reasoning, all these inconsistent implementations would break every plugin.

A post ID is an integer. It's a BIGINT in the database. It's typecast internally because it's read from the database as a string, which is unfortunate, but that ship sailed fifteen years ago.

I totally agree with you on this. The issue however is handling. The majority of plugins do not typecast their IDs/data they retrieve from wpdb, option, transient or cache (which ALL return type string) causing an idiotic mix of string|int.
Thus why not make it simple for everybody and switch it to string - as lots (probably most) plugins already treat it as a string anyway, since they (almost) never typecast their stuff.

Note: See TracTickets for help on using tickets.