The framework defaults file sets the serializer to `:hybrid` instead of
`:marshal`, but we can just remove the actual setting and referer to the
defaults file instead. [ci-skip]
This header has been deprecated and the XSS auditor it triggered
has been removed from all major modern browsers (in favour of
Content Security Policy) that implemented this header to begin with
(Firefox never did).
[OWASP](https://owasp.org/www-project-secure-headers/#x-xss-protection)
suggests setting this header to '0' to disable the default behaviour
on old browsers as it can introduce additional security issues.
Added the new behaviour as a framework default from Rails 7.0.
ruby/debug is a new debugger that is going to ship with CRuby.
It makes sense for Rails to switch to this one because that is
where the language is heading, and because Byebug is not fully
compatible with Zeitwerk. See
https://github.com/deivid-rodriguez/byebug/issues/564
While ruby/debug has not been heavily tested with Zeitwerk,
casual usage seems to suggest it works without issues, including
explicit namespaces, which is where Byebug and Zeitwerk conflict.
Byebug is terrific, thanks a lot for all these years. ❤️
Because the PluginCommand is defined with `hide_command!`, running
`bin/rails -h` hides the plugin command.
As an alternative to removing the `hide_command!` this adds the plugin
command to the USAGE. Unless it's an engine, because adding an engine to
an engine doesn't make sense.
Both the railtie and engine terms are used so a user can search for both.
[Petrik de Heus + Rafael Mendonça França + Jonathan Hefner]
When running `bin/rails -h` the following messages is shown:
> All commands can be run with -h (or --help) for more information.
This doesn't apply to the commands that are Rake tasks like db:migrate.
If you run `bin/rails db:migrate -h` you'll get the Rake help, which
can be confusing...
Instead, if we replace the `-h` argument with `--describe db:migrate`
Rails outputs the Rake task descriptions, which are a lot more helpful:
rails db:migrate
Migrate the database (options: VERSION=x, VERBOSE=false, SCOPE=blog).
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
Fix a bug introduced by
3fe0ab52df
that raised an undefined method when trying to deep merge an array with
an empty config hash
It also adds a test to clarify config_for behaviour with root arrays: when there's
an env array and a shared array, it should only returns the env key (and not a concatenation)
Closes#42698
When passing an invalid index type to a generator, the index is silently
ignored. For example when misspelling the index:
bin/rails g model post title:string:indxe
Instead of silently ignoring the invalid index, the generator should
raise an error.
This continues the work in d163fcd6208c9b0507746888c7fb4a6f934303ce
where we started raising errors if the attribute types are invalid.
Currently when you make a new Rails app, we generate a lot of initializers. For new users, I think we should try and include as few as possible - the less files, the less daunting a new app is. And for upgrades I'd like to [continue to simplify the update process](https://github.com/rails/rails/pull/41083), in this case by not bringing back initializers you have probably already dismissed or modified.
In this PR I'm proposing we remove two initializers: `application_controller_renderer.rb` and `cookies_serializer.rb`:
**`application_controller_renderer.rb`**. This configures [`ActionController::Renderer`](https://api.rubyonrails.org/classes/ActionController/Renderer.html), for rendering views outside of controller actions. I don't think this is something most Rails apps will need (certainly not on day 1); users can configure this feature when they need it.
**`cookies_serializer.rb`**. This was added for [Rails 4.1](https://guides.rubyonrails.org/upgrading_ruby_on_rails.html#cookies-serializer). The behaviour is:
- For new apps, the initializer says `:json`.
- For upgraded apps that don't have the initializer, it is added with value `:marshal`.
- If there's no initializer, the [default value](c9a89a4067/actionpack/lib/action_dispatch/middleware/cookies.rb (L589)) is `:marshal`.
Since nobody should be upgrading direct from Rails 4.0 to Rails 7.0, we can simplify this by using new framework defaults. So the behavior will now be:
- For new apps, `config.load_defaults("7.0")` sets the value to `:json`.
- The `new_framework_defaults_7_0.rb` file explains this, and suggests using `:hybrid` to be upgrade to JSON cookies.
- No changes to [the code](c9a89a4067/actionpack/lib/action_dispatch/middleware/cookies.rb (L589)); the default value is `:marshal` if you don't set one.
So if you were not setting a `cookies_serializer` previously and you want to keep using `:marshal`, you'll need to explicitly set this before using `config.load_defaults("7.0")`, otherwise it will switch to `:json`. The upside of this is you won't get the `cookies_serializer.rb` file created for you every time you upgrade.
Generators can create invalid migrations when passing an invalid
field type. For example, when mixing up the name and type:
bin/rails g model post string:title
This will generate a field for post with a column named `string`
of the type `title`, instead of a column named `title` of the type
`string`. Running the migration will result in an error as the type
`title` is not known to the database.
Instead of generating invalid files, the generator should raise an error
if the type is invalid. We validate the type by checking if it's a
default migration types like: string, integer, datetime, but also
references, and rich_text.
If the type isn't a default type, we can ask the
database connection if the type is valid. This uses the `valid_type?`
method defined on each database adapter, which returns true if the
adapter supports the column type. This method is also used by the
SchemaDumper.
Some gems like 'postgis' add custom types. The 'postgis' gem adds these
types by overriding the `native_database_types` method.
That method is used by `valid_type?` method on the database adapter,
making this change compatible with 'postgis'.
Ruby master ships with Psych 4.0.0 which makes `YAML.load`
defaults to safe mode (https://github.com/ruby/psych/pull/487).
However since these YAML files are trustworthy sources
we can parse them with `unsafe_load`.
Previous discussion: #38412, #38325, 37423e4, 24f9c03
- Rack::Runtime is replaced by FakeRuntime, which is a dummy middleware
that just passes requests on and cannot be used in middleware operations
- Using Rack::Runtime in middleware operations (relative inserts, moves,
etc.) throws a deprecation warning and uses FakeRuntime instead
- if an application adds Rack::Runtime explicitly (use, unshift, etc.),
then the deprecation warning does not happen and FakeRuntime is
ignored
- docs are updated to no longer reference Rack::Runtime
Fix issue where running "rails g scaffold Author" will create system
test names like "creating a Author" and "updating a Author" so that
there are not grammatical errors. Now running "rails g scaffold Author"
will generate "should create Author", "should update Author", and
"should destroy Author" which works around the article vowel-sound
agreement issues.
Fixes#40744
