So, you visit your WordPress blog and all you get is a blank white screen. You can’t log into WordPress either. This is when you freak the *$!@ out.

Don’t panic! It may look like your blog has been deleted, but all the data is probably still there. The White Screen of Death usually appears when you have a problem with a theme or plugin. To fix the problem, you need to log into your server and rename the folder that contains the malfunctioning theme or plugin. This is a process of trial and error, so keep renaming folders and refreshing the blog to see if it’s fixed.

Once your blog is back, try renaming the folder to its original name. Usually whatever was wrong will have righted itself. If not, delete the plugin (after backing it up) and try reinstalling it with the latest version.

The White Screen of Death always terrifies people, but it’s one of the easiest WordPress problems to fix. Clients are never more grateful than when I magically recover their blogs this way. By far, it has the biggest reward to work ratio of any problem I solve.

If you are interested in my Diaryland to WordPress conversion service, you will need to get a copy of your Diaryland entries. Instructions on how to do that are included below thanks to Weetabix!

1. Log into the Diaryland account that you want archived.
2. Look at your Profile. That will tell you exactly how many entries that account has posted. I charge $0.10 per entry to be imported.
3. If you’re no longer a Gold member, then pay for a 3 month Gold membership (it’s $12) which is the cheapest tier, and then wait an eternity for Andrew to flip the switch on your account and send you the email that you’re Gold again.
4. Go to the Gold Member resources.
5. Select Download Diaryland Backup or something like that. That will trigger a giant file that may take a very long time to build. When it finishes, save that file as an .html on your harddrive. It might be helpful to rename it (YOUR NAME) Diaryland Backup.html.
6. Send it to me (via my email address on the contact page) along with your WordPress admin address and log in information. I’ll invoice you for half the fee before I start and the other half once it’s complete.

When I started blogging on my own self-hosted site in 2003, PastaQueen.com, I chose to install the Movable Type blogging software. At the time it was one of the best blogging platforms available, plus it was free. It was also written in Perl, a programming language I was using at my day job at the time. Using Movable Type helped me develop my professional skills as I learned how to install and manage the software.

Now it’s 2010, I no longer program in Perl, and Movable Type is no longer my blogging platform of choice. Over the past several years, WordPress has made great strides to become a free, easy-to-use software package with a lively community of devotees and open source developers–emphasis on easy-to-use. After working with both Movable Type and WordPress, the latter beats the former in all areas. It’s insanely easy to install and update. A developer has probably already written a plug-in for any feature you might desire. And WordPress’s template files are much easier to read and manage than Movable Type’s.

I’ve thought about switching my blog, PastaQueen.com, from Movable Type to WordPress for over a year now, but the thought of transferring over 5 years of archives intimidated me. I was afraid of losing PageRank and search engine links if I failed to redirect my entries properly. However, after a spam attack at the end of 2009, the pain involved in transferring the site seemed worth the pain it would save me via WordPress’s superior spam-filtering abilities.

Here’s a step-by-step guide to the process I went through to transfer over 1000 entries and over 27,000 comments from Movable Type 4.2 to WordPress 2.9 on my blog, PastaQueen.com. Hopefully it will help anyone else out there brave the process of migrating their site from Movable Type to WordPress.

1) Backup everything

First, backup everything. This includes your Movable Type database as well as any images or other media you’ve uploaded to the blog. If something goes wrong during the migration, you’ll be happy you did.

2) Export your entries from Movable Type

Movable Type has a built-in feature to export your blog as a text file. Go to Tools -> Export and click the Export Blog button. At the prompt, save the text file to your hard drive.

3) Import entries to WordPress

I installed WordPress on the same domain as my blog, but in a different folder. Later on, I set up a redirect to point all the old pages to their counterparts on the new page. You can install your new WordPress installation wherever you like, but once you do, go to Tools -> Import and click on Movable Type and TypePad. After you install WordPress, make sure you update it to the latest version.

If you have a small amount of entries, you can use the upload option to import the data. My exported text file was 15.2mb which would have caused the upload to time out. Instead, I used FTP to send the file renamed at mt-export.txt to the /wp-content/ folder as directed.

The importer will then ask you if you want to map a user from Movable Type to an existing WordPress user, or if you want to create new users. After that, WordPress will start importing your comments and entries. In my case, it would time out after the server memory met its maximum limit.

There are two ways to proceed from here. If you have a text editor which handles large files, you can splice the file into smaller pieces that are smaller than your server’s memory limit. However, I was uncertain if I could simply splice the mt-export.txt on any line, since there may or may not be important information above the splice point that I didn’t want to cut out.

