Make WordPress Core

Opened 5 years ago

Last modified 4 weeks ago

#16445 new defect (bug)

Fix incompatibilities with IDs greater than 2^31

Reported by: Viper007Bond Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.1
Component: Import Keywords: needs-patch
Focuses: Cc:

Description (last modified by Viper007Bond)

For various reasons, things go bad when you get a post ID greater than 231. When we're importing content and there's an existing ID, I suggest we ignore it if possible if it's too big.

Tumblr2WordPress for example maintains the Tumblr IDs and causes problems in WordPress.

Change History (16)

comment:1 @Viper007Bond5 years ago

  • Description modified (diff)

comment:2 @Viper007Bond5 years ago

  • Description modified (diff)

comment:3 follow-up: @lloydbudd5 years ago

What things go bad? If you want to maintain the permalinks after importing from Tumblr (+custom domain) then the easiest solution is probably to maintain the bigint postid.

Last edited 5 years ago by lloydbudd (previous) (diff)

comment:4 @daniloercoli5 years ago

  • Cc daniloercoli added

i don't know if it is related but we have similar issues with post IDs using the XML-RPC endpoint.
The postID returned by metaWeblog.editPost, for example, is an int field


but in the case above the value exceeds the xml-rpc specs for the int type (four-byte signed integer - http://www.xmlrpc.com/spec)

So, within the java app, we have issues because the XML-RPC parser tries to retrieve the value using an Integer (It has a minimum value of -2,147,483,648 and a maximum value of 2,147,483,647 (inclusive)).

comment:5 @josephscott5 years ago

If we change the type to 'string' for postid, will it make things work for you again? It would be great if you could test that before we consider making that change official.

comment:6 follow-up: @josephscott5 years ago

  • Cc josephscott added

comment:7 in reply to: ↑ 3 @Viper007Bond5 years ago

Replying to lloydbudd:

What things go bad? If you want to maintain the permalinks after importing from Tumblr (+custom domain) then the easiest solution is probably to maintain the bigint postid.

Agreed. This is probably a much better long term solution to just fix the things that break when the post ID gets that big, such as XML-RPC.

comment:8 @westi5 years ago

  • Cc westi added

comment:9 in reply to: ↑ 6 @daniloercoli5 years ago

Replying to josephscott:

Agree with you, String seems to be a good solution for the long term that respects the standard.
In any case, we should release a new version of the blackberry app (and maybe others), to switch to string, or if you won't change things on your side, we should modify the parser and generate a 'Long' when the overflow will occur.
note: we should fix page_id as well.

comment:10 @nacin5 years ago

  • Milestone changed from Awaiting Review to Future Release
  • Summary changed from Don't allow imported IDs to be greater than 2^31 to Fix incompatibilities with IDs greater than 2^31

comment:11 @duck_5 years ago

It's not just the interfaces to the importers/XML-RPC but rather casting to int is prevalent throughout the code base. I also assume this is not a problem for 64-bit systems on which PHP_INT_MAX is the same as BIGINT.

X-ref: Importer fails for post_id's over PHP_INT_MAX of 2147483647

comment:12 @noahcoad3 years ago

changing to bigint fix this for me, but JetPack site stats still show "#2147483647 (loading title)" as getting all my page views, meaning the WordPress JetPack host needs to be updated as well. See pic: http://screencast.com/t/ZdEwbRPe1BR

comment:13 @noahcoad3 years ago

To get Jetpack to correctly log stats I had to manually reset all the post IDs (by tweaking my sql tables, a real pain).

comment:15 @chriscct75 weeks ago

  • Component changed from Import to WordPress.org site
  • Keywords needs-patch added

comment:16 @Viper007Bond4 weeks ago

  • Component changed from WordPress.org site to Import

This is actually related to all importers, not just the Tumblr2WordPress one.

It'd probably make the most sense to handle this at the core importer level of ignoring any existing IDs if they're bigger than ones that we can safely store. That way each individual importer wouldn't need to have this logic.

Note: See TracTickets for help on using tickets.