123456789_123456789_123456789_123456789_123456789_

DO NOT READ THIS FILE ON GITHUB, GUIDES ARE PUBLISHED ON http://guides.rubyonrails.org.

Upgrading Ruby on Rails

This guide provides steps to be followed when you upgrade your applications to a newer version of Ruby on Rails. These steps are also available in individual release guides.

General Advice

Before attempting to upgrade an existing application, you should be sure you have a good reason to upgrade. You need to balance several factors: the need for new features, the increasing difficulty of finding support for old code, and your available time and skills, to name a few.

Test Coverage

The best way to be sure that your application still works after upgrading is to have good test coverage before you start the process. If you don't have automated tests that exercise the bulk of your application, you'll need to spend time manually exercising all the parts that have changed. In the case of a Rails upgrade, that will mean every single piece of functionality in the application. Do yourself a favor and make sure your test coverage is good before you start an upgrade.

The Upgrade Process

When changing Rails versions, it's best to move slowly, one minor version at a time, in order to make good use of the deprecation warnings. Rails version numbers are in the form Major.Minor.Patch. Major and Minor versions are allowed to make changes to the public API, so this may cause errors in your application. Patch versions only include bug fixes, and don't change any public API.

The process should go as follows:

  1. Write tests and make sure they pass.
  2. Move to the latest patch version after your current version.
  3. Fix tests and deprecated features.
  4. Move to the latest patch version of the next minor version.

Repeat this process until you reach your target Rails version. Each time you move versions, you will need to change the Rails version number in the Gemfile (and possibly other gem versions) and run bundle update. Then run the Update task mentioned below to update configuration files, then run your tests.

You can find a list of all released Rails versions here.

Ruby Versions

Rails generally stays close to the latest released Ruby version when it's released:

TIP: Ruby 1.8.7 p248 and p249 have marshaling bugs that crash Rails. Ruby Enterprise Edition has these fixed since the release of 1.8.7-2010.02. On the 1.9 front, Ruby 1.9.1 is not usable because it outright segfaults, so if you want to use 1.9.x, jump straight to 1.9.3 for smooth sailing.

The Update Task

Rails provides the app:update task (rake rails:update on 4.2 and earlier). After updating the Rails version in the Gemfile, run this task. This will help you with the creation of new files and changes of old files in an interactive session.

$ rails app:update
   identical  config/boot.rb
       exist  config
    conflict  config/routes.rb
Overwrite /myapp/config/routes.rb? (enter "h" for help) [Ynaqdh]
       force  config/routes.rb
    conflict  config/application.rb
Overwrite /myapp/config/application.rb? (enter "h" for help) [Ynaqdh]
       force  config/application.rb
    conflict  config/environment.rb
...

Don't forget to review the difference, to see if there were any unexpected changes.

Upgrading from Rails 5.1 to Rails 5.2

For more information on changes made to Rails 5.2 please see the release notes.

Bootsnap

Rails 5.2 adds bootsnap gem in the newly generated app's Gemfile. The app:update task sets it up in boot.rb. If you want to use it, then add it in the Gemfile, otherwise change the boot.rb to not use bootsnap.

Expiry in signed or encrypted cookie is now embedded in the cookies values

To improve security, Rails now embeds the expiry information also in encrypted or signed cookies value.

This new embed information make those cookies incompatible with versions of Rails older than 5.2.

If you require your cookies to be read by 5.1 and older, or you are still validating your 5.2 deploy and want to allow you to rollback set Rails.application.config.action_dispatch.use_authenticated_cookie_encryption to false.

Upgrading from Rails 5.0 to Rails 5.1

For more information on changes made to Rails 5.1 please see the release notes.

Top-level HashWithIndifferentAccess is soft-deprecated

If your application uses the top-level HashWithIndifferentAccess class, you should slowly move your code to instead use ::ActiveSupport::HashWithIndifferentAccess.

It is only soft-deprecated, which means that your code will not break at the moment and no deprecation warning will be displayed, but this constant will be removed in the future.

Also, if you have pretty old YAML documents containing dumps of such objects, you may need to load and dump them again to make sure that they reference the right constant, and that loading them won't break in the future.

application.secrets now loaded with all keys as symbols

If your application stores nested configuration in config/secrets.yml, all keys are now loaded as symbols, so access using strings should be changed.

From:

Rails.application.secrets[:smtp_settings]["address"]

To:

Rails.application.secrets[:smtp_settings][:address]

Upgrading from Rails 4.2 to Rails 5.0

For more information on changes made to Rails 5.0 please see the release notes.

Ruby 2.2.2+ required

From Ruby on Rails 5.0 onwards, Ruby 2.2.2+ is the only supported Ruby version. Make sure you are on Ruby 2.2.2 version or greater, before you proceed.

Active Record Models Now Inherit from ApplicationRecord by Default

In Rails 4.2, an Active Record model inherits from ::ActiveRecord::Base. In Rails 5.0, all models inherit from ApplicationRecord.

ApplicationRecord is a new superclass for all app models, analogous to app controllers subclassing ApplicationController instead of ::ActionController::Base. This gives apps a single spot to configure app-wide model behavior.

When upgrading from Rails 4.2 to Rails 5.0, you need to create an application_record.rb file in app/models/ and add the following content:

class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true
end

Then make sure that all your models inherit from it.

Halting Callback Chains via throw(:abort)

