This week in Rails

This week 48 contributors helped to move Rails forward! Want to be one of them? Look at the issues list and make a contribution!

Rails 4.2.6.rc1 and 4.1.15.rc1 have been released!
If no regressions are found expect the final release around March 4, 2016.

These both allow external code to run blocks of user code to do "work" at a similar unit size to a web request without needing to get intimate with ActionDispatch.

This change is intended to allow interested callers (Sidekiq, ActionCable), to just do:

Rails.application.reloader.wrap do
  # run some user code
end

and Rails will take care of the interlock, code reloading, returning ActiveRecord connections to the pool, and anything else that might be relevant.
Exciting, if you have ever been stung by concurrent processing in Jobs, etc.

With related changes from Puma, Puma 3.0 and up introduced compatibility to read from config/puma.rb when booting from the command $ rails server . Rails now depends on Puma 3.0, so that support for config/puma.rb comes out of the box.

The force_ssl option redirects each request to https. This change now allows redirection to be constrained to only whitelisted requests with constrain_to:

config.ssl_options = { redirect: { exclude: -> request { request.path !~ /healthcheck/ } } }

This change makes the application generator create a new file config/spring.rb, which tells Spring to watch additional common files, for example- .ruby-version. This can then be enhanced as per the application's need to reload App changes.

This change added log "Rendering ...", when starting to render a template, to log that we have started to render something, at the very beginning.

This helps to easily identify queries called from controller vs views.

Allowing :controller and :action values to be specified via the path in config/routes.rb has been an underlying cause of a number of issues in Rails that have resulted in security releases. In light of this it's better that controllers and actions are explicitly whitelisted rather than trying to blacklist or sanitize bad values.
This change deprecates passing these options in routes.

This change deprecates {insert|update|delete}_sql in DatabaseStatements in favor of {insert|update|delete} public methods.
Originally, {insert|update|delete}_sql were protected methods, and were not intended for external use.

Module.local_constants has now been deprecated.
After Ruby 1.9 (and since Rails 5 supports ruby 2.2+), we can easily get the constants that have been defined locally by Module.constants(false). Hence, Module.local_constants is no more necessary.