| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
we should take disabled option not only from `html_options` hash but from
`options` hash too like `build_select` method does it. So
datetime_select("post", "updated_at", { :discard_minute => true }, { :disabled => true })
datetime_select("post", "updated_at", :discard_minute => true , :disabled => true)
both these variants work now
closes #7431
|
| |
|
|
|
| |
This functionality will be available from gem
`active_record-session_store` instead.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
With a value of "nosniff", this prevents Internet Explorer from MIME-sniffing a response away from the declared content-type.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix indentation on template errors to consider line number character count.
For instance, when an error is shown, if the related source code snippet has line numbers from, lets say, 8-12, the lines are left aligned, which means the code indent is wrong:
8: foo
9: bar
10: raise
11: baz
12: ...
This changes it to right align the source code snippet, so that the indentation is correct:
8: foo
9: bar
10: raise
11: baz
12: ...
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
| |
This pattern was introduced as a plugin by @dhh.
The original implementation can be found in
https://github.com/rails/routing_concerns
|
| |
|
|
| |
their own header object
|
| | |
|
| |
|
|
| |
Updated documentation to demonstrate start_hour and end_hour options
|
| |
|
|
| |
We can avoid creating extra hashes with #merge, and use #merge! instead.
|
| |
|
|
|
|
|
| |
Further simplify the option_html_attributes method after the changes
introduced in dacbcbe55745aa9e5484b10b11f65ccca7db1c54 to not escape the
html options here (since they're going to be escaped down the chain in
content tag).
|
| |\
| |
| | |
Check for Blank Record in form_for
|
| | |
| |
| |
| | |
if nil or an empty array is passed into form_for you get a horrible error message, this one is much more indicative of what the programmer needs to know to fix the problem.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When you mount your application at a path, for example /myapp, server
should set SCRIPT_NAME to /myapp. With such information, rails
application knows that it's mounted at /myapp path and it should generate
routes relative to that path.
Before this patch, rails handled SCRIPT_NAME correctly only for regular
apps, but it failed to do it for mounted engines. The solution was to
hardcode default_url_options[:script_name], which is not the best answer
- it will work only when application is mounted at a fixed path.
This patch fixes the situation by respecting original value of
SCRIPT_NAME when generating application's routes from engine and the
other way round - when you generate engine's routes from application.
This is done by using one of 2 pieces of information in env - current
SCRIPT_NAME or SCRIPT_NAME for a corresponding router. This is because
we have 2 cases to handle:
- generating engine's route from application: in this situation
SCRIPT_NAME is basically SCRIPT_NAME set by the server and it
indicates the place where application is mounted, so we can just pass
it as :original_script_name in url_options. :original_script_name is
used because if we use :script_name, router will ignore generating
prefix for engine
- generating application's route from engine: in this situation we
already lost information about the SCRIPT_NAME that server used. For
example if application is mounted at /myapp and engine is mounted at
/blog, at this point SCRIPT_NAME is equal /myapp/blog. Because of that
we need to keep reference to /myapp SCRIPT_NAME by binding it to the
current router. Later on we can extract it and use when generating url
Please note that starting from now you *should not* use
default_url_options[:script_name] explicitly if your server already
passes correct SCRIPT_NAME to rack env.
(closes #6933)
|
| |/ |
|
| | |
|
| |
|
|
|
|
| |
Thanks to Marek Labos & Nethemba
CVE-2012-3465
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
can write `form_for @record, data: { behavior: 'autosave' }` instead of `form_for @record, html: { data: { behavior: 'autosave' } }` *DHH*
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We recommend the use of Unobtrusive JavaScript instead. For example:
link_to "Greeting", "#", :class => "nav_link"
$(function() {
$('.nav_link').click(function() {
// Some complex code
return false;
});
});
or
link_to "Greeting", '#', onclick: "alert('Hello world!'); return false", class: "nav_link"
for simple cases.
This reverts commit 3acdd652e9fe99481c879c84c5807a84eb9ad724.
|
| |
|
|
|
|
|
| |
what this makes ERB files look like.
This reverts commit 46b8bceedd3e47169c50a04c93161424909c75fb, reversing
changes made to 2f58795e783150f2e1b1f6c64e305703f0061129.
|
| |
|
|
| |
percent sign on a line to indicate non-inserted Ruby code.
|
| |
|
|
|
|
| |
Rails were including 'application.js' to the pack when using
`javascript_include_tag :all` even there's no application.js in the
public directory.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
| |
|
|
|
| |
Passing options as the last value in an array doesn't work with form_for.
This reverts commit 61c8a4d926343903593a27080216af7e4ed81268.
|
| |
|
|
|
| |
Passing options as the last value in an array doesn't work with form_for.
This reverts commit 6be564c7a087773cb0b51c54396cc190e4f5c983.
|
| | |
|
| |
|
|
|
|
|
|
| |
Rather than keep the url options in record_or_hash_or_array, extract it
and reverse merge with options as it may contain important private keys
like `:routing_type`.
Closes #7259
|
| |
|
|
|
| |
Generating an URL with an array of records is now able to build a query
string if the last item of the array is a hash.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
single check.
Rails includes a single character body to a head(:no_content) response to work around an old Safari bug where headers were ignored if no body sent.
This patch brings the behavior slightly closer to spec if :no_content/204 is explicity requested via a head only response.
Status comparison done on symbolic and numeric values
Not returning any content when responding with head and limited to a status code that explicitly states no content will be returned - 100..199, 204, 205, 304.
|
| |\
| |
| | |
Fix for digest authentication bug - issue #2301 in rails/rails
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content
Closes #7215
|
| |
|
|
| |
will work
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
responses.
Processing controller actions in a separate thread allows us to work
around the rack api - we can allow the user to set status and headers,
then block until the first bytes are written. As soon as the first
bytes are written, the main thread can return the status, headers, and
(essentially) a queue for the body.
|
