Upgrading to Rails 3 - Part 1

So it's been about 4 years since we wrote CushyCMS in rails 2.1.3. Over the years it eventually got upgraded through 2.2 and 2.3 and is now running on the latest stable version in the 2.3 tree. But as we all know, leaving a site behind will only bite you later when you want to add new features but can't use new gems or find help for your old code etc etc. The smart thing to do is to upgrade to rails 3.

I figured a staggered approach would be best. I'll upgrade to rails 3.0.12, then 3.1.x and then 3.2.x if I still have any motivation left by the time I finish. Making sure everything still works and tests still pass at each step. Should be pretty easy right? There are a tonne of guides and railscasts out there on how to smoothly transition. Wrong.

I marked this blog post as Part 1, even though I don't even know what will go in Part 2, I'm sure there will be a need for one. Let's just start listing the problems I've already endured in the supposedly simple upgrade.

• helpers :all is now on by default. Rails 3.1 has a way of disabling it, but Rails 3.0 does not. This is only a problem if you have a collision in your helper names, which we do, and so do many others according to a quick google search.
• default_url_options is no longer passed a Hash of options that include the controller/action for which the URL is currently being generated. Meaning you can't easily come up with some "default URL options" for a specific route.
• content_tag(:div, '') returns you an ActiveSupport::SafeBuffer instance, which is html_safe, and if you concat a string on the end of it, it will still be html_safe providing said string doesn't have HTML tags in it. However if you concat in the opposite direction, the same is not true. E.g. ('' + content_tag(:div)).html_safe? != (content_tag(:div) + '').html_safe?.
• I18n translations now use %{} as the interpolation mechanism instead of {{}}
• I18n translations require the phrase key to end in "_html" if you want them to be html_safe?. If you host your translations elsewhere, then this is not something that can be easily updated en masse.

Now this is just a list of what I would consider non-standard issues I've hit. There are of course a bunch more "standard" issues that most people will already know about and are usually covered by the guides out there that help you upgrade. Such as:

• ActionMailer has completely changed it's API and you will need to rewrite your entire Notifier models.
• error_messages_for has been completely removed, with no replacement built in.
• You will need to completely rewrite your routes.rb file from scratch.
• If you're using any plugins/gems (and let's face it, who isn't), more than likely you will need to upgrade them along with rails. If you're lucky, they will be well maintained and not have any API changes. I can assure you, I was not so lucky. At least 50% of the plugins we use are no longer maintained and don't work in Rails 3.0. Yay. 

In short. To anyone out there thinking it's going to be easy to upgrade. Think again.