When `render` was moved from ActionPack to ActionView in acc8e259,
some fixtures required by the tests were duplicated, but they are
actually only required by ActionView tests.
To give one example, `double_render` is already defined [in the AV tests](72139d8d31/actionview/test/actionpack/controller/render_test.rb (L407))
and is never used in the ActionPack tests.
The new test/docs further explain the conflicts that can happen when
mixing `:if`/`:unless` options with `:only`/`:except` options in
`skip_before_action`.
The gist is that "positive" filters always have priority over negative
ones.
The previous commit already showed that `:only` has priority over `:if`.
This commit shows that `:if` has priority over `:except`.
For instance, the following snippets are equivalent:
```ruby
skip_before_action :some_callback, if: -> { condition }, except: action
```
```ruby
skip_before_action :some_callback, if: -> { condition }
```
Test case for using skip_before_filter with the options :only and :if
both present. In this case, the :if option will be ignored and :only
will be executed.
Closes#14549 (the commit was cherry-picked from there).
Commit 20fece1 introduced the `_status_code` method to fix calls to
`head :ok`. This method has been added on both ActionController::Metal
and ActionDispatch::Response.
As for the latter, this method is just equivalent to the `response_code`
one so commit aefec3c removed it from the `Reponse` object so call to
the `_status_code` method on an ActionController::Base instance would be
handled by the `Metal` class (which `Base` inherits from) but the status
code is not updated according to the response at this level.
The fix is to actually rely on `response_code` for ActionController::Base
instances but this method doesn't exist for bare Metal controllers so we
need to define it.
The current implementation of `variants=` don't allow a resetting to nil, wich is the default value.
This results in the following code smell:
```ruby
case request.user_agent
when /iPhone/
request.variants = :phone
when /iPad/
request.variants = :ipad
end
```
With the ability to reset variants to nil, it could be:
```ruby
request.variants = case request.user_agent
when /iPhone/
:phone
when /iPad/
:ipad
end
```
When an `around_action` does not `yield`, then the corresponding action is
*never* executed and the `after_` actions are *never* invoked.
The value returned by the `around_action` does not have any impact on this:
an `around_action` can "return" `true`, `false`, or `"pizza"`, but as long
as `yield` is not invoked, the corresponding action and after callbacks are
not executed.
The test suite for `ActionController::Callbacks` currently includes separate
tests to distinguish the cases in which a non-yielding `around_actions` returns
`true` or `false`.
In my opinion, having such tests is misleading, giving the impression that the
returned value might have some sort of impact, while it does not. At least
that's the impression I got when I read those tests.
For completeness, the tests were introduced 7 years ago by @NZKoz in e80fabb.
There is no need to subtract one from the path_params size when there is
no format parameter because it is not present in the path_params array.
Fixes#17819.
As suggested in #16299([1]), this method should be a new public API for
retrieving unfiltered parameters from `ActionController::Parameters`
object, given that `Parameters#to_hash` will no longer work in Rails
5.0+ as we stop inheriting `Parameters` from `Hash`.
[1]: https://github.com/rails/rails/pull/16299#issuecomment-50220919
This fixes a regression in 4.2.0 from 4.1.8.
https://github.com/rails/rails/pull/17823 fixed a similar regression regarding _explicitly_ named routes for a mounted Rack app, but there was another regression for the default value.
With a route like:
Rails.application.routes.draw do
mount Mountable::Web, at: 'some_route'
end
The "Prefix" column of rake routes gives the following:
- 4.1.8: mountable_web
- 4.2.0.beta1-4: [nothing]
- 4.2.0.rc1: [nothing]
- 4.2.0.rc2: some_route <- regression
This fixes the default to go back to being based off the name of the class like the docs specify: 785d04e310/actionpack/lib/action_dispatch/routing/mapper.rb (L558-L560)
Explicitly named routes still work correctly per https://github.com/rails/rails/pull/17823:
Rails.application.routes.draw do
mount Mountable::Web, at: 'some_route', as: 'named'
end
- 4.1.8: named
- 4.2.0.beta1-4: [nothing]
- 4.2.0.rc1: [nothing]
- 4.2.0.rc2: named
Some `require 'openssl'` statements were surrounded by `rescue` blocks to deal with Ruby versions that did not support `OpenSSL::Digest::SHA1` or `OpenSSL::PKCS5`.
[As @jeremy explains](a6a0904fcb (commitcomment-8826666)) in the original commit:
> If jruby didn't have jruby-openssl gem, the require wouldn't work. Not sure whether either of these are still relevant today.
According to the [release notes for JRuby 1.7.13](http://www.jruby.org/2014/06/24/jruby-1-7-13.html):
> jruby-openssl 0.9.5 bundled
which means the above `rescue` block is not needed anymore.
All the Ruby versions supported by the current version of Rails provide those OpenSSL libraries, so Travis CI should also be happy by removing the `rescue` blocks.
---
Just to confirm, with JRuby:
$ ruby --version #=> jruby 1.7.16.1 (1.9.3p392) 2014-10-28 4e93f31 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_20-b26 +jit [darwin-x86_64]
$ irb
irb(main):001:0> require 'openssl' #=> true
irb(main):002:0> OpenSSL::Digest::SHA1 #=> OpenSSL::Digest::SHA1
irb(main):003:0> OpenSSL::PKCS5 # => OpenSSL::PKCS5
And with Ruby 2.1:
$ ruby --version #=> ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-darwin13.0]
$ irb
irb(main):001:0> require 'openssl' #=> true
irb(main):002:0> OpenSSL::Digest::SHA1 #=> OpenSSL::Digest::SHA1
irb(main):003:0> OpenSSL::PKCS5 #=> OpenSSL::PKCS5
claudiob