Be Careful When Upgrading to WordPress 2.2 If You Have the WP-Cache Plugin — Adventures in Backing Up and Restoring WordPress Databases

by Tom Johnson on May 22, 2007
categories: technical-writing • wordpress

I spent a fun evening wrangling with WordPress 2.2. I attribute most of the trouble to the wp-cache plugin, because I kept receiving this exciting error:

Warning: fopen(/home/idrathe1/public_html/wp-content/cache/wp_cache_mutex.lock) [function.fopen]: failed to open stream: No such file or directory in /home/idrathe1/public_html/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 96

I've never had a problem with a mutex.lock!

After several more attempts to upload the 2.2 files, I decided future endeavors would be useless, so I restored back to my 2.1.2 version. Oh boy, here's where the fun starts.
I am very grateful for Podz's tutorials at http://www.tamba2.org.uk/wordpress/. They are mostly superb. I was nervous when I had to delete all my WordPress files and my entire database, leaving me hanging only with an exported .sql file of 3.5 megs. That's quite an interesting jumble of text to look at, by the way.

Here's what you see as you are dropping [deleting] all your database tables (image from Podz's tutorial):

Take a deep breath before you click Go. Well, of course I backed up my entire site in two different ways before deleting everything, but still, it's no fun to annihilate database tables.

However, there's an error in Podz's restore instructions. Instead of using the Import function, he says,

Open the .sql file in a text editor. Do NOT use a word-processor, or Dreamweaver or GoLive unless you REALLY know what you are doing - on a Windows machine WordPad is okay. ... You highlight some text, copy it, paste it into the SQL window, click Go and after the Success message, you do it again with the next chunk of text..

After I opened the .sql file in WordPad and copied it into the SQL window, I had some strange characters that appeared in my posts, namely these: ’ �. It's an encoding issue that happened in the restore, since the Podz tutorials said it was okay to paste content from WordPad into a SQL text box.

I went to bed thinking I'd have to fix each post individually -- this would have taken hours.

In the morning I woke up and checked the support forum, where I had asked for help with the strange characters. Lelion wrote:

This is a problem with incorrect encoding... WordPad is not the best choice when restoring databases :-(

Better use Dreamweaver, which supports various encodings, and copy -> paste from it. Or any other editor, which supports UTF-8, and many other encodings... I can't say if there's a way to automatically fix the wrong characters in the database.. If you keep the original MySQL backups/files, better open them with the correct editor and make the copy paste again:)

I started to wonder why I didn't just open the .sql file in Notepad ++. Or maybe Podz's method wasn't as easy as the Codex tutorial, which listed the following steps:

1. Login to phpMyAdmin.
2. Click databases, and select the database that you will be importing your data into.
3. You will then see either a list of tables already inside that database or a screen that says no tables exist. This depends on your setup.
4. Across the top of the screen will be a row of tabs. Click the Import tab.
5. On the next screen will be a Location of Text Filet box, and next to that a button named Browse.
6. Click Browse. Locate the backup file stored on your computer.
7. Make sure the SQL radio button is checked.
8. Click the Go button.

Sure enough, the Codex restore method worked, and it didn't have the strange characters. It's amazing what a night's sleep does for troubleshooting.

Reflections on the Shortcomings of Open Source Models

This experience made me reflect on some serious shortcomings of WordPress for novice users. I consider myself a power WordPress user, but when it comes to dropping database tables, selecting the right check boxes in phpMyAdmin, and trying to understand problems that start with wp_cache_mutex.lock, I think WordPress becomes too esoteric. People don't want to wade in code, especially when so much is at stake.

For example, when backing up your database, you have to select from among the check boxes in the image below. If you've not worked with databases before, these choices look foreign.

WordPress developers have to make upgrading painless. However, this raises an issue with open source software. The developer behind the wp-cache plugin ran out of steam and stopped development on the plugin a few months ago. As WordPress continues to develop, it requires changes in the wp-cache plugin and dozens of other plugins like it. Each plugin and theme must keep pace with the ever evolving, rapidly changing WordPress core.

That's partly why it's such a hassle to upgrade WordPress, because you never know what plugin or theme the new version is going to break. One solution is to minimize plugins and stick with mainstream themes. But if you take away plugins and theme variety, you might as well use one of the second-rate, boring blogging platforms.

Another Revelation: Comment Spam Continues Even When Your Site's Broken

Here's another interesting revelation I had during the two hours my site was down: comment spam kept arriving every 10 minutes even though there was no possible way to even see any posts on my site. I assume comment spam bots work at the file level, slamming the comment.php file with requests.

More Lessons Learned

Although deleting and restoring a database and all my WordPress files isn't fun, I now feel more confident about the whole backup and restore process. If you don't have Skippy's back-up plugin already integrated into your site (it is now included by default with installations), be sure you have it. Go to Manage > Backup and make regular back-ups. You can also set up a ...

Wait, in searching for the wp-cron plugin, which will automatically run a regularly scheduled backup, I found this note from Skippy:

I have officially discontinued support for all of my WordPress plugins. Over the past couple of months I've continued to receive questions about the plugins, so I thought I'd write here, once and for all, the authoritative explanation. All old links to the plugins should direct to this post, so now most folks should be made aware of what's going on.

I'm focusing on Habari for now. My more popular plugins have found new homes, to which I have linked below.

Even Skippy has fled the scene. This means that when WordPress 2.3 or something comes along, someone else must ensure that all his plugins continue to be compatible with future WordPress upgrades. Skippy's plugins include:

• cat2email
• sdm_comment_auth
• gravatars (new home: http://zenpax.com/)
• impostercide
• in-series
• not-to-me
• sdm_moderate_authors
• sdm_spam_check
• subscribe2 (new home: http://subscribe2.wordpress.com/)
• vhost
• wp-cron (obsolete in WordPress 2.1+)
• wp-db-backup

I'm guessing that many people have these plugins integrated into their sites already. When something goes awry in a future upgrade, maybe they'll find this post.