Posts Tagged ‘import’

How to export your Diaryland posts

July 11th, 2011

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.

Two ways to restore a WordPress blog: Database restoration and XML import

August 4th, 2010

You rarely ever want to be in a crash, be it a car crash, a market crash, or a blog crash. But if you are, first is covered by car insurance, the second is covered by the media, and the third is covered by me.

Recently, I had a client who needed to restore two blogs after her server crashed a few months prior. The server was home a personal site and a popular television fan site. A backup of both blogs exited, but due to various issues, she wasn’t able to obtain those files right away. The personal blog was put on hold for the time being, but the television site needed to come back online right away. Being a tech savvy client, she set up a fresh WordPress installation on a new host and kept the television blog going until she got the backup files from the old server.

When the client contacted me to restore her old entries, I realized we’d have to take different approaches to how we restored each blog. The personal site didn’t have any new data since the crash, so the simplest approach was to just restore the database for that blog. The television site required me to merge the old data (which included posts, comments, links, and tags) with the new data.

Not as simple as it looked. (The trouble with prefixes.)

The personal site sounded like an easy fix, but of course it wasn’t. The client had tried restoring the personal site’s database herself, but when she went to her blog she was faced with the WordPress installation screen instead of the posts and comments she expected. At this point she decided to call me for help.

I took a look at the database using PHPAdmin and realized that the tables in her WordPress database were missing the “wp_” prefix that is used by default. You can adjust the settings in the wp-config.php file to use whatever prefix you choose on your tables, or to get rid of the prefix completely, which appears to be what happened here.

To solve the problem, you can do one of two things. You can edit the wp-config.php file so there is no prefix. Or you can add the prefix to all the tables, as well as make edits to some values in the wp_options and wp_users tables as described here. Once I made the adjustments, the site was back up and running like it had been before. Plus, I got to feel like a magician!

Merging the old blog with the new

Next, I had to take on the trickier blog restoration. First, I set up a fresh WordPress installation on my development site and hooked it into the database the client provided me. The database was rather large, so I used Big Dump to import it quickly. I then I opened PHPAdmin and edited the site address in the wp_options table to match the address of the development blog. Then I was able to log into the site using my client’s old credentials. (NOTE: If you try viewing the WordPress blog at this point, you’ll probably see a blank screen because the template selected in the database doesn’t exist in your WordPress installation. Select a different theme and then you’ll be able to see the site.)

From there, I exported the blog using WordPress’s built-in export tool under Tools -> Export. This created a huge XML file of all the posts, comments and tags that I could import to the newer version of the blog, thus merging all the information. The XML file was a rather huge 60mb, which would most likely cause WordPress to timeout if I tried uploading it all at once. So I used WordPress splitter to divide it into 5mb files instead. Late that night, when web traffic was lighter, I imported each of the XML files into the client’s current blog. For a finishing touch, I exported her old WordPress links and imported those into her site as well. The process took about an hour to complete, but all her data was restored.

All’s well that ends well

The client was very happy with the end results. I was glad that I knew two different ways to restore WordPress blogs and knew which one fit each situation best. A straight-up database restoration is by far the quickest way, when it works, taking only a few minutes instead of the hour the XML import required. However, if you’re uncertain of your database’s integrity, like you might be if your site had been hacked, the XML import is a safe way to go too. The XML import doesn’t allow you to import any of your plug-in settings and other general settings though, which is another downer. I hope you never have a server crash, but if you do, hopefully you’ll now know how to recover from one.

Movable Type to WordPress: A migration slightly less painful than the Trail of Tears

January 25th, 2010

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.

Movable Type export

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.

Movable Type Import

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:

Movable Type Import Utilities

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.

Htaccess tool

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!