5

In my config/environments/development.rb I have the following line:

config.action_controller.consider_all_requests_local = true

which means I should get all the ugly error stuff when in development environment. But for some reason my app has suddenly started giving me the pretty error page you're supposed to see on production.

Is there possibly some place where this may have been over-ridden? Other people are working on the project as well so maybe one of them did something to cause it.

tybro0103
  • 48,327
  • 33
  • 144
  • 170

3 Answers3

2

Old post, but just in case someone finds this like I did ...

I'm pretty sure that when the

config.action_controller.consider_all_requests_local = true

is set, local_request? is never called.

I would dump the config value at runtime and see what it is.

How do I access a Rails configuration value during runtime?

(in rails 3.2)

config.consider_all_requests_local = true

Community
  • 1
  • 1
John Hinnegan
  • 5,864
  • 2
  • 48
  • 64
0

This just happened to me and it turned out it was just because I had special characters in the page I was trying to load. I added # encoding: utf-8 to the top of the file with the special characters and everything worked.

Ariel
  • 3,383
  • 4
  • 43
  • 58
0

Someone might be overriding the local_request? (api) method somewhere, it's a way to always show the proper error page.

I just answered someone else's question on how to override it. You basically just would put a method in one of the controllers (like ApplicationController) like this:

def local_request?
  false
end

So, possibly someone used that somewhere. Do a full project search in textmate or using grep.

Community
  • 1
  • 1
Dan McNevin
  • 22,278
  • 5
  • 35
  • 28
  • I haven't found any occurences of local_request?... anything else? – tybro0103 Jan 01 '10 at 17:36
  • That's the only way I know of.. Maybe you can set up a similar method but always return true if RAILS_ENV == "development" in the ApplicationController or the controller that you're working in. Another thing would be to use ./script/server -u and put a "debugger" in close to what's generating the error and just use 'next' to step though the code and see where the error page is being generated from. – Dan McNevin Jan 02 '10 at 23:48