Big Trouble in Little Database (Size)

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”;
DELETE FROM wp_comments WHERE comment_approved = “spam”;

DELETE FROM wp_commentmeta WHERE meta_key
LIKE “%akismet%”

DELETE FROM wp_commentmeta WHERE comment_id
SELECT comment_id
FROM wp_comments

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:

Death, Taxes, and… Web Designers

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: