As most of the PermissionsPolicy is defined in
ActionDispatch::HTTP::PermissionsPolicy, it should include most of the
documentation. ActionController::Metal::PermissionsPolicy should
describe controller overrides.
This PR also makes the documentation more similar to the
ActionDispatch::HTTP::ContentSecurityPolicy documentation.
Note:
The Feature-Policy header has been renamed to Permissions-Policy
in the specification. The Permissions-Policy requires a different
implementation and isn't yet supported by all browsers. To avoid
having to rename this middleware in the future we use the new
name for the middleware but keep the old header name in the
documentation for now.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
This has the benefit of hiding the warning message from git when
initialBranch configuration is unset, and was a recommendation on the
original commit adding main as the default branch for generators.
Ref: eb261937ac856100b4e1c8a2dbb56aab6e5d140e
I haven't yet identified why this particular test is causing issues when
other similarly-shaped ones seem fine, but if skipping it gets CI
working again, that's an improvement for now.
core_ext/array/wrap
- added in b1164adda12268b38bba9b0d81c0d26b7251b8bb
- usage removed in fa986ae0cac423bf1ebcb5caeccbecf00c990094
core_ext/numeric/time
- added in ee51b51b60f9e6cce9babed2c8a65a14d87790c8, but usage was only
in mem_cache_store so moved require there
Rendering the list of boot steps as a code block confused the syntax
highlighter.
This commit changes the list to use RDoc's ordered list syntax, and adds
inline code markup as appropriate.
The "Serialization formats" ASCII table confused the syntax highlighter.
Additionally, the "database storage" column headers were a bit muddled,
and the "NULL" column was difficult to decipher.
This commit relocates that information to the `class_name_or_coder`
parameter description, expressed as a list of accepted values.
This commit also fixes the custom coder code example (which called
`string.rot13` instead of `rot13(string)`), and improves the
documentation formatting in various spots.
"Overwrite" means "destructively replace", and is more suitable when,
for example, talking about writing data to a location.
"Override" means "supersede", and is more suitable when, for example,
talking about redifining methods in a subclass.
This almost never matters, but if the path-global 'rake' or 'rails'
points to a specific (and wrong) ruby version, (or, possible in CI,
there is no installed 'rails' executable), things get confused.
Instead, any time we mean "run a global 'rails', as for 'new'", use a
fully-qualified path to our in-tree copy. And any time we're working
inside an application, use the bin/rails script directly. It would be
equivalently valid to always use the one in exe/, because that handles
searching for bin/rails internally... but it's uglier to fully-qualify,
plus 'rake' would then be more complicated.
Fix: https://github.com/rails/rails/issues/44496
It's really unfortunate, but since thread locals were copied
since a decade and we moved most of them into IsolatedExecutionState
we now need to copy it too to keep backward compatibility.
However I think it's one more sign that AC::Live should be
rethought.
