If you’ve been here before, you’ve surely noticed that things look a bit different. Well, it’s been a long time coming, but I’m finally changing the blog’s theme to make it a) look better and b) more readable and usable. The old theme was a bit stale and I had gotten a few complaints, so here ya go. There have been numerous changes behind the scenes, too:

I upgraded from Typo 4.0.1 to 5.4.3. This is a major update. The entire back-end has changed (drastically for the better!), and things work as never before. Funny how you can get used to and just accept a crap version of something. Perhaps this will entice me to post a bit more, since the UI has gotten quite slick.

Now for the nitty-gritty details of upgrading. Don’t bother continuing unless you’re interested in upgrading Typo on a shared hosting service (in my case, Dreamhost). I ran into a few roadblocks along the way, piecing the steps together from numerous sources:

  1. First, I went to the typo upgrade site to get things going. These directions aren’t very good, so I’ll elaborate.
  2. I have gems installed on my account (~/.gems), since mine is a shared account and I like to have control over the software being run there. I simply ran

    gem update -i ~/.gems typo

    to update the gems in my account. Pretty simple.

  3. The next step was to actually install the updated Typo gem into my existing installation:

    ~/.gems/bin/typo install ~/blog_home

    which is where the troubles began. Turns out that the ‘install’ gem tries to back up your entire weblog database into a .yml file. Well, if you have a decent-sized blog, this is going to take a lot of time, and consume a whole lot of CPU and memory resources. Dreamhost kept killing the backup process for that very reason (as this guy experienced, too) which was frustrating. I contacted someone via online chat (which has been quite helpful recently) and got some tech guy on the other end who temporarily turned off the kill process for my account. Well, the backup still took forever, with dire warnings from him periodically (99% CPU. 800MB RAM. How long is this going to take? Uhh…just a couple minutes..)

  4. If the previous command causes these types of problems, I’d suggest backing up your blog database manually via mysqldump, phpmysql, or some other utility. Then disable the auto-backup by hacking the rails install gem ($GEM_HOME/gems/rails-app-installer-0.2.0/lib/rails-installer.rb) and commenting out the ‘backup_database’ step in the install_sequence function:

    #backup_database

  5. Now re-run the command in step 3. This got much further for me, but failed again during the schema migration when Dreamhost killed the process again. The simple workaround here was to run the migration manually from the rails home directory via rake:

    rake RAILS_ENV=production db:migrate

  6. And finally, re-run step 3. This completed successfully for me; however, navigating to my blog again was less than successful, giving the dreaded 500 Rails Application Error. Now, Passenger to the rescue:

  7. Create the file $RAILS_HOME/tmp/restart.txt. Passenger watches this file and restarts when it is touched. This is quite handy for debugging. Now go into config/environment.rb and add these lines beneath the #bootstrap require line:

    if ENV['RAILS_ENV'] == 'production'  # don't bother on dev
  ENV['GEM_PATH'] = '/home/USERNAME/.gems' + ':/usr/lib/ruby/gems/1.8'
  Gem.clear_paths
end

  8. This tells Passenger to use the gems in your local account first. Now touch the restart.txt file and you should be good to go!