| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Assigning to a collection of attachments appends rather than replacing, as in 5.2. Existing 5.2 apps that rely on this behavior will no longer break when they're upgraded to 6.0.
For apps generated on 6.0 or newer, assigning replaces the existing attachments in the collection. #attach should be used to add new attachments to the collection without removing existing ones.
I expect that we'll deprecate the old behavior in 6.1.
Closes #36374.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as it is
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.
https://github.com/rails/rails/blob/39de7fac0507070e3c5f8b33fbad6fced84d97ed/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 ]
|
|
|
|
| |
To avoid word wrap in the rendered guide.
|
|\
| |
| | |
[ci skip] Clarity about embed metadata in signed and encrypted cookie
|
| | |
|
|/ |
|
|\
| |
| |
| |
| | |
vishaltelangre/fix-confusing-sentence-in-upgrade-guide
[ci skip] Fix confusing sentence in upgrade guide
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
supports it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Generally followed the pattern for https://github.com/rails/rails/pull/32034
* Removes needless CI configs for 2.4
* Targets 2.5 in rubocop
* Updates existing CHANGELOG entries for fewer merge conflicts
* Removes Hash#slice extension as that's inlined on Ruby 2.5.
* Removes the need for send on define_method in MethodCallAssertions.
|
| |
|
| |
|
|
|
|
|
|
| |
Context https://github.com/rails/rails/pull/33605#discussion_r210354278
Related to #32937, #33605
|
|
|
|
|
|
|
|
|
| |
This commit adds a skeleton of "Ruby on Rails 6.0 Release Notes".
It isn't a good time to add changelogs' entries to this guide since we can
redo/revert some things till the final release 6.0.
It would be better to do it close to the release.
But we already can add mentions about major features
that have been added to 6.0. I added mention about "Parallel Testing".
|
| |
|
| |
|
|
|
|
| |
handling the addition of configurable default HTTP headers. [ci skip]
|
|\
| |
| |
| |
| | |
albertoalmagro/albertoalmagro/prefer-rails-command-over-bin-rails
Prefer rails command over bin/rails
|
| |
| |
| |
| | |
This commit substitutes references to rails/rake task for rails command
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As discussed in #33203 rails command already looks for, and runs,
bin/rails if it is present.
We were mixing recommendations within guides and USAGE guidelines,
in some files we recommended using rails, in others bin/rails and
in some cases we even had both options mixed together.
|
|/
|
|
|
| |
http links will be redirected to the https version, but still better to
just directly link to the https version.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today there are two common ways for Rails developers to force their
applications to communicate over HTTPS:
* `config.force_ssl` is a setting in environment configurations that
enables the `ActionDispatch::SSL` middleware. With this middleware
enabled, all HTTP communication to your application will be redirected
to HTTPS. The middleware also takes care of other best practices by
setting HSTS headers, upgrading all cookies to secure only, etc.
* The `force_ssl` controller method redirects HTTP requests to certain
controllers to HTTPS.
As a consultant, I've seen many applications with misconfigured HTTPS
setups due to developers adding `force_ssl` to `ApplicationController`
and not enabling `config.force_ssl`. With this configuration, many
application requests can be served over HTTP such as assets, requests
that hit mounted engines, etc. In addition, because cookies are not
upgraded to secure only in this configuration and HSTS headers are not
set, it's possible for cookies that are meant to be secure to be sent
over HTTP.
The confusion between these two methods of forcing HTTPS is compounded
by the fact that they share an identical name. This makes finding
documentation on the "right" method confusing.
HTTPS throughout is quickly becomming table stakes for all web sites.
Sites are expected to operate over HTTPS for all communication,
sensitive or otherwise. Let's encourage use of the broader-reaching
`ActionDispatch::SSL` middleware and elminate this source of user
confusion. If, for some reason, applications need to expose certain
endpoints over HTTP they can do so by properly configuring
`config.ssl_options`.
|
|
|
|
|
|
|
|
|
|
|
| |
Add section "Expiry in signed or encrypted cookie is now embedded in the cookies values"
to `master` since it should always be in the guides, not only for version 5.2.
Add info about `config.action_dispatch.use_authenticated_cookie_encryption`
to the "Configuring Rails Applications" guide.
It was committed straight to `5-2-stable` since we don't need this
functionality in 6.0. Related to b25fcbc074ea688765af62a163698d5449221a8c.
|
| |
|
|
|
|
|
|
| |
Skipping over 2.4.0 to sidestep the `"symbol_from_string".to_sym.dup` bug.
References #32028
|
| |
|
|\
| |
| | |
Added a note about bootsnap in the Rails 5.2 upgrade guide [ci skip]
|
| | |
|
| | |
|
|/ |
|
|\
| |
| | |
Make it same title in index and page [ci skip]
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The initial commit (efaa6e4f79d457c2cdd08cbc56d63bc972a6993c) that changed this
behavior was intended to be a minor change, but ended up becoming a
large-ish breaking change within Active Record.
This is because instead of only JSON encoding `Hash`es or `Array`s in `#serialize`,
we now encode all values passed in. This is an issue if you're passing in a `String`,
that has already been transformed from a `Hash` to a `String`, since your data
is now being double encoded.
Unfortunately, the change was included in one of the v5.0.0 beta
releases, and it is too late to revert without huge ripple effects.
Thus, all we can do is update the documentation (via this commit), and
add some test coverage (coming soon in a PR) for the new behavior.
Please note that in the documentation I talk about deserialization, not
about serialization, where the actual change occurred. This is because
you won't notice any changes in serialized data until you try and
deserialize it. Also to make the change itself (confusing until you
read through everything multiple times) easier to understand.
Related #27788, #25594, #26101, #24234, #28292, #28285, #28285, and
probably others.
[ci skip]
|