#52298 closed defect (bug) (wontfix)
Using ID as type string instead of int
Reported by: |
|
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
@
4 years ago
- Keywords reporter-feedback added
#2
@
4 years 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
@
4 years 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
@
4 years 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.
Hi there, welcome back to WordPress Trac! Thanks for the ticket.
Replying to malthert:
Could you elaborate a bit more? Most of the functions like
get_the_ID()
orget_post()
return the post ID asint
, this is done viasanitize_post()
. Changing the ID to a string instead would be a backward compatibility break.