It seemed safer for me to just repeat the import process with the same 15.2mb file. Because the importer was smart enough not to import the data it had already imported, it was able to get farther through the process before the memory timed out. I kept repeating this process until everything had been imported. It was time-consuming, but I wasn’t in a time-crunch situation, so I chose caution over speed.

3b) Modify mt.php if your Movable Type entries were set to “Format: convert line breaks”

When I imported my entries, I was puzzled to see that where there were supposed to be two line breaks denoting a new paragraph, there was only one line break. This made my blog messy and hard to read. After some research, I learned this was happening because I had written my Movable Type entries with the Format drop-down set to “Convert link breaks.” When the entries were imported, WordPress did not translate this formatting correctly.

Luckily, there is an easy fix that I found on the site On a Lark. Open up wp-admin/import/mt.php and replace this line:

// Processing multi-line field, check context.

if( !empty($line) )
$line .= “\n”;

with this:

// Processing multi-line field, check context.

if( !empty($line) )
$line .= “\n\n”;

After I changed the importer, I deleted my WordPress installation and reinstalled it since this was faster than deleting all the poorly formatted entries and comments. I then uploaded the modified mt.php and imported my entries with the correct formatting.

4) Use Movable Type Blog Import Utilities to import tags

The WordPress importer script has one major flaw: it doesn’t import your tags. Tags are an important part of my site structure and I didn’t want to retag all my entries. Instead, I used the Movable Type Blog Import Utilities written by Simone Carletti to bring them over.

I downloaded the mt-utils.php file and uploaded it to the wp-admin/import/ folder. Now when I went to the Tools -> Import page I was presented with another option:

I clicked through to get to the tag importer, which required me to create a new template in my old Movable Type installation that would generate a text file I would use to import my tags. I did so, saved the text file and uploaded it according the tag importer’s instructions. Then I was greatly befuddled when it didn’t work.

Then I realized that my previous editing of the mt.php script had caused the tag importer not to work because it was trying to match the body text of the Movable Type entry with the body text of the WordPress entries. My WordPress entries had an extra line break inserted into them, causing a mismatch. To make the mt.php script work I found this line:

