All posts show as (no title) after migration

[mark.waters]

1. I have multisite wordpress 4.0 installation setup in a 64bit debian vm.
2. I would like to move it to a low power server , like a banana pi.
3. I use mysqldump to dump the entire database to a file.
4. I setup a 32bit debian vm or banana pi server using bananian distro with all the requirements - php5 , mysql , etc.
5. I rsync the whole wordpress application from source to destination , set correct file permissions.
6. I create the mysql wordpress user and database and import the mysqldump file from step 3.
7. All posts show as "(no title)".
8. If I create a new 64bit debian vm instead it all works perfectly.

Previously on the forum - ​https://wordpress.org/support/topic/all-posts-show-as-no-title-after-db-restore?replies=8

[johnbillion]

What do the posts in the wp_posts database table look like? Are the titles present? What show up on the editing screen when you edit a post?

This is probably an issue for the support forums.

[mark.waters]

The wp_2_posts table looks fine , the 32bit and 64bit tables look identical in phpmyadmin , titles are present.

In Wordpress's 'All Posts' page all the posts are shown with '(no title)' , if I click 'Edit' the page just refreshes , it doesn't take me into the usual post editor.

If I click 'Quick Edit' then the posts details drop down but all the details like Title / Slug / Tags fields are empty.
The correct Categories are shown but none are ticked.

Today I have also setup a new 32bit vm and used a new download of Wordpress 4.0 setup as multiuser instead of copying the previous installations files , this should rule out plugin and theme issues.

[mark.waters]

In the Apache2 error log I just saw this from when I clicked 'Edit' on a post :-

[Fri Oct 10 13:21:20.383323 2014] [:error] [pid 1313] [client 192.168.0.70:39567] PHP Warning: Creating default object from empty value in /var/www/wordpress/wp-admin/includes/post.php on line 567, referer: http://sub.domain.tld/markwaters/wp-admin/edit.php

[dd32]

What's the value of post_id for one of the affected posts?
The only difference between a 32bit and 64bit php install is that a 32bit can only handle numbers half the size that a 64bit can. Although in practice this is rarely hit, it could bf related (old bad plugins triggered it with storing tweet ids as post ids once though).

[SergeyBiryukov]

Replying to mark.waters:

In the Apache2 error log I just saw this from when I clicked 'Edit' on a post

The error message means that get_default_post_to_edit() failed to create a new post in the database​.

[mark.waters]

I am seeing the ID field of wp_2_posts at 4863165183.

Wikipedia shows that 2147483647 is the largest 32bit integer - ​https://en.wikipedia.org/wiki/2147483647#In_computing.

Looks like we have found the issue!
Woohoo!

Is there a way to get around this ?

[johnbillion]

Replying to mark.waters:

Is there a way to get around this ?

On a 32 bit system, no. If you need to maintain such high post IDs, then you'll need to move back to a 64 bit system.

That said, I would do some investigation into why you have 4.8 billion rows in your posts table without knowing about it. I suspect something incremented the auto_increment value at some point so it's jumped right up (and you don't actually have billions of rows). If not, then you may have a runaway process on the site which is populating the posts table (visitor hits, tweets, spam, etc).

Closing as invalid based on this. Hope you get it sorted!

[mark.waters]

Thanks you all for all your detective work and explanation , now I know why its happening and can plan around it.
Hope this also helps anyone else seeing the same error and wondering why.