Upgrading to Rails 3 beta (part 2)

This is the second part of a series of posts detailing my experiences while upgrading to Rails 3. The first part covered migrated configuration and framework files to play nicely with the new Rails 3 APIs. Now, we’ll look at booting the server, fixing dependency issues and walking through our app.

Fixing authlogic

Once we’re confident that we’ve migrated files to conform to the Rails 3 APIs, it’s time to boot the server:

> rails server

Depending on the gems on which your app depends, this may fail. My simple app, for example, depends on authlogic, which caused the following exception:

authlogic-2.1.3/lib/authlogic/session/timeout.rb:26:in 
`included': undefined method `before_persisting' for
Authlogic::Session::Base:Class (NoMethodError)

A little googling revealed the answer via this excellent bugmash summary. It seems that authlogic registers a bunch of callbacks, one of which is the before_persisting method mentioned above. The mechanism for specifying callbacks has changed in Rails 3, and so we get the error above.

Fortunately, a patch has already been written for authlogic, although it’s not made it into a gem release. To get the patch, we could install authlogic as a plugin or even better, use Bundler to grab the patched authlogic directly from github.

Installing authlogic from source with Bundler

Bundler allows gems to be installed directly from their source code repository. That way, patched code can be used, which hasn’t yet made it into a gem version. To run the patched authlogic directly from github, I needed to add this line to my Gemfile:

gem 'authlogic', :git => 
  'http://github.com/binarylogic/authlogic.git'

And then updated my bundle, running the following command in my application’s directory:

> bundle install

In the comments, dansby recommends running a rails3 branch of a forked authlogic. I’ve not tried it, but you might want to consider the fork if you want to use the authlogic generators. Simply use the following line in your Gemfile instead:

gem "authlogic", :git => 
  "git://github.com/odorcicd/authlogic.git", :branch => "rails3"

Installing authlogic as a plugin

In the original version of this post, I didn’t know that Bundler could be used to run gems directly from source, and so I recommended installing the patched authlogic as a Rails plugin. I strongly recommend managing all of your application’s dependencies through Bundler, but if you prefer to use a plugin, here’s how:

> rails plugin install git://github.com/binarylogic/authlogic.git

When running authlogic as a plugin, we don’t want to depend on the gem anymore, so we go ahead and comment it out in our Gemfile. We can switch back to the gem, if we wish, when the patch makes it into a release.

Fixing initialisers

My simple app didn’t have any other dependencies that affected the server’s startup, but YMMV. Try googling around, or browsing the source of your dependency.

Now, we’ve fixed our dependencies, our server should boot, right?

> rails server
config/initializers/new_rails_defaults.rb:14:
undefined method `generate_best_match=' for
ActionDispatch::Routing:Module (NoMethodError)

Wrong! This error originates from an initialiser with a suspicious name, new_rails_defaults.rb. Sure enough, the comments in the file indicate that it should be deleted when Rails 3 is released. I went ahead and deleted the file, and then my server booted.

Fixing routes

With the server running, we should try visiting our site. Fire up a web browser and point it at localhost:3000. I was surprised to be presented with the default Rails welcome page. After a bit of pondering, I realised that the Rails generator had regenerated a public/index.html file. We can remove that.

Now, I discovered that none of the routes were being matched. It seems that the routes.rb generated by the version of rails_upgrade I was using doesn’t generate a valid routes.rb file. We must ensure that the first line in our routes.rb looks like:

SampleApp::Application.routes.draw do |map|

and not:

SampleApp::Application.routes do

Run through the app

With routing back on its feet, we can browse our app and make a note of any problems. I found a few issues, which I’ll quickly summarise.

It’s worth watching the output from the server process while browsing your app, as it does spit out fairly good deprecation warnings, such as:

DEPRECATION WARNING: Setting filter_parameter_logging
in ActionController is deprecated and has no longer effect,
please set 'config.filter_parameters' in
config/application.rb instead.

In my app, the following code from app/controllers/application_controller.rb:

filter_parameter_logging :password, :password_confirmation

became the following in config/application.rb

config.filter_parameters << :password << :password_confirmation

Note that filter_parameters is now an array, and we can chain « to append to it.

I found a couple of problems in my templates, which were relatively easy to fix. The most significant change I noticed was that code like this:

<% form_remote_for @object do |f| %>

becomes this:

<% form_for @object, :remote => true do |f| %>

On a related note, this now generates unobtrusive Javascript using HTML 5. We can change our application layout to use the HTML5 doctype:

<!DOCTYPE html>

Right, that’s it for now. I’ve still got a couple of issues to work out, which I may include in a third and final part. Thanks for reading; happy upgrading!