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.
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
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.
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.
Related
I am using the web_console gem and I would like to add some IPs to the whitelist. For reasons that would probably go to far to explain, can't simply add something to the config/application.rb or config/environments/development.rb. However I can create an initializer config/initializers/.
I simple tried this in config/initializers/99-webconsole.rb, but while the file is loaded (--> debug message is shown), the web console does not seem to pick up my settings.
Rails.application.configure do
config.web_console.whitelisted_ips = '10.10.0.0/16'
p "Debug: this is loaded."
end
I assume it's related to some kind of race condition? Providing the same line in config/environments/development.rb works, but as said, I sadly can not change that file.
Based on this code https://github.com/rails/web-console/blob/e3dcf4c588af526eafcf1ce9413e62d846599538/lib/web_console/railtie.rb#L59
maybe there is a code in your initializer that configuring config.web_console.permissions, so your whitelisted_ips config is ignored
whitelisted_ips is also deprecated
and have you checked that you are using v4.2.0, the permissions was buggy and fixed by this commit https://github.com/rails/web-console/commit/6336c89385b58e88b2661ea3dc42fe28651d6296
When I browse the site I get:
We're sorry, but something went wrong.
as I've seen its a 500.html file, so its some internal server error, but how can I make display those errors?
I've tried this:
1) putting ENV['RAILS_ENV'] ||= 'development'in environment.rb, but nothing happened
2) config.log_level = :any, then looked at the production.log, but there is not 500 errors
Or what I need to write in the 500.html to see errors?, or just display it no matter how.
Your log files (wherever they're written) should contain your errors.
If you still like to view the errors in the browser you could change the following in your environment/production.rb (but consider it as a temporary work-around). Make sure to switch it back.
config.consider_all_requests_local = true
I recently started having to restart my development server every time I change my code. My development.rb file still has this line:
config.cache_classes = false
I tried using the debugger verify that this value has stuck around. To do this I set my configuration to a global variable in environment.rb:
$my_initializer = Rails::Initializer.run do |config|
...
end
then I put a debugger line in one of my controllers so I could do this:
(rdb:2) $my_initializer.configuration.cache_classes
false
So that eliminated the possibility that the value of cache_classes was getting set to true somewhere else. I've tried using both Mongrel and WEBrick and it still happens.
What else might be causing Rails not to reload my code with every request?
I am running:
Mongrel 1.1.5
WEBrick 1.3.1
Rails 2.3.8
Ruby 1.8.7 p253
EDIT:
at #Daemin 's suggestion I checked that the mtime of my files are are actually getting updated when I save them in my text editor (Textmate)
merced:controllers lance$ ls -l people_controller.rb
-rwxr-xr-x 1 lance staff 2153 Act 10 18:01 people_controller.rb
Then I made a change and saved the file:
merced:controllers lance$ ls -l people_controller.rb
-rwxr-xr-x# 1 lance staff 2163 Oct 11 12:03 people_controller.rb
So it's not a problem with the mtimes.
So it turns out that config.threadsafe! overwrites the effect of config.cache_classes = false, even though it doesn't actually overwrite the value of cache_classes (see my question for proof). Digging around a bit more in the Rails source code might illuminate why this might be, but I don't actually need threadsafe behavior in my development environment. Instead, I replaced my call to config.threadsafe! in environment.rb to
config.threadsafe! unless RAILS_ENV == "development"
and everything works fine now.
If anyone else has this problem the solution was the order: config.threadsafe! has to come before config.cache_classes. Reorder it like this to fix it:
...
config.threadsafe!
config.cache_classes = false
...
answer from: Rails: cache_classes => false still caches
I suspect that the classes you are expecting to refresh have been 'required' somewhere in your configuration. Note that Rails' dependency loading happens after Ruby's requires have happened. If a particular module or class has already been required, it will not be handled by Rails' dependency loader, and thus it will not be reloaded. For a detailed explanation, check out this article: http://spacevatican.org/2008/9/28/required-or-not
Despite the fact that the threadsafe! solution works, I also wanted to point out for your benefit and the others that may come in after the following...
If you're editing engine code that is directly in your vendor/engines directory, those files will not be updated without a restart. There may be a configuration option to enable such functionality. However, this is very important to remember if you have used engines to separate large bits of functionality from your application.
My guess would be that it's not reloading the classes for each request because they haven't changed between requests. So the system would note down the last modified time when the classes are loaded, and not reload them until that changed.
In my Rails app (running on rails 2.3.5, ruby 1.8.7), my application_controller.rb file is not being loaded automatically when config.cache_classes = false in environment.rb.
It's in the load path. If I add require 'application_controller' to the end of my environment.rb or set cache_classes = true, then the app works fine.
Why wouldn't it load when classes are not being cacehed?
This sounds like it for some reason your app is still using 2.3.2 gems for ActiveSupport. It is probably still looking for application.rb, and the undefined pretty_inspect also lends itself to a versioning problem.
First, make sure that you don't have something like this at the top of your environment.rb:
RAILS_GEM_VERSION = '2.3.2'
If you don't, then at the bottom of the your environment.rb find out if something else is setting it wrong by adding this:
puts RAILS_GEM_VERSION
The application code is loaded as part of the Rails::Initializer.run method in environment.rb. It's almost the last step. I know of nothing that would prevent the application controller from loading -- my only suggestion is to make sure there is not a typo in the filename /app/controllers/application_controller.rb and to make sure there is not a typo in the class definition class ApplicationController < ActionController::Base.
I'd like to add that the first part my last comment applies to production mode, where the classes are eager-loaded in Rails::Initializer#load_application_classes, but in development mode it does not cache classes, so loads them as part of a const_missing catcher each request. See ActiveSupport::Dependencies#load_missing_constant.
I have another idea. You mentioned that it is in the load path, but I would confirm later on that it stays in the load path and that a plugin doesn't mess it up or something. At the very bottom of environment.rb (last line) add this line:
puts ActiveSupport::Dependencies.load_paths.pretty_inspect
Then run a script/server from the command line and take a look at the load paths, making sure /path_to_your_rails_app/app/controllers shows up.
The problem is definitely related to config.cache_classes = false; if I switch this to true then the problem disappears.
(Thanks #Ben Lee for leading me towards this)
I've figured out how to silence the contents of an action by wrapping everything inside the action's method in a logger.silence block.
However, I still get the call to the action showing up in the log file.
I.E:
Processing DashboardController#update (for 66.201.17.166 at 2009-09-09 19:03:27) [GET]
Parameters: {"todos"=>{"user"=>"25", "sfu_type"=>""}}
Completed in 1021ms (View: 439, DB: 438) | 200 OK [http://my.host.com/dashboard/update?todos%5Buser%5D=25&todos%5Bsfu_type%5D=]
I want to either keep the above from getting written to the logs all together, or redirect it to a different log file (i.e. dashboard.log) so it stops cluttering up the production.log file.
I get the above sample written to the log each time the ajax call updates for each user logged in. This updates about every 2 minutes so the production log file is getting flooded with unuseful log messages.
Late answer, but I spent quite a bit of time of the interwebs looking for the answer, which is thus:
In the controller that contains the action you would like to ignore, override the logger method and return the rails default for some actions, and a custom logger or nil for the ones that need special handling.
def logger
if params[:action] == 'action_to_ignore'
# return custom logger or nil
else
RAILS_DEFAULT_LOGGER
end
end
I suspect there is an easier way, and would love to hear it if it exists.
The logger calls are scattered all over ActionController::Base. The only way I can think of is to monkey patch a bunch of methods and check for the name of the controller in question.
Perhaps overriding this method is all you need to do. Not sure. Good luck :)
This looks like a really good, flexible solution using middleware:
http://dennisreimann.de/blog/silencing-the-rails-log-on-a-per-action-basis/
Have you set your production logging level?
config > environments > production.rb
config.log_level = :warn (default is :info)
In the application controller you could override the logger:
def log_error(exception)
#super(exception)
#do my logging here
end
I use this to email me when errors occur in a critical app.