| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
active_support/rails.rb
|
| |
|
| |
|
|\
| |
| | |
Fix TranslationHelper#translate handling of Hash defaults
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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`.
|
|\
| |
| | |
Introduce ActionView::Component
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Co-authored-by: Natasha Umer <natashau@github.com>
Co-authored-by: Aaron Patterson <tenderlove@github.com>
Co-authored-by: Shawn Allen <shawnbot@github.com>
Co-authored-by: Emily Plummer <emplums@github.com>
Co-authored-by: Diana Mounter <broccolini@github.com>
Co-authored-by: John Hawthorn <jhawthorn@github.com>
Co-authored-by: Nathan Herald <myobie@github.com>
Co-authored-by: Zaid Zawaideh <zawaideh@github.com>
Co-authored-by: Zach Ahn <engineering@zachahn.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We sometimes say "✂️ newline after `private`" in a code review (e.g.
https://github.com/rails/rails/pull/18546#discussion_r23188776,
https://github.com/rails/rails/pull/34832#discussion_r244847195).
Now `Layout/EmptyLinesAroundAccessModifier` cop have new enforced style
`EnforcedStyle: only_before` (https://github.com/rubocop-hq/rubocop/pull/7059).
That cop and enforced style will reduce the our code review cost.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
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.
https://github.com/guard/listen/blob/8d85b4cd5788592799adea61af14a29bf2895d87/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
|
|\
| |
| | |
Fix unexpected select_tag delete behavior when include_blank is present
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|\
| |
| |
| |
| | |
abhaynikam/35265-remove-unused-argument-layout-from-rendered-template
Removed unused layout attribute from RenderedTemplate
|
| | |
|
| |
| |
| |
| | |
e.g. via test-unit-rails' `run_setup`
|
| | |
|
| | |
|
|\ \
| | |
| | | |
De-duplicate templates, introduce UnboundTemplate
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|/ / |
|
| |
| |
| |
| | |
This is unnecessary now that we can just provide a file source
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Now that Template#source will always return a source, this is
unnecessary.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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)
|
|\ \
| | |
| | | |
Fix partial caching ignore repeated items issue
|
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Make Resolver#find_all_anywhere equivalent to #find_all
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | | |
in #35826
|
|/ / |
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Deprecate render layout with an absolute path
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This has similar problems to render file:.
I've never seen this used, and believe it's a relic from when all
templates could be rendered from an absolute path.
|
|\ \ \
| |/ /
|/| | |
RFC: Introduce Template::File
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The previous behaviour of render file: was essentially the same as
render template:, except that templates can be specified as an absolute
path on the filesystem.
This makes sense for historic reasons, but now render file: is almost
exclusively used to render raw files (not .erb) like public/404.html. In
addition to complicating the code in template/resolver.rb, I think the
current behaviour is surprising to developers.
This commit deprecates the existing "lookup a template from anywhere"
behaviour and replaces it with "render this file exactly as it is on
disk". Handlers will no longer be used (it will render the same as if
the :raw handler was used), but formats (.html, .xml, etc) will still be
detected (and will default to :plain).
The existing render file: behaviour was the path through which Rails
apps were vulnerable in the recent CVE-2019-5418. Although the
vulnerability has been patched in a fully backwards-compatible way, I
think it's a strong hint that we should drop the existing
previously-vulnerable behaviour if it isn't a benefit to developers.
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | | |
erose/better-error-reporting-for-syntax-errors-in-templates
Display a more helpful error message when an ERB template has a Ruby syntax error.
|
| | | |
|
|\ \ \
| | | |
| | | | |
Aligned the order of the arguments of render_template and render_with_layout
|