rap1ds/rails_41_upgrade_notes.org

## rails_41_upgrade_notes.org

      
    Raw
  

              rails_41_upgrade_notes.org
            
          
    Upgrading from Rails 4.0 to Rails 4.1

CSRF protection from remote <script> tags [1/1]

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.

  [X] We dont’t have them

Spring [0/1]

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

  Add gem 'spring', group: :development to your Gemfile.
  Install spring using bundle install.
  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
  Spring README.

  [ ] Spring is interesting, but let’s have a look at it later

config/secrets.yml [1/1]

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

  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"] %>
    
  
  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”] %>’.
  Remove the secret_token.rb initializer.
  Use rake secret to generate new keys for the development and
    test sections.
  Restart your server.


  [X] Added secrets.yml

Changes to test helper [1/1]

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.

  [X] rails/test_helper is now required in spec/spec_helper.rb

Cookies serializer [2/2]

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.

  [X] Added an environment variable which let’s change the cookie serializer to :hybrid or :json
  [X] Added UPGRADE notes

Flash structure changes [1/1]

Flash message keys are
  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.

  [X] I’m pretty sure we don’t access the Flash like this

Changes in JSON handling [0/0]

There are a few major changes related to JSON handling in Rails 4.1.
MultiJSON removal [1/1]

MultiJSON has reached its
  end-of-life and has been
  removed from Rails.
If your application currently depend on MultiJSON directly, you have a
  few options:

  Add ‘multi\_json’ to your Gemfile. Note that this might cease to work
    in the future
  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
  unsafe.

  [X] Removed MultiJSON from gem file

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 [2/2]

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:

  Circular data structure detection
  Support for the encode_json hook
  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
  =activesupport-json_encoder=
  gem to your Gemfile.

  [X] Updated DelayedJob gem
  [X] Make sure this can be rolled back: Can be, after DJ update

JSON representation of Time objects [1/1]

#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


  [X] Change test (plan_webhook_spec.rb:117) that break because wrong precision

Usage of return within inline callback blocks [1/1]

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 this pull request for
  more details.

  [X] Removed return statements from inline callbacks. Found 2.

Methods defined in Active Record fixtures [1/1]

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

  [X] We don’t use fixtures

I18n enforcing available locales [1/1]

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.

  [X] This was `true` already. Removed the value, no need to duplicate default.

Mutator methods called on Relation [1/1]

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!

  [X] I’m pretty confident we are not using mutators like this

Changes on Default Scopes [1/1]

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'

  [X] We had only one default_scope definition and it didn’t have this problem

Rendering content from string [1/1]

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.

  render :plain will set the content type to text/plain
  render :html will set the content type to text/html
  render :body will not set the content type header.

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.

  [X] Changed two render :text statements to render :plain

PostgreSQL json and hstore datatypes [1/1]

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.

  [X] We are not using PostgreSQL

Explicit block use for ActiveSupport::Callbacks [1/1]

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 }

  [X] I didn’t find any usage of set_callback