rlucas.net: The Next Generation Rotating Header Image

August 6th, 2007:

Rails form_tag Changes in Rails 1.2

I recently updated my dev machine (Mac OS X) to the latest Rails gems, and was getting deprecation warnings for using form_tag in its old, non-block, pre-Rails 1.2 way.

Then, in moving between my development and acceptance-testing boxes (you do have a mirror of your production environment running as an acceptance testing server before you push things from your laptop to production, right?) I started getting blank HTML pages out of the testing box. Whoops.

Well, one thing is that the two different versions of form_tag act differently with respect to output — so with the old one, you needed to put:

<%= form_tag ... %>  

While the new one takes:

<% form_tag ... do %>   ... <% end %>  

(Note lack of = sign in the new, block version.)

But that wasn’t it. My problem was that, even with the equal signs fixed, I was getting no love from my testing box. Things that should have been enclosed in the form tag block were just not happening.

My hunch was that the old version of Rails was barfing (this was sort of true: the new block form of form_tag is not backwards compatible). I updated Rails with a one-two punch of apt-get update; apt-get upgrade mixed with a gem install rails. No luck. Aha! Have to kill and restart the server process: still, I got no form tag love.

I checked the Rails version with rails -v and got 1.2.3, the latest version. gem list showed that 1.2.3 was coexisting with some older versions. Aha! And a real aha this time — for this was, it turns out, the problem.

Thanks to the folks who author the acts_as_authenticated wiki. It was there that I found a reminder that the RAILS_GEM_VERSION variable, in config/environment.rb, can be set to peg which, among several possible installed versions of Rails, the app will use.

It appears that if you comment out RAILS_GEM_VERSION, you get the latest installed version — which in my case fixed it to use 1.2.3, thereby giving me my form_tags back.