Fixes an example in `button_to`'s documentation; the description states
`button_to` only takes a symbol for the `method` argument, but an
example just below uses a string.
Passing an all-lowercase string incidentally works, so the example is
technically functional despite being undefined behavior. But passing an
all-uppercase string fails, and this is a pretty common practice when
specifying HTTP methods (e.g. `DELETE`), so I think it's best this
example is put in line with the documentation and converted to use
symbols.
I fell for it myself and tried to pass an all-uppercase string after
seeing the example without reading the options descriptions.
Reproduction steps:
```sh
rails new buttonto
cd buttonto
rails c
> def protect_against_forgery?
> false
> end
=> :protect_against_forgery?
> button_to('Destroy', 'http://www.example.com', method: "delete", remote: true, data: { confirm: 'Are you sure?', disable_with: 'loading...' })
=> "<form class=\"button_to\" method=\"post\" action=\"http://www.example.com\" data-remote=\"true\"><input type=\"hidden\" name=\"_method\" value=\"delete\" /><input data-confirm=\"Are you sure?\" data-disable-with=\"loading...\" type=\"submit\" value=\"Destroy\" /></form>"
> button_to('Destroy', 'http://www.example.com', method: "DELETE", remote: true, data: { confirm: 'Are you sure?', disable_with: 'loading...' })
=> "<form class=\"button_to\" method=\"post\" action=\"http://www.example.com\" data-remote=\"true\"><input data-confirm=\"Are you sure?\" data-disable-with=\"loading...\" type=\"submit\" value=\"Destroy\" /></form>"
```
`OptimizedFileSystemResolver` builds a regular expression to match view
template paths. Prior to this patch, only file globbing special
characters were escaped when building this regular expression, leaving
other regular expression special characters unescaped.
This patch properly escapes all regular expression special characters,
and adds test coverage for paths that include these characters.
Fixes#37107.
The docs for ActionView partial renderer state:
> NOTE: Due to backwards compatibility concerns, the collection can't be one of hashes. Normally you'd also just keep domain objects, like Active Records, in there.
The reporter stated:
> I can render a collection of hashes without problems:
>
> = render :partial => "info_row", :collection => my_collection, :as => :d
I tested this in a Rails 6.0 rc2 app and hashes were passed as described. Fixes#36897. [ci skip]
Commit 52f0b050e2 replaces `white_list_sanitizer` with `safe_list_sanitizer`. This is a breaking change unless the installed version of `rails-html-sanitizer` is `>= 1.1.0`.
This commit updates the minimum version in `actionview/actionview.gemspec` to `1.1.0`.
This hack prevails everywhere in the codebase by being copy & pasted, and it's actually not a negative thing but a necessary thing for framework implementors,
so it should better have a name and be a thing.
And with this commit, activesupport/test/abstract_unit.rb now doesn't silently autoload AS::TestCase,
so we're ready to establish clearner environment for running AS tests (probably in later commits)
* Added a phone_to helper method, on the style of mail_to and sms_to.
It creates an anchor tag with the href set to tel: *here your number*
which, when clicked on a mobile phone, or on a desktop with a supported
application, lets the phone app kick in, and it prepopulates it with the
phone number specified.
[Pietro Moro + Rafael Mendonça França]
The source_extract method will return nil when it can't find the file name in
the backtrace, methods that consume this method expect an array and the nil ends
up causing type errors down the road like it happened here: #36341. This
patch refactors the source_extract method so that it returns an empty
array instead of nil when it can't find the source code.
Co-authored-by: Kasper Timm Hansen <kaspth@gmail.com>
When a SyntaxError is detected in a template we raise this exception. On
a first request to the server the exception we get a NameError since the
exception is not required from `active_view/template/error.rb` yet.
However later on it gets required and a second request will succeed.
On the first request we see the rails "Something Wen Wrong" page and not
the expected syntax error in template error page with the webconsole and
stacktrace. By autoloading the constant we fix this issue.
Co-authored-by: Gannon McGibbon <gannon.mcgibbon@gmail.com>
It is sometimes expected of the `translate` methods to return a Hash,
for instance it's the case of the `number.format` key.
As such users might need to specify a Hash default, e.g.
`translate(:'some.format', default: { separator: '.', delimiter: ',' })`.
This works as expected with the `I18n.translate` methods,
however `TranslationHelper#translate` apply `Array()` on the default value.
As a result the default value end up as `[:separator, '.', :delimiter, ',']`.
This is really a nit pick, but as this is the framework's documentation
I think it should follow standards as many times as possible to avoid
confusion in new users.
If we were using `resources :articles` in routes. which is what scaffold
adds, the generated helper would be `new_article_path` instead of
`new_articles_path`.
We shouldn't modify fixtures (or any files which are checked-in). It
prevents us from parallelizing, and probably has other issues.
We could fix these tests by copying the file to a tmpdir and modifying
it there, but I don't think they are testing anything useful anymore.
Re-initializing a resolver isn't representative of "uncached" rendering
(either in dev-mode or using lookup_context.disable_cache).
Currently, `clear_cache_if_necessary` is executed even if view paths are
not set like `rails console`.
If the watcher class is `EventedFileUpdateChecker` and the watch
directories are empty, the application root directory will watch. This
is because listen uses the current directory as the default watch directory.
8d85b4cd57/lib/listen/adapter/config.rb (L13)
As a result, `node_modules` also watch. This cause a warning of `listen`.
Ref: https://github.com/rails/rails/pull/36377#issuecomment-498399576
Since #35709, `Response#conten_type` returns only MIME type correctly.
It is a documented behavior that this method only returns MIME type, so
this change seems appropriate.
39de7fac05/actionpack/lib/action_dispatch/http/response.rb (L245-L249)
But unfortunately, some users expect this method to return all
Content-Type that does not contain charset. This seems to be breaking
changes.
We can change this behavior with the deprecate cycle.
But, in that case, a method needs that include Content-Type with
additional parameters. And that method name is probably the
`content_type` seems to properly.
So I changed the new behavior to more appropriate `media_type` method.
And `Response#content_type` changed (as the method name) to return Content-Type
header as it is.
Fixes#35709.
[Rafael Mendonça França & Yuuji Yaginuma ]
The `number_to_human_size` helpers in Action View and Active Support
calculate the "human size" with a base of 1024. The examples should
reflect that so they don't confuse the reader.
The updated documentations use the values from:
helper.number_to_human_size(1500)
The templates rendered in RenderTestCases tests will be cached by the
resolvers unexpectedly. And this will break other tests when executed in
certain order. (See https://github.com/rails/rails/issues/36154 for more
detail)
So to fix this issue, we just need to clear the caches on all resolvers.
Performance cops will be extracted from RuboCop to RuboCop Performance
when next RuboCop 0.68 will be released.
https://github.com/rubocop-hq/rubocop/issues/5977
RuboCop 0.67 is its transition period.
Since rails/rails repository uses Performance cops, This PR added
rubocop-performance gem to Gemfile.
And this PR fixes some offenses using the following auto-correct.
```console
% bundle exec rubocop -a
Offenses:
activerecord/test/cases/connection_adapters/connection_handlers_multi_db_test.rb:212:26:
C: [Corrected] Layout/SpaceAroundOperators: Operator =
> should be surrounded by a single space.
"primary" => { adapter: "sqlite3", database: "db/primary.sqlite3" }
^^
activerecord/test/cases/connection_adapters/connection_handlers_multi_db_test.rb:239:26:
C: [Corrected] Layout/SpaceAroundOperators: Operator => should be
surrounded by a single space.
"primary" => { adapter: "sqlite3", database: "db/primary.sqlite3" }
^^
actionview/test/template/resolver_shared_tests.rb:1:1: C: [Corrected]
Style/FrozenStringLiteralComment: Missing magic comment #
frozen_string_literal: true.
module ResolverSharedTests
^
actionview/test/template/resolver_shared_tests.rb:10:33: C: [Corrected]
Layout/SpaceAroundEqualsInParameterDefault: Surrounding space missing in
default value assignment.
def with_file(filename, source="File at #{filename}")
^
actionview/test/template/resolver_shared_tests.rb:106:5: C: [Corrected]
Rails/RefuteMethods: Prefer assert_not_same over refute_same.
refute_same a, b
^^^^^^^^^^^
2760 files inspected, 5 offenses detected, 5 offenses corrected
```
This adds a bit of complexity, but is necessary for now to avoid holding
extra copies of templates which are resolved from ActionView::Digestor
after disabling cache on the lookup context.
Previously it's possible to have multiple copies of the "same" Template.
For example, if index.html.erb is found both the :en and :fr locale, it
will return a different Template object for each. The same can happen
with formats, variants, and handlers.
This commit de-duplicates templates, there will now only be one template
per file/virtual_path/locals tuple.
We need to consider virtual_path because both `render "index"`, and
`render "index.html"` can both find the same file but will have
different virtual_paths. IMO this is rare and should be
deprecated/removed, but it exists now so we need to consider it in order
to cache correctly.
This commit introduces a new UnboundTemplate class, which represents a
template with unknown locals. Template objects can be built from it by
using `#with_locals`. Currently, this is just a convenience around
caching templates, but I hope it's a helpful concept that could have
more utility in the future.
We didn't previously have many tests directly against the
OptimizedFileSystemResolver or FileSystemResolver, though usually
failures would be exposed through other tests.
It's easier to test some specifics of the behaviour with unit tests.
This also lets us test FileSystemResolver (non-optimized) which I don't
think previously had much testing (other than from classses inheriting
it).
Previously, we would discard the template source after rendering, if we
had a virtual path, in hopes that the virtual path would let us find our
same template again going through the Resolver.
Previously we discarded the source as an optimization, to avoid keeping
it around in memory. By instead just reading the file every time source
is called, as FileTemplate does, this is unnecessary.
Mainly to help with knowning which template is reponsible for the
warning.
handler.class # => Class
handler.to_s # => Coffee::Rails::TemplateHandler
Before:
Change:
>> Class#call(template)
To:
>> Class#call(template, source)
After:
Change:
>> Coffee::Rails::TemplateHandler.call(template)
To:
>> Coffee::Rails::TemplateHandler.call(template, source)
This is because we only use hash to maintain the result. So when the key
are the same, the result would be skipped. The solution is to maintain
an array for tracking every item's position to restructure the result.
Previously, when using `render file:`, it was possible to render files
not only at an absolute path or relative to the current directory, but
relative to ANY view paths. This was probably done for absolutely
maximum compatibility when addressing CVE-2016-0752, but I think is
unlikely to be used in practice.
Tihs commit removes the ability to `render file:` with a path relative
to a non-fallback view path.
Make FallbackResolver.new private
To ensure nobody is making FallbackResolvers other than "/" and "".
Make reject_files_external_... no-op for fallbacks
Because there are only two values used for path: "" and "/", and
File.join("", "") == File.join("/", "") == "/", this method was only
testing that the absolute paths started at "/" (which of course all do).
This commit doesn't change any behaviour, but it makes it explicit that
the FallbackFileSystemResolver works this way.
Remove outside_app_allowed argument
Deprecate find_all_anywhere
This is now equivalent to find_all
Remove outside_app argument
Deprecate find_file for find
Both LookupContext#find_file and PathSet#find_file are now equivalent to
their respective #find methods.
Hector Bustillos