Now, bear in mind, there are decent scripts lurking in vendor/plugins/mephisto_converters that will do a reasonable conversion from either Wordpress→Mephisto or Typo→Mephisto. The problem that comes up, however, is the dichotomy between categories and tags. While I was still using Wordpress (which only offers categories and does not offer tags), I was basically using categories as tags. I never really did get into the whole semantic partitioning between categories vs. tags and find that tags alone satisfy my organizational mindset (meaning, complete chaos, but I digress.

I will not go into how to use these converters, as you can follow these instructions regarding converting from Typo→Mephisto. I imagine the conversion from Wordpress→Mephisto is quite similar, although I haven’t tried it myself.

But, given the aforementioned dichotomy between categories and tags, my previous migration from Wordpress→Typo correctly imported the Wordpress categories as Typo categories. However, for some strange reason, I decided once I started using Typo to only use tags and not categories. This resulted in about a year and a half’s worth of posts with categories but no tags, and a week’s worth of posts with tags but no categories.

I then proceeded to migrate all the posts from Typo to Mephisto (using the instructions I mentioned above.) Unfortunately, the migration script seems to only pick up one set of delineators (categories OR tags, but NOT both). And not only that, it munged the tags that I did have as described, joining them all into single supertags with embedded commas. Not exactly what most people want.

Since there were only 10 or so posts from the previous week while I was using Typo, I ended up just manually fixing all the tags. However, this left all of the Wordpress categories that did not survive the transition through two blog systems. I transiently entertained the notion of manually tagging each and every post, using a backup of my Wordpress database as a reference, but I soon came to my senses and decided to do this programatically.

The following is based entirely on the code from the above referenced website that fixes Mephisto tags based on Typo tags from the Typo database, except that I was fixing Mephisto tags based on Wordpress categories from the Wordpress database. You can just enter all of this at the ./script/console prompt:

require "converters/base" require "converters/word_press" WordPress::Post.find(:all).each do |wp| mp = Article.findby_permalink(wp.postname) wp.categories.collect{|c|c.cat_name}.each do |cat| Tagging.set_on(mp,cat) end end

This is just a quick outline of the steps I took, which I hope to fill in as time goes on.

This route is really circuitous, mostly because the migration script included with Typo is apparently very CPU/memory-intensive, and Dreamhost’s sentinel processes always ended up reaping it before it could even import a couple of blog posts. It also requires the installation of random pieces of software you probably won’t normally use on your local machine. Be forewarned.

NOTE: My desktop computer is a Mac Mini PowerPC G4 running at 1.25 GHz with 1 GB of RAM installed, running Mac OS X 10.4 Tiger. These instructions should be equivalent for an Intel-based Mac, and should be reasonably adaptable for Linux, BSD, or other UNIX/UNIX-like systems. Unfortunately, I haven’t run Windows since 1999, so I can’t really help you there.

1. Export your Wordpress database using whatever method is most comfortable to you. I used myPHPadmin which is available by default on Dreamhost. Transfer the resulting flatfile to your local machine.
2. Make sure you have MySQL running on your local machine. Of interest, MySQL is installed by default in the Server version of Tiger, although turned off by default. It should be pretty easy to install MySQL on any respectable Linux distribution. On the Client version of Tiger, while you can build mysql using Fink or MacPorts, the easiest thing (read: the thing that involved the least amount of thinking and/or compiling) was to just download the binary distribution from mysql.com. The stable version as of this writing is 5.0.
3. Install CocoaMySQL. Obviously, if you’re quite familiar with dealing with MySQL on the command-line, there’s no need to do this, but since I’m not, this was the easiest thing to do.
4. Import your database from Dreamhost into your local copy of MySQL
5. Make sure you have a functioning copy of Ruby installed. Tiger comes with an old version of Ruby installed, so I tried compiling the newest release with Fink. Unfortunately, there are still some issues with compiling Ruby using gcc 4. While it will build without problems, Ruby will segfault randomly when run. Since I didn’t really want to screw around with compiling with gcc 3.3 and making sure all the relevant dependencies would play nice, I ended up installing Locomotive, which lets you run Ruby on Rails applications in a sandboxed environment.
6. Install Rails. Again, Locomotive will take care of this for you, but if you’re running Linux, or you manage to get ruby correctly compiled on Mac OS X, you can just install the gem like so: gem install rails --include-dependencies
7. Make sure you have svn installed. Subversion, a version control system, is readily available on all respectable Linux distributions and can be compiled without incident on Mac OS X via Fink or MacPorts or even just from source.
8. Download typo via svn. You can pretty much install Typo anywhere you like. Once you’re in the directory (folder) of your choice, type: svn checkout http://svn.typosphere.org/typo/trunk typo (see the Typo Trac for more info about grabbing the trunk versus the 4.1 branch.)
9. Create a new database for use with Typo.
10. Configure Typo to use the new database Edit config/database.yml (relative to the directory you downloaded Typo to) so that it’s pointing to your new database.
11. Format the new database with Typo’s schema. I used rake db:migrate Other ways (not sure if this is up to date) are described on the Typo Trac. These should work just as well on your local machine as it does on Dreamhost’s servers.
12. Run the Wordpress 2 → Typo 4 converter script. (If you’re using Locomotive, at this point you’ll need to create a new project and point it to where Typo is living, and start it.) Type db/converters/wordpress2.rb --help for help with the syntax with converter.
13. Export the Typo database on your local machine.
14. Create a new database on Dreamhost for Typo.
15. Import the flatfile from your local machine into the database on Dreamhost.
16. Install and configure Typo on Dreamhost exactly as above. From what I can tell, Dreamhost now has a current enough version of Ruby (1.8.5) and Rails (1.2.3) to run Typo properly, but if you must have the newest versions of everything, you can build it all in your home directory.

At this point, you should be able to point your browser to your site and create an admin account. All your Wordpress posts will be there, although the converter script turns all your entries and all your pictures into separate blog posts.

Right now, I’m running Typo out of the box without having to put in the hackery used to avoid getting 500 errors. Compared to a year ago when I tried Typo out, it feels a lot faster and more responsive, although it is still kind of slow. We’ll see how it goes.

One thing that I found irksome, and for which I couldn’t find an easy solution to on Google, is that Typo’s permalinks are formatted like so: http://domain.name/articles/yyyy/mm/dd/slug In contrast, Wordpress’s permalinks are http://domain.name/yyyy/mm/dd/slug. Personally, I feel that articles is unnecessarily crufty, but I couldn’t figure out an easy way to get rid of it. I couldn’t get Apache’s mod_rewrite to work with Typo either. So this is what I ended up having to do to at least keep my Wordpress permalinks alive. (Derived from WordPress to Typo Migration, Part II.)

In config/routes.rb, add this:

  map.connect ':year/:month/:day/:title',
      :controller => 'wordpress_url', :action => 'redirect',
      :requirements => {:year => /\d{4}/, :month => /\d{1,2}/, :day => /\d{1,2}/}
  

This will require you to create a new file in app/controllers/ called wordpressurlcontroller.rb

app/controllers/wordpressurlcontroller.rb contains the following:

  class WordpressUrlController < ApplicationController
     def redirect
        year = params[:year]
        month = params[:month]
        day = params[:day]
        title = params[:title]
        url = "/articles/#{year}/#{month}/#{day}/#{title}/"
        redirect_permanently url
     end

    def redirect_permanently url
      headers["Status"] = "301 Moved Permanently"
      redirect_to url
    end

 
    private :redirect_permanently
  end

Now, I’m a Ruby/Rails newbie, so if there is a cleaner way to do this, or if there is a way to get rid of articles from the permalink, suggestions would be appreciated.

In case you haven’t noticed, I’ve once again changed blogging engines. This change differs from previous migrations in that I actually imported my old posts. Of course, I haven’t sifted through the old posts yet, and I’m pretty sure a lot of them are pretty broken. I can’t believe I wrote 400+ posts in the past year and a half. Can you imagine if I actually dedicated this time to writing a novel or a book of poems instead?

I tried installing Typo about a year ago, and I eventually got it to work, it was painfully slow. So I slogged on with Wordpress which is actually a really good blogging tool that seems pretty easy for newbies to use.

There are, however, two problems I ended up having with Wordpress: (1) it is painful to write custom themes and (2) PHP is an ugly language. The two problems are not unrelated.

I admit, perl is also an ugly language, but it’s not trying to be a templating language at the same time, either. (You have to install extensions for that sort of madness.) Which makes sense, since PHP uses a lot of perl concepts. And while ruby also owes a lot to perl, ruby can actually be quite elegant in a non-obfuscatory kind of way. The difference between perl and ruby is that in perl, you can write almost any program in one line. In ruby, you can also write almost any program in one line, but you can also actually read it, too.

The other thing was that I had the vain hope that using embedded ruby would allow me to avoid the dreaded nested angle-brackets. Alas, that is not the case, although if I want it badly enough, I can always use embedded ruby to actually build an XHTML element so that I don’t have to nest angle-brackets, which is actually how XSLT handles things. Maybe you can do that in PHP, too, but I really got tired of trying to separate logic from presentation. And the prospect of duplicating code for the index view and the single post view was quite daunting.

With Typo, you can just deal with the templates, since all the logic is really in Rails itself, and what elegant logic it is too. You can create beautiful things when you don’t worry about CPU cycles, you know? (Did I mention that Rails, and therefore, Typo, is slow?) Thanks to partials, you can avoid redundancy. (Although I feel that XSLT manages to avoid redundancy, too, and it’s XML-compliant from the get-go, although most sane people I’ve met don’t care too much about that as long as the eventual output conforms to XHTML and XML standards.) No editing multiple template files for me. Just zoom into the spot and go to it.

But, anyway, we’ll see how things go. The only thing that creeps me out is the fact that using an RDBMS as storage leaves me vulnerable to lock-in. Mostly because I’d rather not (re)learn how to interact with an RDBMS, and screwing around with SELECT statements seems to be the only foolproof way to actually get my data out of there in the eventuality that I want to move to yet another blog engine. Luckily, most of the major players have conversion scripts, although, as you might notice (for now), the Wordpress 2 to Typo converter isn’t exactly a finished product.

On the other hand, I have yet to try to migrate the files from my own hand-rolled static blog engine (mainly because I accidentally nuked the source files a long, long time ago and will therefore have to scrape raw HTML. Bleh.) Moving the blosxom stuff will probably be easier. It’s been trivial to convert a blosxom blog entry into an actual XML document. Now all I have to do is learn XML-RPC (yay) and the MetaWeblog API, and then I’ll be golden. (Yeesh!)