MonthSeptember 2009

Twitter gem – undefined method `stringify_keys’

Have you been getting the following errors when running the Twitter gem lately ?

/usr/local/lib/ruby/gems/1.8/gems/httparty-0.4.3/lib/httparty/response.rb:15:in `send': undefined method `stringify_keys' for # (NoMethodError)
from /usr/local/lib/ruby/gems/1.8/gems/httparty-0.4.3/lib/httparty/response.rb:15:in `method_missing'
from /usr/local/lib/ruby/gems/1.8/gems/mash-0.0.3/lib/mash.rb:131:in `deep_update'
from /usr/local/lib/ruby/gems/1.8/gems/mash-0.0.3/lib/mash.rb:50:in `initialize'
from /usr/local/lib/ruby/gems/1.8/gems/twitter-0.6.13/lib/twitter/search.rb:101:in `new'
from /usr/local/lib/ruby/gems/1.8/gems/twitter-0.6.13/lib/twitter/search.rb:101:in `fetch'
from test.rb:26

It’s because Twitter has been sending back plain text errors that are treated as a string instead of json and can’t be properly ‘Mashed’ by the Twitter gem. Also check

Without diving into the bowels of the Twitter gem or HTTParty, you could ‘begin…rescue’ this error and try again in 5 minutes. I fixed it by overriding the offending code to return nil and checking for a nil response as follows:

module Twitter
  class Search
    def fetch(force=false)

      if @fetch.nil? || force
        query = @query.dup
        query[:q] = query[:q].join(' ')
        query[:format] = 'json' #This line is the hack and whole reason we're monkey-patching at all.

        response = self.class.get('', :query => query, :format => :json)

        #Our patch: response should be a Hash. If it isnt, return nil.
        return nil if response.class != Hash

        @fetch =



(adapted from

If you have a better solution: speak up!

WordPress hack might affect more than your WordPress installation!

Just a quick note…

If you’re managing WordPress installations, and haven’t heard about the recent WordPress hacks ( yet you probably just got back from holiday.

There’s plenty of advice on fixing a hacked installation if you follow some of the links in the above post, so I’m not going to recite that here.

However! While cleaning a WordPress installation that resides in a subdirectory of a modx cms I found that the modx index.php files were also infected. I searched for infected files using grep as follows:

grep -R 'function gpc_' *

If you’re on a shared hosting environment that doesn’t allow shell access: time to change your hosting provider. (mail me if you need recommendations)