Several of you have probably already upgraded to WordPress 2.6, or are getting ready to do so. I’ve used it on my test server for a while (even when it was in the alpha development stage), and basically it is a good upgrade. But, it has at least one “feature” that may surprise you, and could disappoint you, if you are like me.
Here’s the scoop: WordPress 2.6 introduces “revisioning” to posts, so that every revision you make to a post is saved, and so that you can select from these various revisions which one you want to publish. In theory, it sounds good. In practice, it can add a lot of (unnecessary) data to your WordPress database.
For example, when I was using an alpha version of 2.6, I was using it on this live server, and was editing posts to my heart’s content. It is common for me to edit a post several times before I publish it. Unfortunately, I did not realize that this practice was growing my database, until I looked at my database one day. Here is a typical cross-section of what I saw:
Basically, for the post that began with Have you ever caught, there is about extra 40KB of revisioned material. Now, I know that is not a lot, but if you have that for a hundred posts, it can really add up. (By the way, the 40KB applies only to the post table … other tables are also involved.)
The problem is, WordPress does not give you a way to delete the old revisions. Maybe in time the WordPress gods will actually add the code to do this, if enough people complain about it. Maybe. In the interim, you could manually edit the database, but I am reluctant to do so, because I am not sure what other tables might be involved, and do not want to get the tables out of sync.
What you can do, though, is add the following lines to your wp-config.php file, right after the define ('WPLANG', ''); declaration:
define ('WP_POST_REVISIONS', false);
define ('AUTOSAVE_INTERVAL', 600000);
That will prevent revisioning.
Update: Andrei provides an SQL query for eliminating revisions that are already stored in your database, and it nicely handles all appropriate SQL tables:
DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'
It was great of him to share this, and it has worked nicely for me. Note that the biggest cleaning effect comes from getting the revision material out of the wp_postmeta table, but it is also important to clear out the related rows from the wp_term_relationships table, too, and Andrei’s code does that.
Anyway, to the second item: I noticed in my server logs that there were a lot of 500 error codes being returned by Apache. In almost every case, the code was returned when wp-comments-post.php was invoked:
"POST /wp-comments-post.php HTTP/1.1" 500
Since real comments were getting through without an error code, I figured this must have something to do with one of my spam-related plugins.
Well, after disabling various plugins for a few days and doing further testing, I narrowed it down to the Math Comment Spam Protection Plugin. When that plugin is disabled, the 500 errors go away. But, the spam that Akismet has to deal with goes up by a huge amount, increasing the number of spam-classified-comments I have to look through (to ensure no real comments are in there).
Now that I have found “the problem,” I will reactivate the MCSP plugin. I now know from my testing that only spammers are receiving the 500 error codes, and I could care less what happens to them.
So, that’s my little educational session for the day. I look forward to your feedback.