Make WordPress Core

Opened 6 years ago

Last modified 23 months 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)

#1 @Viper007Bond
6 years ago

  • Description modified (diff)

#2 @Viper007Bond
6 years ago

  • Description modified (diff)

#3 follow-up: @lloydbudd
6 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 permalinks after migration using the big postid.

Version 0, edited 6 years ago by lloydbudd (next)

#4 @daniloercoli
6 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)).

#5 @josephscott
6 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.

#6 follow-up: @josephscott
6 years ago

  • Cc josephscott added

#7 in reply to: ↑ 3 @Viper007Bond
6 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.

#8 @westi
6 years ago

  • Cc westi added

#9 in reply to: ↑ 6 @daniloercoli
6 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.

#10 @nacin
6 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

#11 @duck_
6 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

#12 @noahcoad
5 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

#13 @noahcoad
5 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).

#15 @chriscct7
2 years ago

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

#16 @Viper007Bond
23 months 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.