Jan 11

Adding actions to Devise controllers

Adding Actions to Devise Controllers

It wasn’t the most fun I could imagine having during a “holiday season” but while holed up in Chicagoland over Christmas I spent a couple of days porting a few of my older Rails apps to use a more up to date stack: Rails 3, Devise, Inherited Resources, Formtastic, etc. The idea is that if the apps are on a stack I use every day, I’ll spend less of my time reloading old tools into my head when the inevitable tweaks are required. We’ll see how that goes.


Two of the apps I was working on include member profile pages. Having carefully chosen my devise model names to match the language of my app I wanted to use the same controller that’s used for registrations for other member actions. Initially I tried just extending the relevant controller and updating the route:


  devise_for :members, :controllers => { :registrations => "members" }


class MembersController < Devise::RegistrationsController
  def show

but I kept getting ActionController::UnknownAction exceptions when I tried to request a member profile page.

It turns out that Devise runs a before_filter called is_devise_resource? in its controllers and that wasn’t recognising any actions that aren’t included in the core devise controllers. It also runs authenticate_scope! for relevant actions.

With that discovered it was easy enough to update my controller to

class MembersController  [:index, :show, :edit, :update]
  skip_before_filter :authenticate_scope!, :only => [:edit, :update, :destroy]

  def show

and everything fell into place.

May 10

has_many_polymorphs and Rails 3

I’m gradually porting a number of my older Rails apps over to Rails 3. The main motivation is a chance to really put the new version through its paces, get a better sense of how it’s working, where plugins are at, etc; but it’s also rather nice to get some of the performance improvements and cleaner code along the way.

Catapult relies on Evan Weaver’s has_many_polymorphs plugin quite extensively so it was important to be have a Rails 3 compatible version. I couldn’t find any evidence that anyone else was working on it, so I’ve forked the github project and made a few alterations. I’ve set it up to work as a gem (so I can pull in the latest version using bundler) and adjusted to fit the new rails initialization process. It’s rather hacky, but it’s working for me so far.

Evan informs me that he has no plans to work on compatibility, so I’m going to see what time I can find to tidy it up a bit more, make sure the tests are passing, etc. If anyone else is so inclined, I’d love some help with that. You can find my fork on github.

Apr 10

Faster Rails development with bundler and rvm

If you’re anything like me, you’ve found the rails server and console taking longer and longer to launch lately. Even switching to Rails 3 for most active projects hasn’t really helped. But I finally found a solution a couple of weeks ago.

I found it reading Mikel Lindsaar’s Bundle Me Some Sanity where he outlines the way that bundler coupled with rvm allows a rather different and much cleaner way to manage gems in a ruby application.

I’d been aware of rvm as a way to cleanly manage different versions of ruby on a single machine, but had missed their (recent addition in 0.1.25 of) Named Gem Sets. With Named Gem Sets you can specify a version of ruby and a separate gem library for each app, reducing dependency resolution time considerably.

I already can’t imagine switching away from this.

Aug 09

Cucumber, wordpress and database_cleaner

I’m up to my usual using-ruby-tools-to-test-other-environments tricks, using cucumber and my wordpress activerecord classes to do acceptance testing against a highly-customised wordpress install.

I’m hoping to write a bit more about that soon, once I’ve put it through its paces a little more and cleaned up some of the code, but I wanted to quickly mention one of the key pain-points and an extremely handy solution.

One of the things I enjoy most about testing in rails is the handy tasks to prepare a blank database and the transactions that ensure the database is returned to that state after each test. Obviously that wasn’t going to work cleanly with wordpress since it doesn’t use ActiveRecord, but Matt kindly pointed me in the direction of Ben Mabey’s database_cleaner gem.

With that installed it’s as simple as adding:

require 'database_cleaner'
require 'database_cleaner/cucumber'
DatabaseCleaner.strategy = :truncation, {:except => %w[wp_options]}

to my


file and my database is reset on each step. Combined with a few hooks to manage the configuration and load in the schema at the appropriate point, it’s turning into quite a nice little testing environment.

Apr 09

WordPress and "Pathless Categories"

I’m working on a wordpress project at the moment, and pushing that blogging engine quite a bit further than I have before. We’re going to be using categories very extensively and one of the first tasks has been to allow category paths without any preceding /category/ or the like. By default, wordpress wants the category with a slug of ‘case-studies’ to live at:


but we want it to be simply:


So far, so straightforward. I installed the pathless-category-links plugin and all was well. Until I started using subcategories. All subcategory links started returning 404s. It seems I’m far from alone in that problem, but I’ve not yet seen a solution offered, so a little digging was required.

What was happening with subcategories (at least in my setup) was that the wordpress method that parses the query string was identifying the top-level category name as the category name and the subcategory name as the ‘name’ (ie. the post slug to look for). What was needed was a check to see whether that ‘name’ maps to a category slug and if so, correct wordpress’ assumption.

The code I’m using is:

