The `test/fixtures/happy_path/render_action/hello_world.erb` file was
introduced in 8ab37c7 for the `TestRenderAction` test.
That test was subsequently removed in 34f058e, so the fixture is not
used anymore.
If Travis CI is happy, then you can be sure the fixture can be removed.
The fixtures were added to support StaticTests in 401cd97 but
those tests were then removed in d5ad92ce.
If Travis CI is happy with this PR, then you can be sure that
those fixtures are not needed anymore.
c67005f221f102fe2caca231027d9b11cf630484 made the local var in partials
available only if what passed to `:object` was truthy.
For example this would not make the local variable `foo` available inside the
partial:
render partial: 'foo', object: false
Fixes#17373.
This commit moves a test from `test/template` to `test/activerecord` since the
test depends on ActiveRecord.
This matches the documentation from [RUNNING_UNIT_TESTS](f28d1ddd50/actionview/RUNNING_UNIT_TESTS.rdoc):
> Test cases in the test/activerecord/ directory depend on having activerecord and sqlite3 installed.
> If Active Record is not in actionview/../activerecord directory, or the sqlite3 rubygem is not installed, these tests are skipped.
> Other tests are runnable from a fresh copy of actionview without any configuration.
---
More details about this commit.
All the tests starting with `require 'active_record_unit'` are already
inside `test/activerecord`, except for the one test this commit moves.
If you don't have `active_record` on your machine, the following command
currently fails on master:
```bash
```
I grepped the source code for code snippets wrapped in backticks in the comments
and replaced the backticks with plus signs so they are correctly displayed in
the Rails documentation.
[ci skip]
Since 06388b0 `form_tag` accepts the option `enforce_utf8` which, when set to
false, prevents the hidden "UTF8 enforcer" field from appearing in the output.
This commit implements the same behavior for `form_for`.
Stems from https://github.com/rails/rails/pull/17685#issuecomment-63871395
The [current documentation of form_for](http://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-form_for) is incomplete:
> The rightmost argument to form_for is an optional hash of options -
> :url - The URL the form is to be submitted to. This may be represented in the same way as values passed to url_for or link_to. So for example you may use a named route directly. When the model is represented by a string or symbol, as in the example above, if the :url option is not specified, by default the form will be sent back to the current url (We will describe below an alternative resource-oriented usage of form_for in which the URL does not need to be specified explicitly).
> :namespace - A namespace for your form to ensure uniqueness of id attributes on form elements. The namespace attribute will be prefixed with underscore on the generated HTML id.
> :html - Optional HTML attributes for the form tag.
This commit completes the documentation by specifying that:
* `:authenticity_token` is also a valid option (as [documented here](b0f44c9ff0/actionview/lib/action_view/helpers/form_helper.rb (L396)))
* `:method` is also a valid option (as [tested here](b0f44c9ff0/actionview/test/template/form_helper_test.rb (L1819)))
* `:remote` is also a valid option (as [tested here](b0f44c9ff0/actionview/test/template/form_helper_test.rb (L1850)))
[ci skip]
This reverts commit f93df52845766216f0fe36a4586f8abad505cac4, reversing
changes made to a455e3f4e9dbfb9630d47878e1239bc424fb7d13.
Conflicts:
actionpack/lib/action_controller/test_case.rb
actionview/lib/action_view/test_case.rb
This patch uniformizes warning messages. I used the most common style
already present in the code base:
* Capitalize the first word.
* End the message with a full stop.
* "Rails 5" instead of "Rails 5.0".
* Backticks for method names and inline code.
Also, converted a few long strings into the new heredoc convention.
The current style for warning messages without newlines uses
concatenation of string literals with manual trailing spaces
where needed.
Heredocs have better readability, and with `squish` we can still
produce a single line.
This is a similar use case to the one that motivated defining
`strip_heredoc`, heredocs are super clean.
Update select_tag to reflect documentation and behave the same as form builder select. If the value of include_blank is not boolean true, use that value as the option label.
This commit fixes the behavior of `file_field_tag` and `password_field_tag`
when invoked with a hash of options.
These two helpers are different from all the other ones in that they modify the
options hash passed as a parameter, whereas all the other helpers duplicate it
before updating it.
The result is that *bad things* can happen if the user re-uses the same hash.
For instance, users who write the following code to display a file field
followed by a text field (both with the same class):
```rhtml
<% options = {class: 'important'} %>
<%= file_field_tag 'Upload', options %>
<%= text_field_tag 'Name', options %>
```
would instead see **two file fields!**
```html
<input class="important" id="Upload" name="Upload" type="file">
<input class="important" id="Name" name="Name" type="file" value="value">
```
This PR replaces `update` with `merge` in the code of the two helpers,
fixing the issue above.
The included test verifies the change, since it passes after this PR, but
fails before with the following error:
```
Expected: <input type="text" name="title" id="title" value="Hello!" class="important" />
Actual: <input type="password" name="title" id="title" value="Hello!" class="important" />
```
All the methods that invoke `text_field_tag` (such as `hidden_field_tag`)
and all the methods that invoke `number_field_tag` (that is `range_field_tag`)
do not need to call `stringify_keys` on their `options` parameter since the
`text_field_tag` method [is already doing it internally](4159134524/actionview/lib/action_view/helpers/form_tag_helper.rb (L182)):
```ruby
def text_field_tag(name, value = nil, options = {})
tag :input, { "type" => "text", "name" => name, "id" => sanitize_to_id(name), "value" => value }.update(options.stringify_keys)
end
```
and `number_field_tag` is [already doing it internally](e3207bdbba/actionview/lib/action_view/helpers/form_tag_helper.rb (L780)) as well:
```ruby
def number_field_tag(name, value = nil, options = {})
options = options.stringify_keys
...
end
[Note #1: My code uses `merge` to respect the existing behavior of
duplicating the `options` hash before updating its keys, see https://github.com/rails/rails/pull/17096#issuecomment-57223827]
[Note #2: My code uses symbols instead of strings (e.g.: `:hidden`) to look
forward to future version of Ruby/Raiks (GC symbols); the result of the method,
however, is the same, because the symbols are stringified inside `text_field_tag`]
[Note #3: I had previously created a similar PR #17096 but decided to
split it into multiple PRs given the feedback received in the comments]
HTML doesn't care what order the elements are rendered in, so why should we?
Updates tests to use proper `assert_dom_equal` instead of `assert_equal` /cc @jeremy
when mail_to generate blank options for any passed options(cc, bcc, body, subject)
then MICROSOFT OUTLOOK treats it differently and set wrong values in different options.
Since we want this flag to be enabled anytime we are running the tests
under JRuby, let's enable this at the Rakefile level so people get the
performance boost on their local checkout.
Moreover, we avoid having to update this particular line anytime the
option changes on the JRuby side.
The only drawback is that we have to define it in every Rakefile but
there's no big deal, this is already the case for other options.
abstract_unit.rb requires `action_controller` which [already includes the following lines of code](64fcdce1d3/actionpack/lib/action_controller.rb (L2L3)):
```ruby
require 'abstract_controller'
require 'action_dispatch'
```
[ci skip]
89ff1f8 and 1de258e6 removed from the HTML generated by the form helpers
the <div> that was wrapping the field elements inside the <form>.
This commit updates the documentation of the methods to reflect the
two commits above.
This is much less common than string literal appends, so add a special
case method for it. Maybe fixes bug reported by @jeremy on 97ef636191933f1d4abc92fc10871e6d1195285c
ERB compiler guarantees safe_append= will be called with a string, so
nil checks don't make sense. Anything else calling this method should
check for nil themselves before calling
This reverts commit 21ec7fefea5a1b823cb88733b019b3d52240801d.
Per #16911, there's actually a good reason for a "blank" value to have a
useful `to_s` here. So let's also add some tests to prove that.
Goals:
1. Default to :random for newly generated applications
2. Default to :sorted for existing applications with a warning
3. Only show the warning once
4. Only show the warning if the app actually uses AS::TestCase
Fixes#16769
We're seeing too many failures to believe otherwise.
This reverts commits bc116a55ca3dd9f63a1f1ca7ade3623885adcc57,
cbde413df3839e06dd14e3c220e9800af91e83ab,
bf0a67931dd8e58f6f878b9510ae818ae1f29a3a, and
2440933fe2c27b27bcafcd9019717800db2641aa.
Suppose you have two resources routed in the following manner:
```ruby
resources :blogs do
resources :posts
end
resources :posts
```
When using polymorphic resource routing like `url_for([@blog, @post])`, and `@blog` is `nil` Rails should still try to match the route to the top-level posts resource.
Fixes#16754
When we are loading a component and we want to know its version, we are
actually not speaking about the constant but the library itself.
[ci skip]
[Godfrey Chan & Xavier Noria]
the ERB has already been compiled to Ruby code by the time we're calling
module_eval. Nothing that module eval raises will be caught by a blank
`rescue`, so I think we can remove this
- Default to Rails::DeprecatedSanitizer in ActionView::Helpers::SanitizeHelper.
- Add upgrade notes.
- Add sanitizer to new applications Gemfiles.
- Remove 'rails-dom-testing' as a dependency.
Benchmarking the existing code:
```ruby
{ :only_path => options[:host].nil? }.merge!(options.symbolize_keys))
```
Against optimized code, that does not require a new hash or a merge:
```ruby
options = options.symbolize_keys
options[:only_path] = options[:host].nil? unless options.key?(:only_path)
options
```
We see a statistically significant performance gain:
![](https://www.dropbox.com/s/onocpc0zfw4kjxl/Screenshot%202014-08-14%2012.45.30.png?dl=1)
Updated to not mutate incoming parameters
Calling ActiveSupport::TestCase.i_suck_and_my_tests_are_order_dependent! in AS::TestCase makes
everyone's tests order dependent, which should never be done by the framework.
The message passed to Minitest's assert_raise is used as output in case
the assertion fails, but we can test against the exact message by using
the actual exception object that is returned from the assert_raise call.
Email does not support relative links since there is no implicit host. Therefore all links inside of emails must be fully qualified URLs. All path helpers are now deprecated. When removed, the error will give early indication to developers to use `*_url` methods instead.
Currently if a developer uses a `*_path` helper, their tests and `mail_view` will not catch the mistake. The only way to see the error is by sending emails in production. Preventing sending out emails with non-working path's is the desired end goal of this PR.
Currently path helpers are mixed-in to controllers (the ActionMailer::Base acts as a controller). All `*_url` and `*_path` helpers are made available through the same module. This PR separates this behavior into two modules so we can extend the `*_path` methods to add a Deprecation to them. Once deprecated we can use this same area to raise a NoMethodError and add an informative message directing the developer to use `*_url` instead.
The module with warnings is only mixed in when a controller returns false from the newly added `supports_relative_path?`.
Paired @sgrif & @schneems
We are planning to remove mocha from our test suite because of
performance problems. To make this possible we should stop require mocha
on ActionSupport::TestCase.
This should not affect applications since users still need to add mocha
to Gemfile and this already load mocha.
Added FIXME notes to place that still need mocha removal
[Jonas Baumann & Yves Senn]
The submitted params from a select with `multiple: true` look as follows:
```
{post: {category: [""]}}
{post: {category: ["", "Category 1", "Category 2"]}}
```
This is a follow up to #1552.