For accessibility reasons[1], it's recommended not to use "here"/"click
here"/"more" as the title for a link. When screen reader users are
tabbing through all links on the page, they'll miss the context of "read
more about X" preceding the "here". Thankfully, the sentences in the are
largely good to go, so the "here" can be dropped in favour of the last
part of the sentence to give the link title more meaning.
Some of these text changes may seem trivial, but when considering the
link text outwith its context sentences, the text has some more meaning
for those reading them through screen readers. (e.g. "API documentation"
-> "`number_to_currency` API documentation")
[1]: https://www.gov.uk/guidance/content-design/links#writing-link-text
I was reading this source code and made a few edits on passing to ensure
style details agree within the file itself and Rails.
The addition of "# noop" makes the method body look similar to other
analogous ones in the same file (not shown in the diff).
In addition to updating the code examples and editing text for clarity and flow, here some more details on some of the changes:
- [X] Do we still need an HTML5 warning at the end of the 1st section? It's pretty standard these days.
--> agree, removed.
- [X] Not sure the output of `_form_with model: @article`_ is 100% correct, might need to double check that.
--> yes. updated this example and got the HTML output from my "guides playground" rails app.
- [X] When we mention `record.persisted?` in record identification, could be a good plug to link to the Active Model guide on that.
--> Hm...there is no direction mention, other than this https://guides.rubyonrails.org/active_model_basics.html#conversion
- [X] Similar to STI, link to the guide / reference on it.
- [X] Time Zone and Country Select should likely be broken into separate sub-sections (I don't mind still mentioning country select)
- [X] Would the file upload example would be better with a CSV for local processing, rather than showing saving to local disk? (which is probably a very uncommon usage?)
- [X] The _labeled_form_with_ example could likely be simplified with `_**options_` being all that it takes, instead of explicitly showing all possible kwargs.
- [X] It may be better to show "complex forms" (section 10) right after the parameters (section 8), moving "forms to external resources" down... just because complex forms require exactly the fields_for incantation that was detailed further under the parameters section, so it seems a better continuation. (or potentially even reversed? complex forms then params? not sure)
- [X] Under "complex forms", adding fields on the flow could be slightly expanded, it feels very "go figure".
--> Yeah, not sure what to do about this one. Was thinking about removing it as there is not built-in support to showcase.
---------
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
Co-authored-by: Petrik de Heus <petrik@deheus.net>
Co-authored-by: Amanda Perino <58528404+AmandaPerino@users.noreply.github.com>
Co-authored-by: Karl Lingiah <karl@superchilled.co.uk>
The Logger severity predicates have existed since the [introduction of
Logger][1]. However, these methods only looked at the `level` instance
variable, so they did not work with the [thread safe implementation][2]
of temporary log levels in Rails.
Since then, the Logger severity predicates were [updated][3] to use the
`level` method instead of the instance variable, making Rails' severity
predicate overrides obsolete.
This commit removes Rails' custom severity predicates in favor of
Logger's implementation, since the new implementation was released in
Logger 1.4.2 and came bundled with Ruby 2.7.0.
[1]: ruby/logger@525b58d97e
[2]: rails/rails@629efb6057
[3]: ruby/logger@7365c995bf
On CI, this takes about 8 hours. On my PC I canceled after 3.
I suspect this comment in rdoc to be relevant (since this method is where it is stuck): 4b84660690/lib/rdoc/mixin.rb (L68-L71)
Removing a few includes eventually makes it complete. It doesn't seem to matter which ones you remove.
https://github.com/rails/rails/pull/52185 was the trigger for this.
Currently, we use both Thor and Rake for `bin/rails` commands.
We eventually want to get all the built-ins task promoted to Thor Commands.
This migrates the `stats` task to Thor.
