I recently wrote about some WordPress trouble a client had that was related to the database size. I listed some SQL commands that can be run, but there are simpler ways to keep a WordPress database clean and optimized to avoid trouble like that.
It’s good practice to install a plugin like WP-Optimize that can perform the same tasks without the need for nitty gritty SQL commands. Not only will your database not fill up, but keeping your database optimized will also make sure your website / blog loads as fast as possible.
WordPress also has a feature called “revisions” that can unnecessarily clog up the database. You can only turn that off by diving into some PHP files on the web server, which isn’t for the faint of heart. For more information on doing that, head over here.
I ran into this problem a day ago; all users on a WordPress blog couldn’t login. They wouldn’t receive an error when entering the correct password, but they also wouldn’t login. Attempts to reset passwords also failed, even using the trick to reset the admin password via theme.php.
Eventually I found that the database was full. The client, on Network Solutions, was allotted 300mb and they were at 301. Not to fear! I found that running the following SQL commands directly in the database manager would do the job:
DELETE FROM wp_posts WHERE post_type = “revision”;
OPTIMIZE TABLE wp_posts;
DELETE FROM wp_comments WHERE comment_approved = “spam”;
DELETE FROM wp_commentmeta WHERE meta_key
DELETE FROM wp_commentmeta WHERE comment_id
NOT IN (
But alas, I found myself in a Catch-22. To remove the data deleted above, you have to optimize each table. But to optimize each table, there had to be more free space in the database! Some users have had luck calling their web host, and having them somehow clear out the old entries. This client in particular ended up buying for $4 per month an extra 700mb in database space.
Post title inspiration goes to the graphic novel and cult classic:
There aren’t many guarantees out there in the IT world, but I’ve found that without fail, web designers will ALWAYS manage to screw up MX records when doing work in a web domain’s DNS settings.
Last week for instance, I was told a client was getting a new website. I immediately warned them about the track record many web designers have when doing things like this. The client immediately emailed the web designer, in Australia, about being careful. The reply was as follows:
[Client XYZ] email records won’t be altered as we’re only interested in the web hosting information
Suffice to say, less than five hours later I saw this when doing an MX lookup to see if this web designer was any different than the others: