Upgrading to Active Admin 1.0.0.pre1

If you’re using Active Admin chances are, you’re not on 1.0 yet. Most likely because it isn’t out yet. So what do you when Rails 4 isn’t supported and you’d like to upgrade your app to it? You have to boldly go and bundle a prerelease version. Eek, that sounds scary! A prerelease is, by […]

If you’re using Active Admin chances are, you’re not on 1.0 yet. Most likely because it isn’t out yet. So what do you when Rails 4 isn’t supported and you’d like to upgrade your app to it?

You have to boldly go and bundle a prerelease version. Eek, that sounds scary! A prerelease is, by definition, not deemed stable yet – so how can you find the courage to let your app use it? Firstly, you don’t have to take it all the way to production. Trying to run the app in development can be fine. If all you you want to do is help the people, who work on Active Admin in their free time. Getting your app to run you’ll help that team find more regressions.

Speaking more generally, that’s the approach I’d advise you to take with Rails too. The Rails team (of which I’m a member) would love for you to bundle betas and run your test suite. If you find a regression you can file a bug and help everyone out.

Back to our case. We’re using Active Admin with our own employees so we could stand production woes.

Here’s the changes I went through to make our admin setup run with Active Admin 1.0.0.pre1. I can’t say these are all the things you have to do, but this is a start. Use the comments box to add your experience and tips below.

Changes I had to do

Inheritance hierarchy changed for custom filters

Right on the first boot, I realized my server and I weren’t as friendly as I had thought:

app/admin/filters/exact_string.rb:3:in `<module:Inputs>': uninitialized constant ActiveAdmin::Inputs::FilterStringInput (NameError)

Confused by my Ruby code name checking me at the door, I went looking in admin/filters/exact_string.rb and saw this:

module ActiveAdmin
  module Inputs
    class FilterExactStringInput < FilterStringInput
      filter :equals
    end
  end
end

Long story short the inheritance namespace changed to ActiveAdmin::Inputs::Filters::StringInput. A quick change to Filters::StringInput had that deal sorted. Instead of being out of the woods yet, however, we’d merely moved slightly into more uncharted territory. Now Active Admin couldn’t find our custom filter:

[FATAL] ActionView::Template::Error (Unable to find input class ExactStringInput):

Look closely at the expected class name – there’s no need for the Filter prefix we had. I removed it, the filter worked and our final input looked like:

module ActiveAdmin
  module Inputs
    class ExactStringInput < Filters::StringInput
      filter :equals
    end
  end
end

I’ve added the steps I used to figure this change out (as it wasn’t documented and there was no deprecation notice). Skip to the next section if you don’t care.

I cloned the Active Admin repository and searched the git history using the tips here: https://gun.io/blog/git-search-log/

git grep "FilterStringInput" $(git rev-list —all)

Which gave output that looked like:

9d6e3c8d1b5ac89f97631f777ee352493d1a7211:lib/active_admin/inputs.rb:    autoload :FilterStringInput
9d6e3c8d1b5ac89f97631f777ee352493d1a7211:lib/active_admin/inputs.rb:    autoload :FilterStringInput
9d6e3c8d1b5ac89f97631f777ee352493d1a7211:lib/active_admin/inputs/filter_string_input.rb:    class FilterStringInput < ::Formtastic::Inputs::StringInput

This showed where the file that defined the FilterStringInput that went missing. Now I just had to get at it. I checked out the commit from above, opened the file in my editor and went back to master to compare. Sure enough, there was still an inputs folder in master which had a filter very close to what we were using.

Action items without a name deprecated

This time the boot worked fine and I even had new friends in the logs:

[WARN ] DEPRECATION WARNING: Active Admin: using `action_item` without a name is deprecated! Use `action_item(:edit)`. (called from block in <top (required)> at /Users/kasperhansen/Documents/code/mainframe/app/admin/phone_numbers.rb:196) (pid:42252)

Okay, so I went around and updated all the action items to give them a name.

I tried to automate the change, but gave up as replacing a line in file was starting to take too long. Here’s how far I got, in case you want to finish it:

Dir['app/admin/*.rb'].each do |admin_file|
  File.open(admin_file, 'w+') do |f|
    lines = f.each_line
    new_lines = []

    begin
      while line = lines.next
        new_lines << line

        if line =~ /action_item(.*)do/
          next if line.include?('=>') && !line.include?(',')

          link_title = $1 if lines.peek =~ /link_to(?s+['"]?(.*?)['"])/
          next unless link_title

          if link_title.count(' ') > 1 # Assume complex link title name
            puts "What should the action name be for? #{link_title}"
            link_title = gets.chomp # You write it, jerk.
          end

          new_lines.last.sub! /action_item/, "action_item #{link_title.snake_case},"
        end
      end
    rescue StopIteration
    end

    f.write new_lines.join($/)
  end
end

Formtastic deprecated buttons in favor of actions

Active Admin doesn’t like to reinvent the wheels and makes use of some other libraries to do its thing. One of those is Formtastic, which also had to be upgraded when going to 1.0.0.pre1. Formtastic also had some API changes, where buttons was deprecated in favor of actions in forms. That’s easy enough to sort out if you run this when in your Rails app’s root:

find app/admin -type f -exec sed -i '' 's/f.buttons/f.actions/g' {} ;

Those were the steps I had to take to get Active Admin up and working. So far I haven’t found any bugs, and the prerelease feels stable. Great work, gang!

Source: Firmafon