| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
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]
|
|
|
|
|
|
| |
`it` and `has` are for singular, not plural
[ci skip]
|
|
|
|
| |
`ActionView::Helpers::RecordTagHelper`
|
|
|
|
| |
slice as this has actually been implemented by Parameters
|
|
|
|
| |
The `secrets` method is in `Application` class, not `Configuration` class.
|
|
|
|
| |
[ci skip]
|
| |
|
|
|
|
|
| |
This is a small breaking change that we chose to make in 5.1 since the
fix can be done with a search and replace tool.
|
| |
|
|
|
|
|
|
|
| |
Since using a `ActiveSupport::Deprecation::DeprecatedConstantProxy`
would prevent people from inheriting this class and extending it
from the `ActiveSupport::HashWithIndifferentAccess` one would break
the ancestors chain, that's the best option we have here.
|
|\
| |
| | |
Add note about breakage in file uploads in controller tests to upgrading guide
|
| |
| |
| |
| |
| |
| |
| |
| | |
guide
ref #26404
[ci skip]
|
|/ |
|
|
|
|
|
|
|
|
|
| |
jeremywadsack/doc_cache_importability""
This reverts commit 6961afefd2f163f30b9ae3aacb74b290287f9a80.
We were not able to keep backward compatibility in this case so it is
better to ask people to upgrade with cold cache.
|
| |
|
|\
| |
| | |
Consistent examples and template for assets#precompile
|
| |
| |
| |
| |
| |
| |
| |
| | |
Listening to a few developers today discussing their troubles in understanding how to use the asset pipeline, it turns out that the precompile examples in the guides and assets.rb template have over time become a bit inconsistent.
This PR makes the examples consistent in code style, spacing, and asset names, removes the old 'swfObject.js' example, and in a couple of places wraps lines at 80 characters including in the assets.rb template.
Re-add spaces inside array parentheses.
|
|\ \
| | |
| | | |
Clarify migration to ApplicationRecord in upgrade guides [ci skip]
|
| | | |
|
|/ / |
|
| |
| |
| |
| |
| |
| | |
Reason: See https://github.com/rails/rails/pull/26163#issuecomment-239703322
This reverts commit 39effc857e5c774670d6fad1a26aebcc33c51f0a.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
The Guides section about autoloading being disabled was slightly confusing
(#24724) and didn't directly reference the removed feature by name
(config.autoload_paths) making it much harder for someone to search the upgrade
guides for a mention or serendipitously find it via a Google search when running
into autoloading issues.
I also fixed some confusing turns of phrase and a missing word.
/cc @vipulnsward @jvanbaarsen
|
|
|
| |
Fix a small typo on doc: "caches_pages" -> "caches_page".
|
| |
|
|
|
|
|
| |
See issue #25581:
https://github.com/rails/rails/issues/25581
|