Fix incompatibilities with IDs greater than 2^31

[Viper007Bond]

For various reasons, things go bad when you get a post ID greater than 2³¹. 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.

[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.

[daniloercoli]

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

<methodResponse>
  <params>
    <param>
      <value>
        <struct>
  <member><name>dateCreated</name><value><dateTime.iso8601>20110203T23:32:58</dateTime.iso8601></value></member>
  <member><name>userid</name><value><string>1</string></value></member>
  <member><name>postid</name><value><int>2746722655</int></value></member>
  <member><name>description</name><value><string>.....

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)).

[josephscott]

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.

[Viper007Bond]

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.

[daniloercoli]

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.

[duck_]

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

[noahcoad]

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

[noahcoad]

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

[SergeyBiryukov]

Related: #22845

[Viper007Bond]

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.