Collections can take advantage of `multi_read` if they render one template
and their partials begin with a cache call.
The cache call must correspond to either what the collections elements are
rendered as, or match the inferred name of the partial.
So with a notifications/_notification.html.erb template like:
```ruby
<% cache notification %>
<%# ... %>
<% end %>
```
A collection would be able to use `multi_read` if rendered like:
```ruby
<%= render @notifications %>
<%= render partial: 'notifications/notification', collection: @notifications, as: :notification %>
```
The methods `fresh_when` and `stale?` from ActionController::ConditionalGet
accept a single record as a short form for a hash. For instance
```ruby
def show
@article = Article.find(params[:id])
fresh_when(@article)
end
```
is just a short form for:
```ruby
def show
@article = Article.find(params[:id])
fresh_when(etag: @article, last_modified: @article.created_at)
end
```
This commit extends `fresh_when` and `stale?` to also accept a collection
of records, so that a short form similar to the one above can be used in
an `index` action. After this commit, the following code:
```ruby
def index
@article = Article.all
fresh_when(etag: @articles, last_modified: @articles.maximum(:created_at))
end
```
can be simply written as:
```ruby
def index
@article = Article.all
fresh_when(@articles)
end
```
PR #18772 changed the parameters of `stale?` to use `kwargs`.
[As for this comment](https://github.com/rails/rails/pull/18872/files#r24456288)
the default value for the `etag` parameter should be `record`, not `nil`.
This commit fixes the code and introduces a test that:
- passed before #18872
- fails on the current master (after #18772)
- passes again after setting the default value of `etag` to `record`.
In match_head_routes, deleted the routes in which request.request_method was empty (matches all HTTP verbs) when responding to a HEAD request. This prevents catch-all routes (such as Racks) from intercepting the HEAD request.
Fixes#18698
This is an issue brought up by @daniel-rikowski in rails/web-console#91.
Citing his PR proposal here:
> Prior to this, backtrace lines were simply split by a single colon.
>
> Unfortunately that is also the drive letter delimiter in Windows paths
> which resulted in a lot of empty source fragments of "C:0". ("C" from
> the drive letter and 0 from "/path/to/rails/file.rb:16".to_i)
>
> Now the trace line is split by the first colon followed by some digits,
> which works for both Windows and Unix path styles.
Now, the PR was sent against web-console, because of the templates copy
issue we used to had. Instead of bothering the contributor to reopen the
issue against upstream Rails itself, I will make sure he gets the credit
by putting his name in [rails-contributors/hard_coded_authors.rb][].
[rails-contributors/hard_coded_authors.rb]: (https://github.com/fxn/rails-contributors/blob/master/app/models/names_manager/hard_coded_authors.rb).
Non-kwargs requests are deprecated now.
Guides are updated as well.
`post url, nil, nil, { a: 'b' }` doesn't make sense.
`post url, params: { y: x }, session: { a: 'b' }` would be an explicit way to do the same
Inside a controller functional test after the last flash is deleted it
still persists the flash because to_session_value is nil. We should
delete it from the session when the serialized version is nil, same as
the flash middleware.
Fixes an issue that would cause default_url_options to be lost when generating
URLs with fewer positional arguments than parameters in the route definition.
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).
