This test were assuming that the list of render options will always be
the same. Fixing that so this doesn't break when we add/remove render
option in the future.
This is an option for to HTML content with a content type of
`text/html`. This rendering option calls `ERB::Util.html_escape`
internally to escape unsafe HTML string, so you will have to mark your
string as html safe if you have any HTML tag in it.
Please see #12374 for more detail.
This is as an option to render content with a content type of
`text/plain`. This is the preferred option if you are planning to render
a plain text content.
Please see #12374 for more detail.
This is an option for sending a raw content back to browser. Note that
this rendering option will unset the default content type and does not
include "Content-Type" header back in the response.
You should only use this option if you are expecting the "Content-Type"
header to not be set. More information on "Content-Type" header can be
found on RFC 2616, section 7.2.1.
Please see #12374 for more detail.
Allow setting `request.variant` as an array - an order in which they will be
rendered.
For example:
request.variant = [:tablet, :phone]
respond_to do |format|
format.html.none
format.html.phone # this gets rendered
end
automatically call @foo.to_partial_path
Calling `render @foo` allows local variables but not options to be
passed to the partial renderer. The correct way to render an object AND
pass options to the partial renderer is to pass the object in the
`:partial` parameter. However, there were previously no tests for this
behaviour (in `render_helper_test.rb` at least).
I did not see in the docs that `button_to` supports not only URLs but paths as well. I documented this functionality with a unit tests and added an example to the docs as well.
LookupContext is eagerly loaded, and FallbackFileSystemResolver is
referenced at the class level. Just require the resolver from the
eagerly loaded class rather than jumping through autoload hoops
The current implementation can't handle some special cases of oddly-formatted Ruby. Now we are able to detect them:
* Multi-line arguments on the `render` call
* Strings containing quotes, e.g. `"something's wrong"`
* Multiple kinds of identifiers - instance variables, class variables and globals
* Method chains as arguments for the `render` call
Also, this fix reduces the rate of "false positives" which showed up when we had calls/access to identifiers containing `render`, like `surrender` and `rendering`.
The use of `display:inline` with the content_tag call in the
extra_tags_for_form method potentially causes display issues with some
browsers, namely Internet Explorer. IE's behaviour of not collapsing
the line height on divs with ostensibly no content means that the
automatically added div containing the hidden authenticity_token, utf8
and _method form input tags may interfere with other visible form
elements in certain circumstances. The use of `display:none` rather
than `display:inline` fixes this problem.
Fixes#6403
- While editing an existing record, end_year is equal to current selected year plus 5 by default.
- While editing an existing record, start_year is equal to current selected year value minus 5 by default.
- Fixes#13552
Acked-by: Prathamesh Sonpatki <csonpatki@gmail.com>
Acked-by: Prathamesh Sonpatki <csonpatki@gmail.com>
Change most tests to make use of assert_raise returning the raised
exception rather than relying on a combination of flunk + rescue to
check for exception types/messages.
Before ec16ba75a5493b9da972eea08bae630eba35b62f,
ActionView::Helpers::TranslationHelper#translate has raised errors with
specifying options[:raise] to true.
This should work by this fix:
begin
t(:"translations.missing", raise: true)
rescue I18n::MissingTranslationData
p :hello!
end
Now users have to explicit mark the unit as safe if they trust it.
Closes#13161
Conflicts:
actionpack/lib/action_view/helpers/number_helper.rb
actionpack/test/template/number_helper_i18n_test.rb
By default, variants in the templates will be picked up if a variant is set
and there's a match. The format will be:
app/views/projects/show.html.erb
app/views/projects/show.html+tablet.erb
app/views/projects/show.html+phone.erb
If request.variant = :tablet is set, we'll automatically be rendering the
html+tablet template.
In the controller, we can also tailer to the variants with this syntax:
class ProjectsController < ActionController::Base
def show
respond_to do |format|
format.html do |html|
@stars = @project.stars
html.tablet { @notifications = @project.notifications }
html.phone { @chat_heads = @project.chat_heads }
end
format.js
format.atom
end
end
end
The variant itself is nil by default, but can be set in before filters, like
so:
class ApplicationController < ActionController::Base
before_action do
if request.user_agent =~ /iPad/
request.variant = :tablet
end
end
end
This is modeled loosely on custom mime types, but it's specifically not
intended to be used together. If you're going to make a custom mime type,
you don't need a variant. Variants are for variations on a single mime
types.
i18n doesn't depend on active support which means it can't use our html_safe
code to do its escaping when generating the spans. Rather than try to sanitize
the output from i18n, just revert to our old behaviour of rescuing the error
and constructing the tag ourselves.
Fixes: CVE-2013-4491
The previous behavior equated the sanitize option for simple_format with the
escape option of content_tag, however these are two distinct concepts.
This fixes CVE-2013-6416
Conflicts:
actionview/lib/action_view/helpers/text_helper.rb
This reverts commit f4a5a9ea4d183f4102796215d4502c46dbe3e52b, reversing
changes made to 7ccb482181ee6c47c765406009018a15172812de.
Reason:
The logic is different, the first call to #option_value_selected? is for
the :selected option (the argument is the "selected" variable), the second
call is for the :disabled option (the argument is the "disabled" variable).