if (! function_exists('jys_pathless_category_links_query_string')) {
  function jys_pathless_category_links_query_string($qs) {
    parse_str($qs, $query_vars);
    if (isset($query_vars['name']) && get_category_by_slug($query_vars['name'])) {
      $res = array('category_name' => $query_vars['category_name'] . "/" . $query_vars['name']);
      return http_build_query($res);
    return $qs;

add_filter('query_string', 'jys_pathless_category_links_query_string');

(NB: This will break if you have permalinks set up as recommended by the plugin author (‘/%category%/%postname%’) and a post in your top-level category with the same slug as your subcategory. But hopefully that’s rare enough that we’ll be okay!)

Feb 09

Hacking wordpress to support per-post banner images

post-bannersI seem to be spending a lot of time with wordpress at the moment. It’s become so ubiquitous that it often makes far more sense to set it up and integrate with an existing app than to set up some other blogging system and re-train users. As a result I’ve been writing a few wordpress plugins. Most of them are too specialised to be worth sharing, but one seemed worth opening up…

Implementing a (not quite public yet) design recently I had need of a way to specify a banner image for each post. While wp has pretty good support for adding various media into the body of posts, this needed to sit outside the post body.

I whipped together a quick plugin to handle uploading a banner and storing its details in the metadata for the post. It was a simple process, nicely self-contained, except that the post edit form doesn’t have the appropriate enctype=”multipart/form-data”. I looked around for any hooks that would allow me to cleanly add attributes to the form tag, but in the end resorted to editing wp-admin/edit-form-advanced.php to add it.

I’d hoped that there’d be time to find a cleaner way to do all this before telling people about it—perhaps some javascript that hooks into the existing media selector but allows it to populate a custom data field?—but it hasn’t, so I’m throwing it out there to the wider world as-is. The code is at github. Feel free to take it and use it as-is, to fork it and update it to be a better wordpress citizen, to email me patches to apply to my copy, or even to employ me to spend more time cleaning it up! Either way, it deserves to be out in the open and hopefully it’ll be of us to somebody besides me.

Feb 09

Rails 2.3 and theme_support part 3: Layouts

In my ongoing efforts to bring my fork of theme_support in line with Rails 2.3 I’ve covered the core views and email, but when I left off earlier today layouts still weren’t working.

The key problem with overriding layouts is that the process of identifying them relies on some class methods on ActionController::Base (provided in the ActionController::Layout module). Roughly put we have:

  1. ActionController::Base#render calls ActionController::Base#pick_layout
  2. ActionController::Base#pick_layout checks to see if there’s a specific layout requested and calls ActionController::Base#active_layout
  3. ActionController::Base#active_layout checks whether there’s a candidate layout for this controller or action and makes sure the layout exists by calling ActionController::Base.find_layout
  4. ActionController::Base.find_layout (class method) is called which checks the view_paths to find the appropriate layout in there

The issue is that as a class method ActionController::Base.active_layout has no knowledge of the specific controller instance, or the request object it contains, and so it can’t access our logic to determine the current theme.

One option would be to patch a number of these methods to hand a controller instance around which could be queried for the theme, but that seems rather clunky.

Another option is to wrap the active_layout method so that it (as an instance method) checks whether there is a current theme and if so, adds that theme’s path to the class level view_paths, removing it again after that check:

  class ActionController::Base
    alias_method :theme_support_active_layout, :active_layout

    def active_layout(passed_layout = nil)
      if current_theme
        theme_path = File.join(RAILS_ROOT, "themes", controller.current_theme, "views")
        if File.exists?(theme_path) and ! self.class.view_paths.include?(theme_path)
          result = theme_support_active_layout(passed_layout)
          return result


And it works!

So that’s views, emails and now layouts all working with theme_support on Rails 2.3. As before, you can get the results in the branch on github:


Over the next couple of weeks I’m hoping to test my patches on other releases in the 2.x series, probably using a test app with specs or stories that will put it through its paces. Once that’s done I may turn my attention to the other corners of the plugin (that I don’t personally use) like the asset helper methods, but if anyone wants to contribute patches in the meantime I’d love to get them.

Feb 09

Rails 2.3 and theme_support part 2: ActionMailer

Stage 2 of fixing up theme_support for Rails 2.3 was making sure that ActionMailer picked up themed templates (for stage 1 information see here). That’s something I’d not quite cracked in the 2.2 version, so starting afresh with 2.3 forced me to spend the time to look through the full render path and figure out what was going on.

ActionMailer is a little more complicated than ActionView in that there are multiple routes of entry (ways of sending emails) and each email can have multiple templates associated with it to allow for multipart email. But at the core of it all is the ActionMailer::Base#create! method. This executes the specific method that populates the mailer variables (ie. the code you actually write in your mailers) and then uses Dir.glob to look for appropriate templates for this email:

Dir.glob("#{template_path}/#{@template}.*").each do |path|
  template = template_root["#{template_path}/#{File.basename(path)}"]

  # Skip unless template has a multipart format
  next unless template && template.multipart?

  @parts <  template.content_type,
    :disposition => "inline",
    :charset => charset,
    :body => render_message(template, @body)

The initial patch provides a couple of ways to specify the theme for an email. I’m mainly using the approach of specifying self.current_theme within a mailer method. eg:

class UserMailer < ActionMailer::Base
  def activation(user)
    self.current_theme = user.site.theme
    @subject    += 'Your account has been activated!'
    @body[:url]  = "http://www.catapultmagazine.com/"

With that in place the next step was to patch ActionMailer::Base#create! so that instead of just looking at the main template_path it looked first in the relevant theme folder and then in the main template folder. So the code above becomes:

tpaths = []
tpaths < < File.join(RAILS_ROOT, "themes", self.current_theme, "views", mailer_name) if self.current_theme
tpaths << template_path

tpaths.each do |tpath|
  Dir.glob("#{tpath}/#{@template}.*").each do |path|
    template = template_root["#{tpath}/#{File.basename(path)}"]

    # Skip unless template has a multipart format
    next unless template && template.multipart?

    @parts < template.content_type,
      :disposition => "inline",
      :charset => charset,
      :body => render_message(template, @body)
  break if @parts.any?

The keen-eyed among you will notice that this means you can’t have, say, your HTML part themed and your plain text part in your main app/views folder. There would be ways around that, but this seemed the cleanest approach to take.

UPDATE (5pm): I’ve now got layouts working too. More on that over here.

Feb 09

Rails 2.3 and theme_support

A couple of months back, I realised that two of my projects (Generous and Catapult) could do with the help of the theme_support Rails plugin. Discovering that it didn’t play nicely with Rails 2.1, I created a fork on github and hacked at the _pick_template method to get it to do what I wanted. It turned out a few people were interested in having the plugin work with Rails 2.1, some of whom used more of the plugin’s featured than I need, and a few further forks emerged. I’ve been meaning to work through them and merge together the best bits, but the impending release of Rails 2.3 stopped me in my tracks.

I’m particularly keen to upgrade to 2.3 because Catapult generates a lot of routes and 2.3’s improved route handling should save us quite a bit of RAM and a number of cycles. So it was rather frustrating to find that yet again a new release of rails broke the plugin. Many hours later, working my way through the render path and trying to find the optimal solution, I’m not quite there, but it sort of works and seemed worth writing up:

It turns out that for most templates there’s a single point we can patch that will handle things. ActionView::Base#view_paths returns an instance of ActionView::PathSet which is an augmented Array that ActionView consults to find a template that matches its current requirements. By overriding that method we can check to see if a theme should be active and add that theme’s folder to the set of paths to be consulted.

module ActionView
  class Base

    alias_method :theme_support_old_view_paths, :view_paths

    def view_paths
      paths = theme_support_old_view_paths

      if controller and controller.current_theme
        theme_path = File.join(RAILS_ROOT, "themes", controller.current_theme, "views")
        if File.exists?(theme_path) and ! paths.include?(theme_path)


The hitch is that this doesn’t work for layouts, which take a slightly different path. In my case, that’s not a huge deal, but it’s a major omission for other uses. I’ve also not yet tested the actionmailer handling.

You can track progress in a branch on GitHub. I’ll post here as I make more progress, but would welcome any contributions from the rest of the community.

UPDATE (10pm): I just checked in ActionMailer support. More on that tomorrow.

Jan 09

Tracking Heathrow with twitter

It's 11.23 on Thursday

A few months back—while we were discussing the number of talking objects appearing on twitter—Jenny pointed out to me that all Heathrow airport arrivals and departures data is online. That set my mind racing, as if you know all the flights leaving that currently controversial airport, there are all manner of things you could begin to do. Working out miles travelled and carbon emitted, spotting delays, and so on. But at the time it all came down to a quick note in Things to some day set aside time to explore.

That day arrived this week. The data turned out to be pretty simple to scrape, with a quick wrapper around hpricot, and to throw into an SQLite database using datamapper to give me a little abstraction and a place to throw a variety of methods to make my code simpler. And then it was a small matter of employing John Nunemaker’s twitter gem to set up regular tweets letting followers in on how many flights in and out of Heathrow there have been lately.

The result is a rather pleasing hourly summary, that adds a little rhythm and background awareness into my day. You can follow it at http://twitter.com/heathrowtower.

Perhaps the biggest frustration with the data is that all destinations/origins are given as city names. Given that city names are hardly unique, and even if they were a given city may have several airports connecting with Heathrow, that makes it a bit trickier to do some of the more sophisticated calculations. My hope is that the flight codes (which are given) can soon be transformed into a list of airport codes, which can then open up a route to more useful and interesting data. (if anyone knows of an existing database that does that mapping, please let me know!)

I’m looking forward to that, but I’m also anticipating the ambient awareness that having the bot running will create. Will the hourly ritual of seeing a sentence or two about Heathrow activity reveal any patterns? If they do, maybe I’ll update the code to make more of those. We’ll see.

For now, please do follow the tower on twitter, tell people about it, send it messages if you spot anything interesting, and feel free to take a look at the code over on github.