Background

I’ve been happily running this site on Textpattern (version 4.2.0) for a couple of years now with no issues or concerns. It has been a solid platform and I found a good template which I was able to customize to my liking. Recently, however, my wife has expressed interest in starting her own blog (more on that to come), and she wanted to use WordPress primarily because she had used it before.

Over the past couple of months, I’ve been working a lot with WordPress in support of Lori’s effort to bring her blog to life. We’ve been running an internal development site during that time to find the right theme, customize that theme, play with different post presentations and build some content prior to launching. She’s very serious about taking this blog live, so I figured I should probably get serious about learning as much as I can about WordPress.

This post is all about my experience converting from Textpattern 4.2.0 to WordPress 3.0.4.

Finding a Theme and Testing Migration

The first thing I did was install WordPress 3.0.4 on my internal server so I could play with different themes and test migrating my old content. Since I’ve been doing a lot more photography recently, I tried to find a photo-centric theme. After looking at four or five different themes, I settled on F8 Lite by Graph Paper Press. I’m a big fan of its clean, simple grid presentation and the focus on photography.

During my initial testing I discovered that the standard process for creating a child theme under which to make your customizations did not work. I’ve not figured out why it breaks, so for now I’m working with a full copy of the original theme. I’ll have to keep track of what I’ve customized so I can re-apply those customizations when an updated version of this theme comes out (hopefully that won’t be often).

Another issue I found while researching migration from Textpattern to WordPress is that the built in tools for Textpattern migration have been broken for quite some time. Some people have developed some work-arounds, but it seemed the process was hit or miss depending on the versions of each platform in use. I noted, however, that there was a generic import tool which would utilize the old site’s RSS feed to import posts. I tested this out and it worked very well. All the post content was imported (some caveats on that later) and only some minor formatting issues were introduced.

After playing with the F8 theme and my imported content for several hours I decided to go ahead and start the process of migrating my live site.

Migration Preparations

Any successful migration starts with a full backup of the old site so you can restore it should something go horribly wrong. Textpattern, just like WordPress, is a MySQL/PHP based site, so there really are just two things to back up: the database and the site files.

First, I backed up the database with the following:

mysqldump -u root -p txp_database | gzip -9 > 20110116_textpattern.sql.gz

Breaking that down, I called mysqldump with a root account, prompted for that user’s password (-p) and dumped the database called txp_database. Since mysqldump outputs to standard out, I piped that through gzip with -9 for maximum compression, then re-directed it into the final file. I like to put the date as the first part of a backup filename so it is easier to distinguish later if I have a bunch of backup files in the same location.

Next it was time to back up the textpattern site files. This contained all the PHP code plus all of the customizations I’d made to that code and the site graphics. After changing to the directory under which all this lives (varies by server configuration, but could be /opt/textpattern or /usr/share/textpattern) I then issued the following:

sudo tar -czvf /tmp/20110116_textpattern_files.tgz ./

Breaking down this sequence, I escalated my privileges to root with sudo, issued tar to create (-c) a compressed (-z with gzip, use -j for bzip2), with verbose output (-v), file with the given name (-f) containing the contents of the current directory (./). Note that I placed the output file in a different location than the current directory to avoid any problem with the tar process trying to recursively include its output file in the input. It would also be a good idea to move both the MySQL dump and this backup file to a common location for safe keeping — leaving either under /tmp is a bad idea because some systems clear the contents of that folder upon rebooting.

At this point, I could completely mess up Textpattern and I would be able to utilize the contents of these two files to restore it all back to its current condition.

Migration and Importing Textpattern Content

Once all the backups were out of the way, it was time to move the WordPress files and database from my development site to my “live” Web server. This was the tricky bit, as I discovered some of the initial setup was migrated with the database and there was no easy way to re-configure those settings. Most notably, the site URL kept re-directing me to my local dev site after I migrated the files. I ended up starting with a fresh copy of the database, but using my modified WordPress files. I had to re-configure the site and re-import the Textpattern content, but that was easy to do since I already had a dump of the rss feed.

First, I wrapped up my WordPress development files in a tar/gzip file, similar to backing up by issuing the following after changing to the root of the WordPress folder on my development server:

sudo tar -czvf /tmp/20110116_wordpress_files.tgz ./

I then copied that tgz file up to my server and uncompressed it to a WordPress folder by changing to that folder and issuing:

sudo tar -xzvf /tmp/20110116_wordpress_files.tgz

Next, I issued the following sequence to get into MySQL, then issue SQL statements to create a fresh database:

mysql -u root -p
create database wordpress;
grant all privileges on wordpress.* to 'wp_user'@'localhost' identified by 'wp_password';
quit

Breaking that down, the first line opens a MySQL command prompt with root privileges. The next line creates the wordpress database. The third line simultaneously creates the user ‘wp_user’ with the password ‘wp_password’ and grants that user full access to the wordpress database. The last line quites the MySQL interface.

At this point, my old Textpattern site was still live, but I had to configure the WordPress site. I decided to quickly switch over to the WordPress site and finish up the configuration. To do this, I simply had to edit my /etc/apache2/sites-available/default file so it pointed to the location of the WordPress site instead of the Textpattern one. All the rest of the settings in that file remained the same.

Once that was done, I hit the wp-admin URL to complete the site setup and create a site administrator user account. I then logged in as the site administrator and fired up the rss-importer plugin, which I had already installed as part of my development site, and it came over when I copied those files. But first, a word on getting that RSS content out of Textpattern. . .

The rss-importer plugin takes as its input an RSS XML file. In order to generate such a file from Textpattern, I had to go into the site settings and set the RSS feed to present all of my posts in the feed and set it to place the entire contents of each post in that feed. Once that was set, I visited the site and right-clicked on the RSS link, saving that link as a file called rss.file. Within my WordPress development site, I was then able to upload the contents of rss.file into the rss-importer plugin. Here are my caveats about this method and why it worked for me, but might not work for you:

1. My Textpattern content was all code/text. All of my images were hosted from my Flickr account. I don’t believe site embedded pictures would have transferred with this method.
2. There is a 2 MB file upload limit in WordPress. I only had 108 posts in Textpattern and the RSS XML file was under 500 KB. I believe you can increase the 2 MB limit, if needed.
3. The import wasn’t perfect. Some formatting was lost. I spent a significant amount of time going through each of the 108 posts and adjusting the formatting. A better import method may have preserved this formatting.
4. The categories did not import either. I had to go through all posts and assign categories and tags. I’m not sure if any of the other import methods would preserve categories. I wanted to re-work these anyway, so this wasn’t a big loss.

Aftermath and Conclusion

So, yeah, I had to touch every post and fix some formatting. I also had to set up new Categories and set tags on each post. Good thing I’m not a terribly prolific blogger, or I would have had some tough choices to make. As it was, 108 posts weren’t too bad. The later posts were more complex, requiring more attention. As the posts got older, there was less to do, so the last half to one quarter went a lot quicker.

Overall, I’m happy with the look of the site and the way this theme integrates with WordPress. As mentioned before, I still need to work out the child theme issue, but hopefully I can figure that out in my development site soon. I’m also going to dig into the CSS of the site and change up some of the colors. I don’t like the red article link headers and hyperlinks, and I want some of the fonts to be just a bit larger.

My work on this site will never be done, but that is the way of the blogger. . .