In Rails 4.2, when a 'before' callback returns false in Active Record and Active Model, then the entire callback chain is halted. In other words, successive 'before' callbacks are not executed, and neither is the action wrapped in callbacks.

In Rails 5.0, returning false in an Active Record or Active Model callback will not have this side effect of halting the callback chain. Instead, callback chains must be explicitly halted by calling throw(:abort).

When you upgrade from Rails 4.2 to Rails 5.0, returning false in those kind of callbacks will still halt the callback chain, but you will receive a deprecation warning about this upcoming change.

When you are ready, you can opt into the new behavior and remove the deprecation warning by adding the following configuration to your config/application.rb:

ActiveSupport.halt_callback_chains_on_return_false = false

Note that this option will not affect Active Support callbacks since they never halted the chain when any value was returned.

See #17227 for more details.

ActiveJob Now Inherits from ApplicationJob by Default

In Rails 4.2, an Active Job inherits from ::ActiveJob::Base. In Rails 5.0, this behavior has changed to now inherit from ApplicationJob.

When upgrading from Rails 4.2 to Rails 5.0, you need to create an application_job.rb file in app/jobs/ and add the following content:

class ApplicationJob < ActiveJob::Base
end

Then make sure that all your job classes inherit from it.

See #19034 for more details.

Rails Controller Testing

Extraction of some helper methods to rails-controller-testing

assigns and assert_template have been extracted to the rails-controller-testing gem. To continue using these methods in your controller tests, add gem 'rails-controller-testing' to your Gemfile.

If you are using Rspec for testing, please see the extra configuration required in the gem's documentation.

New behavior when uploading files

If you are using ::ActionDispatch::Http::UploadedFile in your tests to upload files, you will need to change to use the similar Rack::Test::UploadedFile class instead.

See #26404 for more details.

Autoloading is Disabled After Booting in the Production Environment

Autoloading is now disabled after booting in the production environment by default.

Eager loading the application is part of the boot process, so top-level constants are fine and are still autoloaded, no need to require their files.

Constants in deeper places only executed at runtime, like regular method bodies, are also fine because the file defining them will have been eager loaded while booting.

For the vast majority of applications this change needs no action. But in the very rare event that your application needs autoloading while running in production mode, set Rails.application.config.enable_dependency_loading to true.

XML Serialization

ActiveModel::Serializers::Xml has been extracted from Rails to the activemodel-serializers-xml gem. To continue using XML serialization in your application, add gem 'activemodel-serializers-xml' to your Gemfile.

Removed Support for Legacy mysql Database Adapter

Rails 5 removes support for the legacy mysql database adapter. Most users should be able to use mysql2 instead. It will be converted to a separate gem when we find someone to maintain it.

Removed Support for Debugger

debugger is not supported by Ruby 2.2 which is required by Rails 5. Use byebug instead.

Use bin/rails for running tasks and tests

Rails 5 adds the ability to run tasks and tests through bin/rails instead of rake. Generally these changes are in parallel with rake, but some were ported over altogether.

To use the new test runner simply type bin/rails test.

rake dev:cache is now rails dev:cache.

Run bin/rails to see the list of commands available.

::ActionController::Parameters No Longer Inherits from HashWithIndifferentAccess

Calling params in your application will now return an object instead of a hash. If your parameters are already permitted, then you will not need to make any changes. If you are using map and other methods that depend on being able to read the hash regardless of permitted? you will need to upgrade your application to first permit and then convert to a hash.

params.permit([:proceed_to, :return_to]).to_h

protect_from_forgery Now Defaults to prepend: false

protect_from_forgery defaults to prepend: false which means that it will be inserted into the callback chain at the point in which you call it in your application. If you want protect_from_forgery to always run first, then you should change your application to use protect_from_forgery prepend: true.

Default Template Handler is Now RAW

Files without a template handler in their extension will be rendered using the raw handler. Previously Rails would render files using the ERB template handler.

If you do not want your file to be handled via the raw handler, you should add an extension to your file that can be parsed by the appropriate template handler.

Added Wildcard Matching for Template Dependencies

You can now use wildcard matching for your template dependencies. For example, if you were defining your templates as such:

<% # Template Dependency: recordings/threads/events/subscribers_changed %>
<% # Template Dependency: recordings/threads/events/completed %>
<% # Template Dependency: recordings/threads/events/uncompleted %>

You can now just call the dependency once with a wildcard.

<% # Template Dependency: recordings/threads/events/* %>

::ActionView::Helpers::RecordTagHelper moved to external gem (record_tag_helper)

content_tag_for and div_for have been removed in favor of just using content_tag. To continue using the older methods, add the record_tag_helper gem to your Gemfile:

gem 'record_tag_helper', '~> 1.0'

See #18411 for more details.

Removed Support for protected_attributes Gem

The protected_attributes gem is no longer supported in Rails 5.

Removed support for activerecord-deprecated_finders gem

The activerecord-deprecated_finders gem is no longer supported in Rails 5.

::ActiveSupport::TestCase Default Test Order is Now Random

When tests are run in your application, the default order is now :random instead of :sorted. Use the following config option to set it back to :sorted.

# config/environments/test.rb
Rails.application.configure do
  config.active_support.test_order = :sorted
end

::ActionController::Live became a Concern

If you include ::ActionController::Live in another module that is included in your controller, then you should also extend the module with ::ActiveSupport::Concern. Alternatively, you can use the self.included hook to include ::ActionController::Live directly to the controller once the StreamingSupport is included.

This means that if your application used to have its own streaming module, the following code would break in production mode:

# This is a work-around for streamed controllers performing authentication with Warden/Devise.
# See https://github.com/plataformatec/devise/issues/2332
# Authenticating in the router is another solution as suggested in that issue
class StreamingSupport
  include ActionController::Live # this won't work in production for Rails 5
  # extend ActiveSupport::Concern # unless you uncomment this line.

  def process(name)
    super(name)
  rescue ArgumentError => e
    if e.message == 'uncaught throw :warden'
      throw :warden
    else
      raise e
    end
  end
end

New Framework Defaults

Active Record belongs_to Required by Default Option

belongs_to will now trigger a validation error by default if the association is not present.

This can be turned off per-association with optional: true.

This default will be automatically configured in new applications. If existing application want to add this feature it will need to be turned on in an initializer.

config.active_record.belongs_to_required_by_default = true

Per-form CSRF Tokens

Rails 5 now supports per-form CSRF tokens to mitigate against code-injection attacks with forms created by JavaScript. With this option turned on, forms in your application will each have their own CSRF token that is specified to the action and method for that form.

config.action_controller.per_form_csrf_tokens = true

Forgery Protection with Origin Check

You can now configure your application to check if the HTTP Origin header should be checked against the site's origin as an additional CSRF defense. Set the following in your config to true:

config.action_controller.forgery_protection_origin_check = true

Allow Configuration of Action Mailer Queue Name

The default mailer queue name is mailers. This configuration option allows you to globally change the queue name. Set the following in your config:

config.action_mailer.deliver_later_queue_name = :new_queue_name

Support Fragment Caching in Action Mailer Views

Set config.action_mailer.perform_caching in your config to determine whether your Action Mailer views should support caching.

config.action_mailer.perform_caching = true

Configure the Output of db:structure:dump

If you're using schema_search_path or other PostgreSQL extensions, you can control how the schema is dumped. Set to :all to generate all dumps, or to :schema_search_path to generate from schema search path.

config.active_record.dump_schemas = :all

Configure SSL Options to Enable HSTS with Subdomains

Set the following in your config to enable HSTS when using subdomains:

config.ssl_options = { hsts: { subdomains: true } }

Preserve Timezone of the Receiver

When using Ruby 2.4, you can preserve the timezone of the receiver when calling to_time.

ActiveSupport.to_time_preserves_timezone = false

Changes with JSON/JSONB serialization

In Rails 5.0, how JSON/JSONB attributes are serialized and deserialized changed. Now, if you set a column equal to a String, Active Record will no longer turn that string into a Hash, and will instead only return the string. This is not limited to code interacting with models, but also affects :default column settings in db/schema.rb. It is recommended that you do not set columns equal to a String, but pass a Hash instead, which will be converted to and from a JSON string automatically.

Upgrading from Rails 4.1 to Rails 4.2

Web Console

First, add gem 'web-console', '~> 2.0' to the :development group in your Gemfile and run bundle install (it won't have been included when you upgraded Rails). Once it's been installed, you can simply drop a reference to the console helper (i.e., <%= console %>) into any view you want to enable it for. A console will also be provided on any error page you view in your development environment.

Responders

respond_with and the class-level respond_to methods have been extracted to the responders gem. To use them, simply add gem 'responders', '~> 2.0' to your Gemfile. Calls to respond_with and respond_to (again, at the class level) will no longer work without having included the responders gem in your dependencies:

# app/controllers/users_controller.rb

class UsersController < ApplicationController
  respond_to :html, :json

  def show
    @user = User.find(params[:id])
    respond_with @user
  end
end

Instance-level respond_to is unaffected and does not require the additional gem:

# app/controllers/users_controller.rb

class UsersController < ApplicationController
  def show
    @user = User.find(params[:id])
    respond_to do |format|
      format.html
      format.json { render json: @user }
    end
  end
end

See #16526 for more details.

Error handling in transaction callbacks

Currently, Active Record suppresses errors raised within after_rollback or after_commit callbacks and only prints them to the logs. In the next version, these errors will no longer be suppressed. Instead, the errors will propagate normally just like in other Active Record callbacks.

When you define an after_rollback or after_commit callback, you will receive a deprecation warning about this upcoming change. When you are ready, you can opt into the new behavior and remove the deprecation warning by adding following configuration to your config/application.rb:

config.active_record.raise_in_transactional_callbacks = true

See #14488 and #16537 for more details.

Ordering of test cases

In Rails 5.0, test cases will be executed in random order by default. In anticipation of this change, Rails 4.2 introduced a new configuration option active_support.test_order for explicitly specifying the test ordering. This allows you to either lock down the current behavior by setting the option to :sorted, or opt into the future behavior by setting the option to :random.

If you do not specify a value for this option, a deprecation warning will be emitted. To avoid this, add the following line to your test environment:

# config/environments/test.rb
Rails.application.configure do
  config.active_support.test_order = :sorted # or `:random` if you prefer
end

Serialized attributes

When using a custom coder (e.g. serialize :metadata, JSON), assigning nil to a serialized attribute will save it to the database as NULL instead of passing the nil value through the coder (e.g. "null" when using the JSON coder).

Production log level

In Rails 5, the default log level for the production environment will be changed to :debug (from :info). To preserve the current default, add the following line to your production.rb:

# Set to `:info` to match the current default, or set to `:debug` to opt-into
# the future default.
config.log_level = :info

after_bundle in Rails templates

If you have a Rails template that adds all the files in version control, it fails to add the generated binstubs because it gets executed before Bundler:

# template.rb
generate(:scaffold, "person name:string")
route "root to: 'people#index'"
rake("db:migrate")

git :init
git add: "."
git commit: %Q{ -m 'Initial commit' }

You can now wrap the git calls in an after_bundle block. It will be run after the binstubs have been generated.

# template.rb
generate(:scaffold, "person name:string")
route "root to: 'people#index'"
rake("db:migrate")

after_bundle do
  git :init
  git add: "."
  git commit: %Q{ -m 'Initial commit' }
end

Rails HTML Sanitizer

There's a new choice for sanitizing HTML fragments in your applications. The venerable html-scanner approach is now officially being deprecated in favor of Rails HTML Sanitizer.

This means the methods sanitize, sanitize_css, strip_tags and strip_links are backed by a new implementation.

This new sanitizer uses Loofah internally. Loofah in turn uses Nokogiri, which wraps XML parsers written in both C and Java, so sanitization should be faster no matter which Ruby version you run.

The new version updates sanitize, so it can take a Loofah::Scrubber for powerful scrubbing. See some examples of scrubbers here.

Two new scrubbers have also been added: PermitScrubber and TargetScrubber. Read the gem's readme for more information.

The documentation for PermitScrubber and TargetScrubber explains how you can gain complete control over when and how elements should be stripped.

If your application needs to use the old sanitizer implementation, include rails-deprecated_sanitizer in your Gemfile:

gem 'rails-deprecated_sanitizer'

Rails DOM Testing

The TagAssertionsmodule (containing methods such asassert_tag), has been deprecated in favor of the assert_select` methods from the {SelectorAssertions} module, which has been extracted into the {https://github.com/rails/rails-dom-testing rails-dom-testing gem}.

Masked Authenticity Tokens

In order to mitigate SSL attacks, form_authenticity_token is now masked so that it varies with each request. Thus, tokens are validated by unmasking and then decrypting. As a result, any strategies for verifying requests from non-rails forms that relied on a static session CSRF token have to take this into account.

Action Mailer

Previously, calling a mailer method on a mailer class will result in the corresponding instance method being executed directly. With the introduction of Active Job and #deliver_later, this is no longer true. In Rails 4.2, the invocation of the instance methods are deferred until either deliver_now or deliver_later is called. For example:

class Notifier < ActionMailer::Base
  def notify(user, ...)
    puts "Called"
    mail(to: user.email, ...)
  end
end

mail = Notifier.notify(user, ...) # Notifier#notify is not yet called at this point
mail = mail.deliver_now           # Prints "Called"

This should not result in any noticeable differences for most applications. However, if you need some non-mailer methods to be executed synchronously, and you were previously relying on the synchronous proxying behavior, you should define them as class methods on the mailer class directly:

class Notifier < ActionMailer::Base
  def self.broadcast_notifications(users, ...)
    users.each { |user| Notifier.notify(user, ...) }
  end
end

Foreign Key Support

The migration DSL has been expanded to support foreign key definitions. If you've been using the Foreigner gem, you might want to consider removing it. Note that the foreign key support of Rails is a subset of Foreigner. This means that not every Foreigner definition can be fully replaced by its Rails migration DSL counterpart.

The migration procedure is as follows:

  1. remove gem "foreigner" from the {Gemfile}.
  2. run bundle install.
  3. run bin/rake db:schema:dump.
  4. make sure that db/schema.rb contains every foreign key definition with the necessary options.

Upgrading from Rails 4.0 to Rails 4.1

CSRF protection from remote <script> tags

Or, "whaaat my tests are failing!!!?" or "my <script> widget is busted!!"

Cross-site request forgery (CSRF) protection now covers GET requests with JavaScript responses, too. This prevents a third-party site from remotely referencing your JavaScript with a <script> tag to extract sensitive data.

This means that your functional and integration tests that use

get :index, format: :js

will now trigger CSRF protection. Switch to

xhr :get, :index, format: :js

to explicitly test an {XmlHttpRequest}.

Note: Your own <script> tags are treated as cross-origin and blocked by default, too. If you really mean to load JavaScript from <script> tags, you must now explicitly skip CSRF protection on those actions.

Spring

If you want to use Spring as your application preloader you need to:

  1. Add gem 'spring', group: :development to your {Gemfile}.
  2. Install spring using bundle install.
  3. Springify your binstubs with bundle exec spring binstub --all.

NOTE: User defined rake tasks will run in the development environment by default. If you want them to run in other environments consult the {https://github.com/rails/spring#rake Spring README}.

config/secrets.yml

If you want to use the new secrets.yml convention to store your application's secrets, you need to:

  1. Create a secrets.yml file in your config folder with the following content:

    development:
  secret_key_base:

test:
  secret_key_base:

production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

  2. Use your existing secret_key_base from the secret_token.rb initializer to set the SECRET_KEY_BASE environment variable for whichever users running the Rails application in production mode. Alternatively, you can simply copy the existing secret_key_base from the secret_token.rb initializer to secrets.yml under the production section, replacing '<%= ENV["SECRET_KEY_BASE"] %>'.

  3. Remove the secret_token.rb initializer.

  4. Use rake secret to generate new keys for the development and test sections.

  5. Restart your server.

Changes to test helper

If your test helper contains a call to {ActiveRecord::Migration.check_pending!} this can be removed. The check is now done automatically when you require 'rails/test_help', although leaving this line in your helper is not harmful in any way.

Cookies serializer

Applications created before Rails 4.1 uses {Marshal} to serialize cookie values into the signed and encrypted cookie jars. If you want to use the new {JSON}-based format in your application, you can add an initializer file with the following content:

Rails.application.config.action_dispatch.cookies_serializer = :hybrid

This would transparently migrate your existing {Marshal}-serialized cookies into the new {JSON}-based format.

When using the :json or :hybrid serializer, you should beware that not all Ruby objects can be serialized as JSON. For example, {Date} and {Time} objects will be serialized as strings, and {Hash}es will have their keys stringified.

class CookiesController < ApplicationController
  def set_cookie
    cookies.encrypted[:expiration_date] = Date.tomorrow # => Thu, 20 Mar 2014
    redirect_to action: 'read_cookie'
  end

  def read_cookie
    cookies.encrypted[:expiration_date] # => "2014-03-20"
  end
end

It's advisable that you only store simple data (strings and numbers) in cookies. If you have to store complex objects, you would need to handle the conversion manually when reading the values on subsequent requests.

If you use the cookie session store, this would apply to the session and flash hash as well.

Flash structure changes

Flash message keys are {https://github.com/rails/rails/commit/a668beffd64106a1e1fedb71cc25eaaa11baf0c1 normalized to strings}. They can still be accessed using either symbols or strings. Looping through the flash will always yield string keys:

flash["string"] = "a string"
flash[:symbol] = "a symbol"

# Rails < 4.1
flash.keys # => ["string", :symbol]

# Rails >= 4.1
flash.keys # => ["string", "symbol"]

Make sure you are comparing Flash message keys against strings.

Changes in JSON handling

There are a few major changes related to JSON handling in Rails 4.1.

MultiJSON removal

MultiJSON has reached its {https://github.com/rails/rails/pull/10576 end-of-life} and has been removed from Rails.

If your application currently depends on MultiJSON directly, you have a few options:

  1. Add 'multi_json' to your {Gemfile}. Note that this might cease to work in the future

  2. Migrate away from MultiJSON by using obj.to_json, and {JSON.parse(str)} instead.

WARNING: Do not simply replace {MultiJson.dump} and {MultiJson.load} with {JSON.dump} and {JSON.load}. These JSON gem APIs are meant for serializing and deserializing arbitrary Ruby objects and are generally {http://www.ruby-doc.org/stdlib-2.2.2/libdoc/json/rdoc/JSON.html#method-i-load unsafe}.

JSON gem compatibility

Historically, Rails had some compatibility issues with the JSON gem. Using {JSON.generate} and {JSON.dump} inside a Rails application could produce unexpected errors.

Rails 4.1 fixed these issues by isolating its own encoder from the JSON gem. The JSON gem APIs will function as normal, but they will not have access to any Rails-specific features. For example:

class FooBar
  def as_json(options = nil)
    { foo: 'bar' }
  end
end

>> FooBar.new.to_json # => "{\"foo\":\"bar\"}"
>> JSON.generate(FooBar.new, quirks_mode: true) # => "\"#<FooBar:0x007fa80a481610>\""

New JSON encoder

The JSON encoder in Rails 4.1 has been rewritten to take advantage of the JSON gem. For most applications, this should be a transparent change. However, as part of the rewrite, the following features have been removed from the encoder:

  1. Circular data structure detection
  2. Support for the encode_json hook
  3. Option to encode {BigDecimal} objects as numbers instead of strings

If your application depends on one of these features, you can get them back by adding the {https://github.com/rails/activesupport-json_encoder activesupport-json_encoder} gem to your {Gemfile}.

JSON representation of Time objects

#as_json for objects with time component ({Time}, {DateTime}, {ActiveSupport::TimeWithZone}) now returns millisecond precision by default. If you need to keep old behavior with no millisecond precision, set the following in an initializer:

ActiveSupport::JSON::Encoding.time_precision = 0

Usage of return within inline callback blocks

Previously, Rails allowed inline callback blocks to use return this way:

class ReadOnlyModel < ActiveRecord::Base
  before_save { return false } # BAD
end

This behavior was never intentionally supported. Due to a change in the internals of {ActiveSupport::Callbacks}, this is no longer allowed in Rails 4.1. Using a return statement in an inline callback block causes a {LocalJumpError} to be raised when the callback is executed.

Inline callback blocks using return can be refactored to evaluate to the returned value:

class ReadOnlyModel < ActiveRecord::Base
  before_save { false } # GOOD
end

Alternatively, if return is preferred it is recommended to explicitly define a method:

class ReadOnlyModel < ActiveRecord::Base
  before_save :before_save_callback # GOOD

  private
    def before_save_callback
      return false
    end
end

This change applies to most places in Rails where callbacks are used, including Active Record and Active Model callbacks, as well as filters in Action Controller (e.g. before_action).

See {https://github.com/rails/rails/pull/13271 this pull request} for more details.

Methods defined in Active Record fixtures

Rails 4.1 evaluates each fixture's ERB in a separate context, so helper methods defined in a fixture will not be available in other fixtures.

Helper methods that are used in multiple fixtures should be defined on modules included in the newly introduced {ActiveRecord::FixtureSet.context_class}, in test_helper.rb.

module FixtureFileHelpers
  def file_sha(path)
    Digest::SHA2.hexdigest(File.read(Rails.root.join('test/fixtures', path)))
  end
end
ActiveRecord::FixtureSet.context_class.include FixtureFileHelpers

I18n enforcing available locales

Rails 4.1 now defaults the I18n option enforce_available_locales to true. This means that it will make sure that all locales passed to it must be declared in the available_locales list.

To disable it (and allow I18n to accept any locale option) add the following configuration to your application:

config.i18n.enforce_available_locales = false

Note that this option was added as a security measure, to ensure user input cannot be used as locale information unless it is previously known. Therefore, it's recommended not to disable this option unless you have a strong reason for doing so.

Mutator methods called on Relation

{Relation} no longer has mutator methods like #map! and #delete_if. Convert to an {Array} by calling #to_a before using these methods.

It intends to prevent odd bugs and confusion in code that call mutator methods directly on the {Relation}.

# Instead of this
Author.where(name: 'Hank Moody').compact!

# Now you have to do this
authors = Author.where(name: 'Hank Moody').to_a
authors.compact!

Changes on Default Scopes

Default scopes are no longer overridden by chained conditions.

In previous versions when you defined a default_scope in a model it was overridden by chained conditions in the same field. Now it is merged like any other scope.

Before:

class User < ActiveRecord::Base
  default_scope { where state: 'pending' }
  scope :active, -> { where state: 'active' }
  scope :inactive, -> { where state: 'inactive' }
end

User.all
# SELECT "users".* FROM "users" WHERE "users"."state" = 'pending'

User.active
# SELECT "users".* FROM "users" WHERE "users"."state" = 'active'

User.where(state: 'inactive')
# SELECT "users".* FROM "users" WHERE "users"."state" = 'inactive'

After:

class User < ActiveRecord::Base
  default_scope { where state: 'pending' }
  scope :active, -> { where state: 'active' }
  scope :inactive, -> { where state: 'inactive' }
end

User.all
# SELECT "users".* FROM "users" WHERE "users"."state" = 'pending'

User.active
# SELECT "users".* FROM "users" WHERE "users"."state" = 'pending' AND "users"."state" = 'active'

User.where(state: 'inactive')
# SELECT "users".* FROM "users" WHERE "users"."state" = 'pending' AND "users"."state" = 'inactive'

To get the previous behavior it is needed to explicitly remove the default_scope condition using unscoped, unscope, rewhere or except.

class User < ActiveRecord::Base
  default_scope { where state: 'pending' }
  scope :active, -> { unscope(where: :state).where(state: 'active') }
  scope :inactive, -> { rewhere state: 'inactive' }
end

User.all
# SELECT "users".* FROM "users" WHERE "users"."state" = 'pending'

User.active
# SELECT "users".* FROM "users" WHERE "users"."state" = 'active'

User.inactive
# SELECT "users".* FROM "users" WHERE "users"."state" = 'inactive'

Rendering content from string

Rails 4.1 introduces :plain, :html, and :body options to render. Those options are now the preferred way to render string-based content, as it allows you to specify which content type you want the response sent as.

From the security standpoint, if you don't expect to have any markup in your response body, you should be using render :plain as most browsers will escape unsafe content in the response for you.

We will be deprecating the use of render :text in a future version. So please start using the more precise :plain, :html, and :body options instead. Using render :text may pose a security risk, as the content is sent as text/html.

PostgreSQL json and hstore datatypes

Rails 4.1 will map json and hstore columns to a string-keyed Ruby {Hash}. In earlier versions, a {HashWithIndifferentAccess} was used. This means that symbol access is no longer supported. This is also the case for store_accessors based on top of json or hstore columns. Make sure to use string keys consistently.

Explicit block use for {ActiveSupport::Callbacks}

Rails 4.1 now expects an explicit block to be passed when calling {ActiveSupport::Callbacks.set_callback}. This change stems from {ActiveSupport::Callbacks} being largely rewritten for the 4.1 release.

# Previously in Rails 4.0
set_callback :save, :around, ->(r, &block) { stuff; result = block.call; stuff }

# Now in Rails 4.1
set_callback :save, :around, ->(r, block) { stuff; result = block.call; stuff }

Upgrading from Rails 3.2 to Rails 4.0

If your application is currently on any version of Rails older than 3.2.x, you should upgrade to Rails 3.2 before attempting one to Rails 4.0.

The following changes are meant for upgrading your application to Rails 4.0.

HTTP PATCH

Rails 4 now uses {PATCH} as the primary HTTP verb for updates when a RESTful resource is declared in config/routes.rb. The update action is still used, and {PUT} requests will continue to be routed to the update action as well. So, if you're using only the standard RESTful routes, no changes need to be made:

resources :users
<%= form_for @user do |f| %>

class UsersController < ApplicationController
  def update
    # No change needed; PATCH will be preferred, and PUT will still work.
  end
end

However, you will need to make a change if you are using form_for to update a resource in conjunction with a custom route using the {PUT} HTTP method:

resources :users, do
  put :update_name, on: :member
end
<%= form_for [ :update_name, @user ] do |f| %>

class UsersController < ApplicationController
  def update_name
    # Change needed; form_for will try to use a non-existent PATCH route.
  end
end

If the action is not being used in a public API and you are free to change the HTTP method, you can update your route to use patch instead of put:

{PUT} requests to /users/:id in Rails 4 get routed to update as they are today. So, if you have an API that gets real PUT requests it is going to work. The router also routes {PATCH} requests to /users/:id to the update action.

resources :users do
  patch :update_name, on: :member
end

If the action is being used in a public API and you can't change to HTTP method being used, you can update your form to use the {PUT} method instead:

<%= form_for [ :update_name, @user ], method: :put do |f| %>

For more on PATCH and why this change was made, see {http://weblog.rubyonrails.org/2012/2/26/edge-rails-patch-is-the-new-primary-http-method-for-updates/ this post} on the Rails blog.

A note about media types

The errata for the {PATCH} verb {http://www.rfc-editor.org/errata_search.php?rfc=5789 specifies that a 'diff' media type should be used with `PATCH}. One such format is {https://tools.ietf.org/html/rfc6902 JSON Patch}. While Rails does not support JSON Patch natively, it's easy enough to add support:

# in your controller
def update
  respond_to do |format|
    format.json do
      # perform a partial update
      @article.update params[:article]
    end

    format.json_patch do
      # perform sophisticated change
    end
  end
end

# In config/initializers/json_patch.rb:
Mime::Type.register 'application/json-patch+json', :json_patch

As JSON Patch was only recently made into an RFC, there aren't a lot of great Ruby libraries yet. Aaron Patterson's {https://github.com/tenderlove/hana hana} is one such gem, but doesn't have full support for the last few changes in the specification.

Gemfile

Rails 4.0 removed the assets group from {Gemfile}. You'd need to remove that line from your {Gemfile} when upgrading. You should also update your application file (in config/application.rb):

# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)

vendor/plugins

Rails 4.0 no longer supports loading plugins from vendor/plugins. You must replace any plugins by extracting them to gems and adding them to your {Gemfile}. If you choose not to make them gems, you can move them into, say, lib/my_plugin/* and add an appropriate initializer in config/initializers/my_plugin.rb.

Active Record

scope :active, where(active: true)

# becomes
scope :active, -> { where active: true }
CatalogCategory < ActiveRecord::Base
  has_and_belongs_to_many :catalog_products, join_table: 'catalog_categories_catalog_products'
end

CatalogProduct < ActiveRecord::Base
  has_and_belongs_to_many :catalog_categories, join_table: 'catalog_categories_catalog_products'
end

Active Resource

Rails 4.0 extracted Active Resource to its own gem. If you still need the feature you can add the {https://github.com/rails/activeresource Active Resource gem} in your {Gemfile}.

Active Model

# Disable root element in JSON by default.
# ActiveSupport.on_load(:active_record) do
#   self.include_root_in_json = false
# end

Action Pack

# config/initializers/secret_token.rb
Myapp::Application.config.secret_token = 'existing secret token'
Myapp::Application.config.secret_key_base = 'new secret key base'

Please note that you should wait to set secret_key_base until you have 100% of your userbase on Rails 4.x and are reasonably sure you will not need to rollback to Rails 3.x. This is because cookies signed based on the new secret_key_base in Rails 4.x are not backwards compatible with Rails 3.x. You are free to leave your existing secret_token in place, not set the new secret_key_base, and ignore the deprecation warnings until you are reasonably sure that your upgrade is otherwise complete.

If you are relying on the ability for external applications or JavaScript to be able to read your Rails app's signed session cookies (or signed cookies in general) you should not set secret_key_base until you have decoupled these concerns.

Please read {https://github.com/rails/rails/pull/9978 Pull Request #9978} for details on the move to encrypted session cookies.

get 'one' => 'test#example', as: :example
get 'two' => 'test#example', as: :example
resources :examples
get 'clashing/:id' => 'test#example', as: :example

In the first case, you can simply avoid using the same name for multiple routes. In the second, you can use the only or except options provided by the resources method to restrict the routes created as detailed in the Routing Guide.

get Rack::Utils.escape('こんにちは'), controller: 'welcome', action: 'index'

becomes

get 'こんにちは', controller: 'welcome', action: 'index'
# Rails 3.x
match '/' => 'root#index'

# becomes
match '/' => 'root#index', via: :get

# or
get '/' => 'root#index'

Remember you must also remove any references to the middleware from your application code, for example:

# Raise exception
config.middleware.insert_before(Rack::Lock, ActionDispatch::BestStandardsSupport)

Also check your environment settings for config.action_dispatch.best_standards_support and remove it if present.

config.action_dispatch.default_headers = {
  'X-Frame-Options' => 'SAMEORIGIN',
  'X-XSS-Protection' => '1; mode=block'
}

Please note that if your application is dependent on loading certain pages in a <frame> or <iframe>, then you may need to explicitly set {X-Frame-Options} to ALLOW-FROM ... or {ALLOWALL}.

Active Support

Rails 4.0 removes the j alias for {ERB::Util#json_escape} since j is already used for {ActionView::Helpers::JavaScriptHelper#escape_javascript}.

Cache

The caching method changed between Rails 3.x and 4.0. You should {http://guides.rubyonrails.org/caching_with_rails.html#activesupport-cache-store change the cache namespace} and roll out with a cold cache.

Helpers Loading Order

The order in which helpers from more than one directory are loaded has changed in Rails 4.0. Previously, they were gathered and then sorted alphabetically. After upgrading to Rails 4.0, helpers will preserve the order of loaded directories and will be sorted alphabetically only within each directory. Unless you explicitly use the helpers_path parameter, this change will only impact the way of loading helpers from engines. If you rely on the ordering, you should check if correct methods are available after upgrade. If you would like to change the order in which engines are loaded, you can use config.railties_order= method.

Active Record Observer and Action Controller Sweeper

{ActiveRecord::Observer} and {ActionController::Caching::Sweeper} have been extracted to the rails-observers gem. You will need to add the rails-observers gem if you require these features.

sprockets-rails

config.assets.js_compressor = :uglifier

sass-rails

Upgrading from Rails 3.1 to Rails 3.2

If your application is currently on any version of Rails older than 3.1.x, you should upgrade to Rails 3.1 before attempting an update to Rails 3.2.

The following changes are meant for upgrading your application to the latest 3.2.x version of Rails.

Gemfile

Make the following changes to your {Gemfile}.

gem 'rails', '3.2.21'

group :assets do
  gem 'sass-rails',   '~> 3.2.6'
  gem 'coffee-rails', '~> 3.2.2'
  gem 'uglifier',     '>= 1.0.3'
end

config/environments/development.rb

There are a couple of new configuration settings that you should add to your development environment:

# Raise exception on mass assignment protection for Active Record models
config.active_record.mass_assignment_sanitizer = :strict

# Log the query plan for queries taking more than this (works
# with SQLite, MySQL, and PostgreSQL)
config.active_record.auto_explain_threshold_in_seconds = 0.5

config/environments/test.rb

The mass_assignment_sanitizer configuration setting should also be added to config/environments/test.rb:

# Raise exception on mass assignment protection for Active Record models
config.active_record.mass_assignment_sanitizer = :strict

vendor/plugins

Rails 3.2 deprecates vendor/plugins and Rails 4.0 will remove them completely. While it's not strictly necessary as part of a Rails 3.2 upgrade, you can start replacing any plugins by extracting them to gems and adding them to your {Gemfile}. If you choose not to make them gems, you can move them into, say, lib/my_plugin/* and add an appropriate initializer in config/initializers/my_plugin.rb.

Active Record

Option :dependent => :restrict has been removed from belongs_to. If you want to prevent deleting the object if there are any associated objects, you can set :dependent => :destroy and return false after checking for existence of association from any of the associated object's destroy callbacks.

Upgrading from Rails 3.0 to Rails 3.1

If your application is currently on any version of Rails older than 3.0.x, you should upgrade to Rails 3.0 before attempting an update to Rails 3.1.

The following changes are meant for upgrading your application to Rails 3.1.12, the last 3.1.x version of Rails.

Gemfile

Make the following changes to your {Gemfile}.

gem 'rails', '3.1.12'
gem 'mysql2'

# Needed for the new asset pipeline
group :assets do
  gem 'sass-rails',   '~> 3.1.7'
  gem 'coffee-rails', '~> 3.1.1'
  gem 'uglifier',     '>= 1.0.3'
end

# jQuery is the default JavaScript library in Rails 3.1
gem 'jquery-rails'

config/application.rb

The asset pipeline requires the following additions:

config.assets.enabled = true
config.assets.version = '1.0'

If your application is using an "/assets" route for a resource you may want change the prefix used for assets to avoid conflicts:

# Defaults to '/assets'
config.assets.prefix = '/asset-files'

config/environments/development.rb

Remove the RJS setting config.action_view.debug_rjs = true.

Add these settings if you enable the asset pipeline:

# Do not compress assets
config.assets.compress = false

# Expands the lines which load the assets
config.assets.debug = true

config/environments/production.rb

Again, most of the changes below are for the asset pipeline. You can read more about these in the {file:asset_pipeline.html Asset Pipeline} guide.

# Compress JavaScripts and CSS
config.assets.compress = true

# Don't fallback to assets pipeline if a precompiled asset is missed
config.assets.compile = false

# Generate digests for assets URLs
config.assets.digest = true

# Defaults to Rails.root.join("public/assets")
# config.assets.manifest = YOUR_PATH

# Precompile additional assets (application.js, application.css, and all non-JS/CSS are already added)
# config.assets.precompile += %w( admin.js admin.css )

# Force all access to the app over SSL, use Strict-Transport-Security, and use secure cookies.
# config.force_ssl = true

config/environments/test.rb

You can help test performance with these additions to your test environment:

# Configure static asset server for tests with Cache-Control for performance
config.public_file_server.enabled = true
config.public_file_server.headers = {
  'Cache-Control' => 'public, max-age=3600'
}

config/initializers/wrap_parameters.rb

Add this file with the following contents, if you wish to wrap parameters into a nested hash. This is on by default in new applications.

# Be sure to restart your server when you modify this file.
# This file contains settings for ActionController::ParamsWrapper which
# is enabled by default.

# Enable parameter wrapping for JSON. You can disable this by setting :format to an empty array.
ActiveSupport.on_load(:action_controller) do
  wrap_parameters format: [:json]
end

# Disable root element in JSON by default.
ActiveSupport.on_load(:active_record) do
  self.include_root_in_json = false
end

config/initializers/session_store.rb

You need to change your session key to something new, or remove all sessions:

# in config/initializers/session_store.rb
AppName::Application.config.session_store :cookie_store, key: 'SOMETHINGNEW'

or

$ bin/rake db:sessions:clear

Remove :cache and :concat options in asset helpers references in views