**DO NOT READ THIS FILE ON GITHUB, GUIDES ARE PUBLISHED ON https://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. ### Ruby Versions Rails generally stays close to the latest released Ruby version when it's released: * Rails 7 requires Ruby 2.7.0 or newer. * Rails 6 requires Ruby 2.5.0 or newer. * Rails 5 requires Ruby 2.2.2 or newer. It's a good idea to upgrade Ruby and Rails separately. Upgrade to the latest Ruby you can first, and then upgrade Rails. ### 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. #### Moving between versions To move between versions: 1. Change the Rails version number in the `Gemfile` and run `bundle update`. 2. Change the versions for Rails JavaScript packages in `package.json` and run `yarn install`, if running on Webpacker. 3. Run the [Update task](#the-update-task). 4. Run your tests. You can find a list of all released Rails gems [here](https://rubygems.org/gems/rails/versions). ### The Update Task Rails provides the `rails app:update` command. After updating the Rails version in the `Gemfile`, run this command. This will help you with the creation of new files and changes of old files in an interactive session. ```bash $ bin/rails app:update exist config conflict config/application.rb Overwrite /myapp/config/application.rb? (enter "h" for help) [Ynaqdh] force config/application.rb create config/initializers/new_framework_defaults_7_0.rb ... ``` Don't forget to review the difference, to see if there were any unexpected changes. ### Configure Framework Defaults The new Rails version might have different configuration defaults than the previous version. However, after following the steps described above, your application would still run with configuration defaults from the *previous* Rails version. That's because the value for `config.load_defaults` in `config/application.rb` has not been changed yet. To allow you to upgrade to new defaults one by one, the update task has created a file `config/initializers/new_framework_defaults_X.Y.rb` (with the desired Rails version in the filename). You should enable the new configuration defaults by uncommenting them in the file; this can be done gradually over several deployments. Once your application is ready to run with new defaults, you can remove this file and flip the `config.load_defaults` value. Upgrading from Rails 7.0 to Rails 7.1 ------------------------------------- ### Autoloaded paths are no longer in load path Starting from Rails 7.1, all paths managed by the autoloader will no longer be added to `$LOAD_PATH`. This means it won't be possible to load them with a manual `require` call, the class or module can be referenced instead. Reducing the size of `$LOAD_PATH` speed-up `require` calls for apps not using `bootsnap`, and reduce the size of the `bootsnap` cache for the others. Upgrading from Rails 6.1 to Rails 7.0 ------------------------------------- ### `ActionView::Helpers::UrlHelper#button_to` changed behavior Starting from Rails 7.0 `button_to` renders a `form` tag with `patch` HTTP verb if a persisted Active Record object is used to build button URL. To keep current behavior consider explicitly passing `method:` option: ```diff -button_to("Do a POST", [:my_custom_post_action_on_workshop, Workshop.find(1)]) +button_to("Do a POST", [:my_custom_post_action_on_workshop, Workshop.find(1)], method: :post) ``` or using helper to build the URL: ```diff -button_to("Do a POST", [:my_custom_post_action_on_workshop, Workshop.find(1)]) +button_to("Do a POST", my_custom_post_action_on_workshop_workshop_path(Workshop.find(1))) ``` ### Spring If your application uses Spring, it needs to be upgraded to at least version 3.0.0. Otherwise you'll get ``` undefined method `mechanism=' for ActiveSupport::Dependencies:Module ``` Also, make sure `config.cache_classes` is set to `false` in `config/environments/test.rb`. ### Sprockets is now an optional dependency The gem `rails` doesn't depend on `sprockets-rails` anymore. If your application still needs to use Sprockets, make sure to add `sprockets-rails` to your Gemfile. ``` gem "sprockets-rails" ``` ### Applications need to run in `zeitwerk` mode Applications still running in `classic` mode have to switch to `zeitwerk` mode. Please check the [Classic to Zeitwerk HOWTO](https://guides.rubyonrails.org/classic_to_zeitwerk_howto.html) guide for details. ### The setter `config.autoloader=` has been deleted In Rails 7 there is no configuration point to set the autoloading mode, `config.autoloader=` has been deleted. If you had it set to `:zeitwerk` for whatever reason, just remove it. ### `ActiveSupport::Dependencies` private API has been deleted The private API of `ActiveSupport::Dependencies` has been deleted. That includes methods like `hook!`, `unhook!`, `depend_on`, `require_or_load`, `mechanism`, and many others. A few of highlights: * If you used `ActiveSupport::Dependencies.constantize` or `ActiveSupport::Dependencies.safe_constantize`, just change them to `String#constantize` or `String#safe_constantize`. ```ruby ActiveSupport::Dependencies.constantize("User") # NO LONGER POSSIBLE "User".constantize # ๐Ÿ‘ ``` * Any usage of `ActiveSupport::Dependencies.mechanism`, reader or writer, has to be replaced by accessing `config.cache_classes` accordingly. * If you want to trace the activity of the autoloader, `ActiveSupport::Dependencies.verbose=` is no longer available, just throw `Rails.autoloaders.log!` in `config/application.rb`. Auxiliary internal classes or modules are also gone, like like `ActiveSupport::Dependencies::Reference`, `ActiveSupport::Dependencies::Blamable`, and others. ### Autoloading during initialization Applications that autoloaded reloadable constants during initialization outside of `to_prepare` blocks got those constants unloaded and had this warning issued since Rails 6.0: ``` DEPRECATION WARNING: Initialization autoloaded the constant .... Being able to do this is deprecated. Autoloading during initialization is going to be an error condition in future versions of Rails. ... ``` If you still get this warning in the logs, please check the section about autoloading when the application boots in the [autoloading guide](https://guides.rubyonrails.org/v7.0/autoloading_and_reloading_constants.html#autoloading-when-the-application-boots). You'd get a `NameError` in Rails 7 otherwise. ### Ability to configure `config.autoload_once_paths` `config.autoload_once_paths` can be set in the body of the application class defined in `config/application.rb` or in the configuration for environments in `config/environments/*`. Similarly, engines can configure that collection in the class body of the engine class or in the configuration for environments. After that, the collection is frozen, and you can autoload from those paths. In particular, you can autoload from there during initialization. They are managed by the `Rails.autoloaders.once` autoloader, which does not reload, only autoloads/eager loads. If you configured this setting after the environments configuration has been processed and are getting `FrozenError`, please just move the code. ### `ActionDispatch::Request#content_type` now returned Content-Type header as it is. Previously, `ActionDispatch::Request#content_type` returned value does NOT contain charset part. This behavior changed to returned Content-Type header containing charset part as it is. If you want just MIME type, please use `ActionDispatch::Request#media_type` instead. Before: ```ruby request = ActionDispatch::Request.new("CONTENT_TYPE" => "text/csv; header=present; charset=utf-16", "REQUEST_METHOD" => "GET") request.content_type #=> "text/csv" ``` After: ```ruby request = ActionDispatch::Request.new("Content-Type" => "text/csv; header=present; charset=utf-16", "REQUEST_METHOD" => "GET") request.content_type #=> "text/csv; header=present; charset=utf-16" request.media_type #=> "text/csv" ``` ### Key generator digest class changing to use SHA256 The default digest class for the key generator is changing from SHA1 to SHA256. This has consequences in any encrypted message generated by Rails, including encrypted cookies. In order to be able to read messages using the old digest class it is necessary to register a rotator. The following is an example for rotator for the encrypted cookies. ```ruby Rails.application.config.action_dispatch.cookies_rotations.tap do |cookies| salt = Rails.application.config.action_dispatch.authenticated_encrypted_cookie_salt secret_key_base = Rails.application.secrets.secret_key_base key_generator = ActiveSupport::KeyGenerator.new( secret_key_base, iterations: 1000, hash_digest_class: OpenSSL::Digest::SHA1 ) key_len = ActiveSupport::MessageEncryptor.key_len secret = key_generator.generate_key(salt, key_len) cookies.rotate :encrypted, secret end ``` ### Digest class for ActiveSupport::Digest changing to SHA256 The default digest class for ActiveSupport::Digest is changing from SHA1 to SHA256. This has consequences for things like Etags that will change and cache keys as well. Changing these keys can have impact on cache hit rates, so be careful and watch out for this when upgrading to the new hash. ### New ActiveSupport::Cache serialization format A faster and more compact serialization format was introduced. To enable it you must set `config.active_support.cache_format_version = 7.0`: ```ruby # config/application.rb config.load_defaults 6.1 config.active_support.cache_format_version = 7.0 ``` Or simply: ```ruby # config/application.rb config.load_defaults 7.0 ``` However Rails 6.1 applications are not able to read this new serialization format, so to ensure a seamless upgrade you must first deploy your Rails 7.0 upgrade with `config.active_support.cache_format_version = 6.1`, and then only once all Rails processes have been updated you can set `config.active_support.cache_format_version = 7.0`. Rails 7.0 is able to read both formats so the cache won't be invalidated during the upgrade. ### Active Storage video preview image generation Video preview image generation now uses FFmpeg's scene change detection to generate more meaningful preview images. Previously the first frame of the video would be used and that caused problems if the video faded in from black. This change requires FFmpeg v3.4+. ### Active Storage default variant processor changed to `:vips` For new apps, image transformation will use libvips instead of ImageMagick. This will reduce the time taken to generate variants as well as CPU and memory usage, improving response times in apps that rely on Active Storage to serve their images. The `:mini_magick` option is not being deprecated, so it is fine to keep using it. To migrate an existing app to libvips, set: ```ruby Rails.application.config.active_storage.variant_processor = :vips ``` You will then need to change existing image transformation code to the `image_processing` macros, and replace ImageMagick's options with libvips' options. #### Replace resize with resize_to_limit ```diff - variant(resize: "100x") + variant(resize_to_limit: [100, nil]) ``` If you don't do this, when you switch to vips you will see this error: `no implicit conversion to float from string`. #### Use an array when cropping ```diff - variant(crop: "1920x1080+0+0") + variant(crop: [0, 0, 1920, 1080]) ``` If you don't do this when migrating to vips, you will see the following error: `unable to call crop: you supplied 2 arguments, but operation needs 5`. #### Clamp your crop values: Vips is more strict than ImageMagick when it comes to cropping: 1. It will not crop if `x` and/or `y` are negative values. e.g.: `[-10, -10, 100, 100]` 2. It will not crop if position (`x` or `y`) plus crop dimension (`width`, `height`) is larger than the image. e.g.: a 125x125 image and a crop of `[50, 50, 100, 100]` If you don't do this when migrating to vips, you will see the following error: `extract_area: bad extract area` #### Adjust the background color used for `resize_and_pad` Vips uses black as the default background color `resize_and_pad`, instead of white like ImageMagick. Fix that by using the `background` option: ```diff - variant(resize_and_pad: [300, 300]) + variant(resize_and_pad: [300, 300, background: [255]]) ``` #### Remove any EXIF based rotation Vips will auto rotate images using the EXIF value when processing variants. If you were storing rotation values from user uploaded photos to apply rotation with ImageMagick, you must stop doing that: ```diff - variant(format: :jpg, rotate: rotation_value) + variant(format: :jpg) ``` #### Replace monochrome with colourspace Vips uses a different option to make monochrome images: ```diff - variant(monochrome: true) + variant(colourspace: "b-w") ``` #### Switch to libvips options for compressing images JPEG ```diff - variant(strip: true, quality: 80, interlace: "JPEG", sampling_factor: "4:2:0", colorspace: "sRGB") + variant(saver: { strip: true, quality: 80, interlace: true }) ``` PNG ```diff - variant(strip: true, quality: 75) + variant(saver: { strip: true, compression: 9 }) ``` WEBP ```diff - variant(strip: true, quality: 75, define: { webp: { lossless: false, alpha_quality: 85, thread_level: 1 } }) + variant(saver: { strip: true, quality: 75, lossless: false, alpha_q: 85, reduction_effort: 6, smart_subsample: true }) ``` GIF ```diff - variant(layers: "Optimize") + variant(saver: { optimize_gif_frames: true, optimize_gif_transparency: true }) ``` #### Deploy to production Active Storage encodes into the url for the image the list of transformations that must be performed. If your app is caching these urls, your images will break after you deploy the new code to production. Because of this you must manually invalidate your affected cache keys. For example, if you have something like this in a view: ```erb <% @products.each do |product| %> <% cache product do %> <%= image_tag product.cover_photo.variant(resize: "200x") %> <% end %> <% end %> ``` You can invalidate the cache either by touching the product, or changing the cache key: ```erb <% @products.each do |product| %> <% cache ["v2", product] do %> <%= image_tag product.cover_photo.variant(resize_to_limit: [200, nil]) %> <% end %> <% end %> ``` Upgrading from Rails 6.0 to Rails 6.1 ------------------------------------- For more information on changes made to Rails 6.1 please see the [release notes](6_1_release_notes.html). ### `Rails.application.config_for` return value no longer supports access with String keys. Given a configuration file like this: ```yaml # config/example.yml development: options: key: value ``` ```ruby Rails.application.config_for(:example).options ``` This used to return a hash on which you could access values with String keys. That was deprecated in 6.0, and now doesn't work anymore. You can call `with_indifferent_access` on the return value of `config_for` if you still want to access values with String keys, e.g.: ```ruby Rails.application.config_for(:example).with_indifferent_access.dig('options', 'key') ``` ### Response's Content-Type when using `respond_to#any` The Content-Type header returned in the response can differ from what Rails 6.0 returned, more specifically if your application uses `respond_to { |format| format.any }`. The Content-Type will now be based on the given block rather than the request's format. Example: ```ruby def my_action respond_to do |format| format.any { render(json: { foo: 'bar' }) } end end ``` ```ruby get('my_action.csv') ``` Previous behaviour was returning a `text/csv` response's Content-Type which is inaccurate since a JSON response is being rendered. Current behaviour correctly returns a `application/json` response's Content-Type. If your application relies on the previous incorrect behaviour, you are encouraged to specify which formats your action accepts, i.e. ```ruby format.any(:xml, :json) { render request.format.to_sym => @people } ``` ### `ActiveSupport::Callbacks#halted_callback_hook` now receive a second argument Active Support allows you to override the `halted_callback_hook` whenever a callback halts the chain. This method now receives a second argument which is the name of the callback being halted. If you have classes that override this method, make sure it accepts two arguments. Note that this is a breaking change without a prior deprecation cycle (for performance reasons). Example: ```ruby class Book < ApplicationRecord before_save { throw(:abort) } before_create { throw(:abort) } def halted_callback_hook(filter, callback_name) # => This method now accepts 2 arguments instead of 1 Rails.logger.info("Book couldn't be #{callback_name}d") end end ``` ### The `helper` class method in controllers uses `String#constantize` Conceptually, before Rails 6.1 ```ruby helper "foo/bar" ``` resulted in ```ruby require_dependency "foo/bar_helper" module_name = "foo/bar_helper".camelize module_name.constantize ``` Now it does this instead: ```ruby prefix = "foo/bar".camelize "#{prefix}Helper".constantize ``` This change is backwards compatible for the majority of applications, in which case you do not need to do anything. Technically, however, controllers could configure `helpers_path` to point to a directory in `$LOAD_PATH` that was not in the autoload paths. That use case is no longer supported out of the box. If the helper module is not autoloadable, the application is responsible for loading it before calling `helper`. ### Redirection to HTTPS from HTTP will now use the 308 HTTP status code The default HTTP status code used in `ActionDispatch::SSL` when redirecting non-GET/HEAD requests from HTTP to HTTPS has been changed to `308` as defined in https://tools.ietf.org/html/rfc7538. ### Active Storage now requires Image Processing When processing variants in Active Storage, it's now required to have the [image_processing gem](https://github.com/janko/image_processing) bundled instead of directly using `mini_magick`. Image Processing is configured by default to use `mini_magick` behind the scenes, so the easiest way to upgrade is by replacing the `mini_magick` gem for the `image_processing` gem and making sure to remove the explicit usage of `combine_options` since it's no longer needed. For readability, you may wish to change raw `resize` calls to `image_processing` macros. For example, instead of: ```ruby video.preview(resize: "100x100") video.preview(resize: "100x100>") video.preview(resize: "100x100^") ``` you can respectively do: ```ruby video.preview(resize_to_fit: [100, 100]) video.preview(resize_to_limit: [100, 100]) video.preview(resize_to_fill: [100, 100]) ``` Upgrading from Rails 5.2 to Rails 6.0 ------------------------------------- For more information on changes made to Rails 6.0 please see the [release notes](6_0_release_notes.html). ### Using Webpacker [Webpacker](https://github.com/rails/webpacker) is the default JavaScript compiler for Rails 6. But if you are upgrading the app, it is not activated by default. If you want to use Webpacker, then include it in your Gemfile and install it: ```ruby gem "webpacker" ``` ```bash $ bin/rails webpacker:install ``` ### Force SSL The `force_ssl` method on controllers has been deprecated and will be removed in Rails 6.1. You are encouraged to enable `config.force_ssl` to enforce HTTPS connections throughout your application. If you need to exempt certain endpoints from redirection, you can use `config.ssl_options` to configure that behavior. ### Purpose and expiry metadata is now embedded inside signed and encrypted cookies for increased security To improve security, Rails embeds the purpose and expiry metadata inside encrypted or signed cookies value. Rails can then thwart attacks that attempt to copy the signed/encrypted value of a cookie and use it as the value of another cookie. This new embed metadata make those cookies incompatible with versions of Rails older than 6.0. If you require your cookies to be read by Rails 5.2 and older, or you are still validating your 6.0 deploy and want to be able to rollback set `Rails.application.config.action_dispatch.use_cookies_with_metadata` to `false`. ### All npm packages have been moved to the `@rails` scope If you were previously loading any of the `actioncable`, `activestorage`, or `rails-ujs` packages through npm/yarn, you must update the names of these dependencies before you can upgrade them to `6.0.0`: ``` actioncable โ†’ @rails/actioncable activestorage โ†’ @rails/activestorage rails-ujs โ†’ @rails/ujs ``` ### Action Cable JavaScript API Changes The Action Cable JavaScript package has been converted from CoffeeScript to ES2015, and we now publish the source code in the npm distribution. This release includes some breaking changes to optional parts of the Action Cable JavaScript API: - Configuration of the WebSocket adapter and logger adapter have been moved from properties of `ActionCable` to properties of `ActionCable.adapters`. If you are configuring these adapters you will need to make these changes: ```diff - ActionCable.WebSocket = MyWebSocket + ActionCable.adapters.WebSocket = MyWebSocket ``` ```diff - ActionCable.logger = myLogger + ActionCable.adapters.logger = myLogger ``` - The `ActionCable.startDebugging()` and `ActionCable.stopDebugging()` methods have been removed and replaced with the property `ActionCable.logger.enabled`. If you are using these methods you will need to make these changes: ```diff - ActionCable.startDebugging() + ActionCable.logger.enabled = true ``` ```diff - ActionCable.stopDebugging() + ActionCable.logger.enabled = false ``` ### `ActionDispatch::Response#content_type` now returns the Content-Type header without modification Previously, the return value of `ActionDispatch::Response#content_type` did NOT contain the charset part. This behavior has changed to include the previously omitted charset part as well. If you want just the MIME type, please use `ActionDispatch::Response#media_type` instead. Before: ```ruby resp = ActionDispatch::Response.new(200, "Content-Type" => "text/csv; header=present; charset=utf-16") resp.content_type #=> "text/csv; header=present" ``` After: ```ruby resp = ActionDispatch::Response.new(200, "Content-Type" => "text/csv; header=present; charset=utf-16") resp.content_type #=> "text/csv; header=present; charset=utf-16" resp.media_type #=> "text/csv" ``` ### Autoloading The default configuration for Rails 6 ```ruby # config/application.rb config.load_defaults 6.0 ``` enables `zeitwerk` autoloading mode on CRuby. In that mode, autoloading, reloading, and eager loading are managed by [Zeitwerk](https://github.com/fxn/zeitwerk). If you are using defaults from a previous Rails version, you can enable zeitwerk like so: ```ruby # config/application.rb config.autoloader = :zeitwerk ``` #### Public API In general, applications do not need to use the API of Zeitwerk directly. Rails sets things up according to the existing contract: `config.autoload_paths`, `config.cache_classes`, etc. While applications should stick to that interface, the actual Zeitwerk loader object can be accessed as ```ruby Rails.autoloaders.main ``` That may be handy if you need to preload Single Table Inheritance (STI) classes or configure a custom inflector, for example. #### Project Structure If the application being upgraded autoloads correctly, the project structure should be already mostly compatible. However, `classic` mode infers file names from missing constant names (`underscore`), whereas `zeitwerk` mode infers constant names from file names (`camelize`). These helpers are not always inverse of each other, in particular if acronyms are involved. For instance, `"FOO".underscore` is `"foo"`, but `"foo".camelize` is `"Foo"`, not `"FOO"`. Compatibility can be checked with the `zeitwerk:check` task: ```bash $ bin/rails zeitwerk:check Hold on, I am eager loading the application. All is good! ``` #### require_dependency All known use cases of `require_dependency` have been eliminated, you should grep the project and delete them. If your application uses Single Table Inheritance, please see the [Single Table Inheritance section](autoloading_and_reloading_constants.html#single-table-inheritance) of the Autoloading and Reloading Constants (Zeitwerk Mode) guide. #### Qualified names in class and module definitions You can now robustly use constant paths in class and module definitions: ```ruby # Autoloading in this class' body matches Ruby semantics now. class Admin::UsersController < ApplicationController # ... end ``` A gotcha to be aware of is that, depending on the order of execution, the classic autoloader could sometimes be able to autoload `Foo::Wadus` in ```ruby class Foo::Bar Wadus end ``` That does not match Ruby semantics because `Foo` is not in the nesting, and won't work at all in `zeitwerk` mode. If you find such corner case you can use the qualified name `Foo::Wadus`: ```ruby class Foo::Bar Foo::Wadus end ``` or add `Foo` to the nesting: ```ruby module Foo class Bar Wadus end end ``` #### Concerns You can autoload and eager load from a standard structure like ``` app/models app/models/concerns ``` In that case, `app/models/concerns` is assumed to be a root directory (because it belongs to the autoload paths), and it is ignored as namespace. So, `app/models/concerns/foo.rb` should define `Foo`, not `Concerns::Foo`. The `Concerns::` namespace worked with the classic autoloader as a side-effect of the implementation, but it was not really an intended behavior. An application using `Concerns::` needs to rename those classes and modules to be able to run in `zeitwerk` mode. #### Having `app` in the autoload paths Some projects want something like `app/api/base.rb` to define `API::Base`, and add `app` to the autoload paths to accomplish that in `classic` mode. Since Rails adds all subdirectories of `app` to the autoload paths automatically, we have another situation in which there are nested root directories, so that setup no longer works. Similar principle we explained above with `concerns`. If you want to keep that structure, you'll need to delete the subdirectory from the autoload paths in an initializer: ```ruby ActiveSupport::Dependencies.autoload_paths.delete("#{Rails.root}/app/api") ``` #### Autoloaded Constants and Explicit Namespaces If a namespace is defined in a file, as `Hotel` is here: ``` app/models/hotel.rb # Defines Hotel. app/models/hotel/pricing.rb # Defines Hotel::Pricing. ``` the `Hotel` constant has to be set using the `class` or `module` keywords. For example: ```ruby class Hotel end ``` is good. Alternatives like ```ruby Hotel = Class.new ``` or ```ruby Hotel = Struct.new ``` won't work, child objects like `Hotel::Pricing` won't be found. This restriction only applies to explicit namespaces. Classes and modules not defining a namespace can be defined using those idioms. #### One file, one constant (at the same top-level) In `classic` mode you could technically define several constants at the same top-level and have them all reloaded. For example, given ```ruby # app/models/foo.rb class Foo end class Bar end ``` while `Bar` could not be autoloaded, autoloading `Foo` would mark `Bar` as autoloaded too. This is not the case in `zeitwerk` mode, you need to move `Bar` to its own file `bar.rb`. One file, one constant. This only applies to constants at the same top-level as in the example above. Inner classes and modules are fine. For example, consider ```ruby # app/models/foo.rb class Foo class InnerClass end end ``` If the application reloads `Foo`, it will reload `Foo::InnerClass` too. #### Spring and the `test` Environment Spring reloads the application code if something changes. In the `test` environment you need to enable reloading for that to work: ```ruby # config/environments/test.rb config.cache_classes = false ``` Otherwise you'll get this error: ``` reloading is disabled because config.cache_classes is true ``` #### Bootsnap Bootsnap should be at least version 1.4.2. In addition to that, Bootsnap needs to disable the iseq cache due to a bug in the interpreter if running Ruby 2.5. Please make sure to depend on at least Bootsnap 1.4.4 in that case. #### `config.add_autoload_paths_to_load_path` The new configuration point ```ruby config.add_autoload_paths_to_load_path ``` is `true` by default for backwards compatibility, but allows you to opt-out from adding the autoload paths to `$LOAD_PATH`. This makes sense in most applications, since you never should require a file in `app/models`, for example, and Zeitwerk only uses absolute file names internally. By opting-out you optimize `$LOAD_PATH` lookups (less directories to check), and save Bootsnap work and memory consumption, since it does not need to build an index for these directories. #### Thread-safety In classic mode, constant autoloading is not thread-safe, though Rails has locks in place for example to make web requests thread-safe when autoloading is enabled, as it is common in the development environment. Constant autoloading is thread-safe in `zeitwerk` mode. For example, you can now autoload in multi-threaded scripts executed by the `runner` command. #### Globs in config.autoload_paths Beware of configurations like ```ruby config.autoload_paths += Dir["#{config.root}/lib/**/"] ``` Every element of `config.autoload_paths` should represent the top-level namespace (`Object`) and they cannot be nested in consequence (with the exception of `concerns` directories explained above). To fix this, just remove the wildcards: ```ruby config.autoload_paths << "#{config.root}/lib" ``` #### Eager loading and autoloading are consistent In `classic` mode, if `app/models/foo.rb` defines `Bar`, you won't be able to autoload that file, but eager loading will work because it loads files recursively blindly. This can be a source of errors if you test things first eager loading, execution may fail later autoloading. In `zeitwerk` mode both loading modes are consistent, they fail and err in the same files. #### How to Use the Classic Autoloader in Rails 6 Applications can load Rails 6 defaults and still use the classic autoloader by setting `config.autoloader` this way: ```ruby # config/application.rb config.load_defaults 6.0 config.autoloader = :classic ``` When using the Classic Autoloader in Rails 6 application it is recommended to set concurrency level to 1 in development environment, for the web servers and background processors, due to the thread-safety concerns. ### Active Storage assignment behavior change With the configuration defaults for Rails 5.2, assigning to a collection of attachments declared with `has_many_attached` appends new files: ```ruby class User < ApplicationRecord has_many_attached :highlights end user.highlights.attach(filename: "funky.jpg", ...) user.highlights.count # => 1 blob = ActiveStorage::Blob.create_after_upload!(filename: "town.jpg", ...) user.update!(highlights: [ blob ]) user.highlights.count # => 2 user.highlights.first.filename # => "funky.jpg" user.highlights.second.filename # => "town.jpg" ``` With the configuration defaults for Rails 6.0, assigning to a collection of attachments replaces existing files instead of appending to them. This matches Active Record behavior when assigning to a collection association: ```ruby user.highlights.attach(filename: "funky.jpg", ...) user.highlights.count # => 1 blob = ActiveStorage::Blob.create_after_upload!(filename: "town.jpg", ...) user.update!(highlights: [ blob ]) user.highlights.count # => 1 user.highlights.first.filename # => "town.jpg" ``` `#attach` can be used to add new attachments without removing the existing ones: ```ruby blob = ActiveStorage::Blob.create_after_upload!(filename: "town.jpg", ...) user.highlights.attach(blob) user.highlights.count # => 2 user.highlights.first.filename # => "funky.jpg" user.highlights.second.filename # => "town.jpg" ``` Existing applications can opt in to this new behavior by setting `config.active_storage.replace_on_assign_to_many` to `true`. The old behavior will be deprecated in Rails 7.0 and removed in Rails 7.1. Upgrading from Rails 5.1 to Rails 5.2 ------------------------------------- For more information on changes made to Rails 5.2 please see the [release notes](5_2_release_notes.html). ### Bootsnap Rails 5.2 adds bootsnap gem in the [newly generated app's Gemfile](https://github.com/rails/rails/pull/29313). The `app:update` command sets it up in `boot.rb`. If you want to use it, then add it in the Gemfile: ```ruby # Reduces boot times through caching; required in config/boot.rb gem 'bootsnap', require: false ``` 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 embedded information makes 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](5_1_release_notes.html). ### 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: ```ruby Rails.application.secrets[:smtp_settings]["address"] ``` To: ```ruby Rails.application.secrets[:smtp_settings][:address] ``` ### Removed deprecated support to `:text` and `:nothing` in `render` If your controllers are using `render :text`, they will no longer work. The new method of rendering text with MIME type of `text/plain` is to use `render :plain`. Similarly, `render :nothing` is also removed and you should use the `head` method to send responses that contain only headers. For example, `head :ok` sends a 200 response with no body to render. ### Removed deprecated support of `redirect_to :back` In Rails 5.0, `redirect_to :back` was deprecated. In Rails 5.1, it was removed completely. As an alternative, use `redirect_back`. It's important to note that `redirect_back` also takes a `fallback_location` option which will be used in case the `HTTP_REFERER` is missing. ``` redirect_back(fallback_location: root_path) ``` Upgrading from Rails 4.2 to Rails 5.0 ------------------------------------- For more information on changes made to Rails 5.0 please see the [release notes](5_0_release_notes.html). ### 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: ```ruby 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`: ```ruby 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](https://github.com/rails/rails/pull/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: ```ruby class ApplicationJob < ActiveJob::Base end ``` Then make sure that all your job classes inherit from it. See [#19034](https://github.com/rails/rails/pull/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](https://github.com/rails/rails/issues/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, 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 `bin/rails dev:cache`. Run `bin/rails` inside your application's root directory 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. ```ruby 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: ```erb <% # 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. ```erb <% # 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`: ```ruby gem 'record_tag_helper', '~> 1.0' ``` See [#18411](https://github.com/rails/rails/pull/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`. ```ruby # 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: ```ruby # 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 an existing application wants to add this feature it will need to be turned on in an initializer: ```ruby config.active_record.belongs_to_required_by_default = true ``` The configuration is by default global for all your models, but you can override it on a per model basis. This should help you migrate all your models to have their associations required by default. ```ruby class Book < ApplicationRecord # model is not yet ready to have its association required by default self.belongs_to_required_by_default = false belongs_to(:author) end class Car < ApplicationRecord # model is ready to have its association required by default self.belongs_to_required_by_default = true belongs_to(:pilot) end ``` #### 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 specific to the action and method for that form. ```ruby 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: ```ruby 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: ```ruby 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. ```ruby 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. ```ruby 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: ```ruby 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`. ```ruby 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: ```ruby # 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: ```ruby # 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](https://github.com/rails/rails/pull/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`: ```ruby config.active_record.raise_in_transactional_callbacks = true ``` See [#14488](https://github.com/rails/rails/pull/14488) and [#16537](https://github.com/rails/rails/pull/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: ```ruby # 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`: ```ruby # 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: ```ruby # 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. ```ruby # 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`](https://github.com/rails/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](https://github.com/flavorjones/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](https://github.com/flavorjones/loofah#loofahscrubber). Two new scrubbers have also been added: `PermitScrubber` and `TargetScrubber`. Read the [gem's readme](https://github.com/rails/rails-html-sanitizer) 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`: ```ruby gem 'rails-deprecated_sanitizer' ``` ### Rails DOM Testing The [`TagAssertions` module](https://api.rubyonrails.org/v4.1/classes/ActionDispatch/Assertions/TagAssertions.html) (containing methods such as `assert_tag`), [has been deprecated](https://github.com/rails/rails/blob/6061472b8c310158a2a2e8e9a6b81a1aef6b60fe/actionpack/lib/action_dispatch/testing/assertions/dom.rb) in favor of the `assert_select` methods from the `SelectorAssertions` module, which has been extracted into the [rails-dom-testing gem](https://github.com/rails/rails-dom-testing). ### 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: ```ruby class Notifier < ActionMailer::Base def notify(user, ...) puts "Called" mail(to: user.email, ...) end end ``` ```ruby 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: ```ruby 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 `