foreach($posts as $post) {
if ($postId = post_exists($post->title, $post->content, ”)) {

and replaced it with this:

foreach($posts as $post) {
if ($postId = post_exists($post->title, ”, ”)) {

Then I found this line:

} else if ($postId = post_exists($post->title, $post->content, ”)) {

and replaced it with this:

} else if ($postId = post_exists($post->title, ”, ”)) {

I tried importing my tags again and this time it worked.

5) Translating my Movable Type templates to a WordPress theme

Next, I had to go line by line through my Movable Type templates and translate them to a corresponding WordPress theme. I had to pay particular attention to what URL each link and image was pointing to and update it to the new folder on my site where WordPress lived. I also had to install some WordPress plug-ins to make some items in my sidebar functional, such as my Recent Posts widget.

This was the most time-consuming part of the process. I chose to do it after I’d imported all my entries so I could make sure everything would display properly with the actual content in it. I chose to leave any images I’d uploaded for posts in my old directory structure since I didn’t want to update every post to point the images to my new WordPress folder.

After the theme was complete, I double-checked all the pages from the archives, search pages, tag archives, and home page, etc. Now we were ready to launch!

6) Setting up redirects and launching!

Because my WordPress entries were in a different folder than my Movable Type entries, I needed to redirect the old posts to the new posts. I wanted to do this without breaking any links, especially any links from search engines. The best way for me to do this was to use the htaccess tool in the Movable Type Blog Import Utilities.

Again, I went to Tools -> Import and clicked on the MT Blog Import Utilities, this time going to the htaccess tool. Again, I had to add a new template on my old Movable Type installation to create a text file I uploaded to the utility. Once I did this, the utility generated code that I pasted in the .htaccess file that lives in the root directory of my old blog. This file can be used to tell search engines and browsers that a page has moved. I had to do some slight tweaking to the Movable Type template to get my URLs correct, but once I did, I was extremely happy with the results! I updated my htaccess file with the results and voila, the new site was launched! I double-checked the htaccess file by trying to access some of my old Movable Type generated files, and each time I was redirected to the WordPress version immediately.

7) Other items to consider

Each blog installation is unique, but another thing you might need to redirect are your site feeds. I added lines to my htaccess file that redirected my Movable Type feeds to the new WordPress feeds. Both Google Reader and Bloglines adjusted to the change seamlessly.

For now, I still have my Movable Type installation on my server, just in case I realize I need to move something over that I’ve forgotten. After a few more weeks I’ll probably back it up and then take it down.

Conclusion

Moving my Movable Type blog to WordPress took the better part of a weekend. I’m very glad I made the change though. Overall, it was slightly less painful than I imagined it would be, but I imagined it would be like chewing on a porcupine. The Movable Type Blog Import Utilities saved me a lot of time since the redirects were the part of the process I dreaded most. Thank you to Simone Carletti for writing those and making them publicly available.

If you too make the move from Movable Type to WordPress, your unique blog installation might run into issues that I didn’t have here. Hopefully the vast resources on the Internet will be able to help you through any situation. Good luck!

There comes a time in every self-hosted WordPress blogger’s life when they will see this:

WordPress updates are like dentist appointments and oil changes, annoying yet necessary. You’ll get cavities and car problems if you don’t get checkups, and you’ll endanger the health of your blog if you don’t update WordPress.

Why do I need to update?

Think of your blog as a castle you need to defend. Inside the tower are all your precious blog entries. Outside the stone walls is an army of hackers, spammers, and other nasty people who at any time might launch an attack on your blog. The developers of WordPress know about your enemies, so they’ve built defenses like moats and drawbridges to keep them out.

Despite these obstacles, occasionally a hacker finds a weakness in your defenses and breaks into the castle. They might find a lose stone in the wall or find a way to dig under the castle into the courtyard. You can defend you blog from 99 different types of attacks, but it only takes that one hundredth unprotected way to allow someone to break through.

The developers of WordPress don’t just hang around the great hall eating slain deer. When they become aware of a new type of attack, they patch the vulnerability in their software and issue a new release. That’s when you get the message on your dashboard asking you to update. If you ignore it, you are making your blog more vulnerable to attacks.

Different types of updates

Each WordPress update has a release number, like 2.8 or 2.8.2. These numbers give you information about how major the update is, as well as give the developers a way to track what changes were made in which releases. The farther the number is to the left, the more serious the update is.

If the first number has changed, like from 1.0 to 2.0, this indicates a major change in the software. The developers might have rewritten major parts of the code or restructured how it works internally. This type of update can sometimes be tricky to handle since it usually involves updating your database or the way your files are structured. You should back up your blog before any update, but especially before this type of update.

The second number, or rather the first number after the dot, refers to a less major, yet still significant update to the software. It indicates that there have probably been some minor bugs fixed or a few small features added. You’re less likely to have problems when doing this type of update.

The third number, or the number after the second dot, refers to a small change in the software. This type of update is usually only released when a bug or security vulnerability needs to be fixed right away. Otherwise, they would wait to include the changes in one of the other types of updates.

Backup your files

You should always backup your WordPress blog before initiating an update, just in case something goes wrong. You can do this several different ways.

CPanel
If your host uses CPanel, you can create a backup through that interface by going to http://yoursite.com/cpanel and entering your username and password. There is an icon titled “Backups” that you can click to guide you through the backup process. Make a full site backup and download it to your computer. Also, open the file after you’ve downloaded it to make sure you have everything.

WordPress Plugins
If you don’t have CPanel, there are two WordPress plugins available that will create backups of your site. The WP-DB-Backup plugin backs up your database. Your database contains all the entries, comments, and other settings related to your blog. However, it does not include any images you have uploaded or any of your site’s themes or plugins. The WordPress Backup plugin saves copies of these files for you. You can have the backups emailed to you, or store them in a zip file on your server. Please note, if your web host’s server breaks down, you won’t be able to access any backups stored there. For that reason, it’s always wise to retain a copy on your local computer.

FTP backup
If neither of the options above are available to you, you can log into your site via FTP and download your blog directory to your computer. It’s slow and not the most efficient method, but it will suffice. If you don’t know what FTP is, you shouldn’t be backing up your blog this way anyway.

Updating WordPress

Ever since WordPress 2.7, it has become very easy to update your site. Log into your WordPress dashboard and go to Tools -> Upgrade. You should then see this screen:

Click on “Upgrade automatically” and you’ll see a screen where you’ll have to enter your web host login information. After you’ve entered this information the first time, it will be saved and you’ll automatically be sent to the next screen, which alerts you that WordPress has been updated. That’s it! It’s easier than flossing.

If you are upgrading from a version of WordPress earlier than 2.7, you will have to update your installation manually. Unless you are technically inclined and are 100% sure you have a backup, this is best left to a professional.

Backups are great. Knowing how to use them is better.

Let’s say the worst happens and for some reason your WordPress upgrade goes, horribly, horribly, wrong. Good thing you made that backup! However, if you don’t know how to restore your blog using the backup, it’s not much use to you. Restoring a site can be complicated and is probably a task better left to your web developer.

Please update!

It is up to you whether your update WordPress or not, but ask yourself, how valuable is your blog? If a hacker were able to infiltrate and delete everything, would you be able to brush it off or would you be brokenhearted? If it’s the latter, keep up with the updates. It doesn’t hurt to floss either.