Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Rails 3: undefined method `render_template' for class `ActionView::Template' (NameError) #17

galetahub opened this Issue Apr 27, 2010 · 11 comments


None yet
5 participants

We need some fix in file "actionview_extension.rb" (http://github.com/brynary/rack-bug/blob/master/lib/rack/bug/panels/templates_panel/actionview_extension.rb)

ActionView::Template now has method "render" and "virtual_path". So please replace file "actionview_extension.rb":

if defined?(ActionView) && defined?(ActionView::Template)
  ActionView::Template.class_eval do

    def render_with_rack_bug(*args, &block)
      Rack::Bug::TemplatesPanel.record(virtual_path) do
        render_without_rack_bug(*args, &block)

    alias_method_chain :render, :rack_bug

lukemelia commented May 28, 2010

Rails 3 support is not yet in master. Jose Valim's fork has some work in this direction, but we need to figure out how to merge it in such a way that preserves Rails 2 support. Or not.

Hummm, any movement on this? Using Rails 3 in production now and I need my Rack Bug!


lukemelia commented Jul 14, 2010

@lorennorman can you try the rails3 branch on this repo (http://github.com/brynary/rack-bug/tree/rails3)? I think it is mostly working with a test app, but I'm not running Rails 3 in production yet, so it hasn't gotten a real workout.

Yeah, I found that branch and just tried it but it breaks in a bad way.

I'm not really sure what is happening, but the Ruby process spikes to 100% CPU for about 30 seconds, then Rack::Bug renders itself inline to the page with a MASSIVE amount of text under Server Variables for... Warden?

This is my first time troubleshooting middlewares, apologies for not knowing more.

Running rake middleware shows Rack::Bug right between Warden and Sass:
use Warden::Manager
use Rack::Bug
use Sass::Plugin::Rack

Something I'm doing wrong or should try?


lukemelia commented Jul 14, 2010

sounds like perhaps Warden puts a lot of stuff into the rack env hash. If there is a pattern to the keys that it adds, you could try filtering them out by following the pattern of line 40 of lib/rack/bug/panels/request_variables_panel.rb

If that solves your problem, we can think about how to come up with a cleaner solution.

I can't imagine that this is normal behavior for Warden, the amount of data is enormous! Maybe RackBug is causing it to do something insane.

I'll poke around a bit and see if I can figure out what is going on.

So I was able to get it fairly stabilized by doing these things:

  • filtering "warden" from the server vars

  • filtering "action_controller.instance" from the server vars

  • added Rack::Bug to the middleware chain BEFORE Warden by doing:

    config.middleware.insert_before "Warden::Manager", "Rack::Bug"

Is it common for action_controller.instance to be enormous and to slow things down? I didn't see why I should have to filter it, but it was clearly lagging the DOM widget when I switched to that view due to its immense size, similar to what Warden was doing.

I'm also not totally sure what changing the order of the middlewares is doing, but I'm fairly certain that it helped as the Rails process doesn't spike to 100% CPU for long periods of time anymore.

My problem is that I'd never used Rack::Bug previous to this, so I don't really know what to compare against, but I'd happily fork and publish what I did if I thought I was doing it right and being helpful!

BTW, what's the best way to swap from relying on an external dependency to actually hacking on that dependency locally? I simply cloned Rack::Bug into vendor/gems and changed my Gemfile line from:

gem 'rack-bug', :require => 'rack/bug', :git => 'git://github.com/brynary/rack-bug', :branch => 'rails3'


gem 'rack-bug', :require => 'rack/bug', :path => 'vendor/gems/rack-bug'

...and manually checked out the rails3 branch in the cloned repo. From there I just added my hack and restarted the server. Good enough in the absence of my own fork, i guess?

Thanks again!

Also getting this deprecation warning, not sure if I caused it or if it's Rails 3 generally being unhappy with Rack::Bug

DEPRECATION WARNING: All middlewares in the chaing are active since the laziness was removed from the middleware stack. (called from block in <module:Info> at /Users/lorennorman/.rvm/gems/ruby-1.9.2-preview3@rails3/gems/railties-3.0.0.beta4/lib/rails/info.rb:92)

Rack Bug does not work for me on Rails 3.0.5 / Ruby 1.8.7. I can click the "toggle Rack Bug" link and from then on all the requests time out or i get a "can not allocate memory" error.
I tried the brynary and the lorennorman rails3 branch.
Any hints?

XJ4 commented Jan 3, 2013

Hey @lorennorman , how did you "filtering "warden" from the server vars" please?

@XJ4 This is ancient history, and I don't think I ever got this working terribly well so I'm not endorsing any of this. But to answer your question directly, this is what I was referring to with respect to filtering server vars:

Good luck!

Napolskih pushed a commit to Napolskih/rack-bug that referenced this issue May 12, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment