Hello!  I’m Dax and I do most of the programming here at 3 Dog Media.

After the Wordpress 2.8.1 upgrade, the built-in gallery feature stopped working.  Here’s how to recreate the error:

1. Go to Posts > Add New.
2. Click the Add media button and upload a file.

After uploading the file, a new tab should appear on the Add Media frame that says “Gallery(1)”.  That gallery will stay with your post after you save it.  After upgrading to 2.8, it does not and your gallery changes are lost until you save the post for the first time.  However, if you repeat the steps below with one small change, the gallery works as expected.

1. Go to Posts > Add New.
2. Click “Save Draft”.
3. Click the Add media button and upload a file.

The gallery will also work like normal when editing a post that has already been saved.  As you can guess, unless you know exactly how to recreate it, this could be a difficult bug to identify properly.  The gallery feature is used infrequently and when it is, it’s an afterthought or the culmination of a post that has been saved multiple times.

Here’s how to fix the bug.

For Wordpress single install:

$wpdb->query(“ALTER TABLE wp_posts CHANGE post_parent post_parent BIGINT”);

Stick that in your /index.php file after the line:

require(‘./wp-blog-header.php’);

Then log into your blog.  That should do it.  Delete that line from your index.php file afterwards.

For Wordpress MU:

Create a new file in your root directory “fix.php”, and put the following code in it.

require('./wp-blog-header.php');
$count = 1;
while($count < 2000){
 $wpdb->query("ALTER TABLE wp_{$count}_posts CHANGE post_parent post_parent BIGINT");
 $count++;
}

Then load yoursite.com/fix.php  Nothing will appear, but it should be fixed.  If you have more than 2000 blogs, use a different number.  You probably don’t.

There are cleaner ways to fix this error, but if you are capable of doing them, then you can figure them out from the code above.  I wanted to make sure even the most casual user could fix their blog.

WHAT WENT WRONG

In the WP system, posts, pages, and images are all stored in the same database.  To tie images to posts, thus enabling the gallery feature, and to assign child pages to their parent pages, WP uses a database entry called “post_parent”.  Think of it as a number that links a page or an image to the page or post it belongs to.  Think of it like that because that’s exactly what it is.  If you upload a bunch of images to a post and create a gallery with them, the database will have an entry for each of those image files with the post_parent of that entry set to the ID of said post.

Now why did this stop working for new, unsaved posts?

In previous versions of WP, the post_parent field was a BIGINT.  A BIGINT is a number that uses 64 bits of storage space.  That means the post_parent field had an upper limit of 2^63.  That’s the biggest number it could be.  If you had more than that many posts on your blog, the WP gallery and parent/child relationships would start breaking down because you would have run out of numbers.  That might sound bad, but even if you blogged every second of your life from the day you were born, you would need to live to 292,471,208,677 years old to break your BIGINT ceiling.

Now, you may be wondering why a 64 bit number has a limit of 2^63.  Why isn’t it 2^64?  When dealing with computer integers, the last bit is usually reserved to save the “sign” of the number — whether a number is supposed to be positive or negative.  That gives normal BIGINT’s a maximum of 2^63 and a minimum of -2^63.  That negative “sign bit” is important when doing calculations, but seems useless for keeping track of things like people and posts, right?  Not in this case.

In WP, any post or page that is not yet saved is assigned a temporary negative ID number until it is saved.  By using temporary negative values, the database isn’t filled with useless post ID’s every time you load the New Post page.  For some reason, in the latest WP upgrade, this BIGINT was changed from a signed BIGINT to an unsigned BIGINT.  The maximum number of posts increased to 2^64, but because of it’s lost “sign bit”, posts could no longer have a negative post_parent.  In changing it, WP broke the ability to add a gallery to a new, unsaved post.

It was probably changed to increase the theoretical maximum number of posts a system could support.  However, I think the WP core would break down because of the autoload options table way before then.  If you’re concerned about the number of posts in your system, a better way to cut down on them is to turn off the WP revisioning system by putting the following line in your wp-config.php

define(‘WP_POST_REVISIONS’, 0);

The BIGINT change probably broke a number of plugins as well.  I know we have several that use the negative temporary pre-save ID of a post.  Users should be able to treat new posts just as they do saved posts.

Hopefully this was helpful to anyone dealing with this bug, or at least was interesting to anyone who cares how their CMS works.  There is a lot of information in here that programmers already know, but since more and more casual users are programming with WP plugins and themes every day, I think everyone could benefit from some computer science fundamentals that explain the architecture of the system instead of just how to make things show up.