When placeholder set to true on `text_field_tag`, it will try to look up its value from the translation files.
The documentation referenced an incorrect translation key scope, it is defined in [Placeholderable][1] as `helpers.placeholder` (singular).
Followup for #37054
Also improves wording.
[1]: 4640cff2b2/actionview/lib/action_view/helpers/tags/placeholderable.rb
This regression was added in c6f46564771413f4a06703fc6b1f82ed09a0c4c9.
What was happening is what when we were setting the belongs_to
associonation and the parent record already had one different child, the
inverted association was not being set.
* Fix regression for select tag helper with array
v6.1.0.rc1 does not generate DOM with the selected attribute
when the object's method returns an array.
This is because it has been changed by #34809 to always convert
to a string.
This commit fixes the issue.
## Steps to reproduce
```ruby
# frozen_string_literal: true
require "bundler/inline"
gemfile(true) do
source "https://rubygems.org"
git_source(:github) { |repo| "https://github.com/#{repo}.git" }
gem "rails", ENV["RAILS_VERSION"]
end
require "action_view"
require "minitest/autorun"
class BugTest < ActionView::TestCase
Post = Struct.new("Post", :tags)
def test_stuff
@post = Post.new
@post.tags = ["foo", "bar"]
expected = <<~DOM.strip
<select name="post[tags]" id="post_tags"><option selected="selected" value="foo">foo</option>
<option selected="selected" value="bar">bar</option>
<option value="buz">buz</option></select>
DOM
assert_dom_equal(expected, select("post", "tags", %W(foo bar buz), { multiple: true }))
end
end
```
The test succeeds on v6.0.3.4, but the test fails on v6.1.0.rc1.
* Update actionview/lib/action_view/helpers/tags/select.rb
[Takumi Shotoku + Rafael Mendonça França]
did_you_mean 1.5.0 will add suggestions to `LoadError`. This means that
`LoadError#message` will now return a new string on each invocation, and
mutating the result will no longer modify the error's message.
For example PG refers to https://www.ietf.org/rfc/rfc3339.txt when converting(Ref: https://www.postgresql.org/docs/current/datatype-datetime.html)
According to the ref there is no explicit mention of allowing sign before the parts, which reads as below:
Durations:
dur-second = 1*DIGIT "S"
dur-minute = 1*DIGIT "M" [dur-second]
dur-hour = 1*DIGIT "H" [dur-minute]
dur-time = "T" (dur-hour / dur-minute / dur-second)
dur-day = 1*DIGIT "D"
dur-week = 1*DIGIT "W"
dur-month = 1*DIGIT "M" [dur-day]
dur-year = 1*DIGIT "Y" [dur-month]
dur-date = (dur-day / dur-month / dur-year) [dur-time]
duration = "P" (dur-date / dur-time / dur-week)
We should not attempt to move sign forward in this case.
In the same way that requests may need to be excluded from forced SSL,
requests may also need to be excluded from the Host Authorization
checks. By providing this additional flexibility more applications
will be able to enable Host Authorization while excluding requests
that may not conform. For example, AWS Classic Load Balancers don't
provide a Host header and cannot be configured to send one. This means
that Host Authorization must be disabled to use the health check
provided by the load balancer. This change will allow an application
to exclude the health check requests from the Host Authorization
requirements.
I've modified the `ActionDispatch::HostAuthorization` middleware to
accept arguments in a similar way to `ActionDispatch::SSL`. The hosts
configuration setting still exists separately as does the
hosts_response_app but I've tried to group the Host Authorization
settings like the ssl_options. It may make sense to deprecate the
global hosts_response_app if it's only used as part of the Host
Authorization failure response. I've also updated the existing tests
as the method signature changed and added new tests to verify the
exclusion functionality.
Re: https://github.com/rails/rails/issues/37066#issuecomment-709403972
Puma (and some other multi-threaded application servers) may check the `Thread` list before and after forking to look for any threads that may have been running during a call to `fork`. Threads running during a `fork` can leave memory and resources open and potentially cause leaks or deadlocks.
However, the Reaper thread in ActiveRecord cannot orphan any resources or memory, and will be cleaned up after forking.
Setting this thread local variable allows Puma and other application servers to ignore this thread for the purpose of displaying warnings to users about threads present and running during `fork`.
Co-authored-by: Eugene Kenny <elkenny@gmail.com>
Now that we have implemented granular connection swapping in #40370
we need a new API that will allow connections to multiple databases. The
reason we need this API is it will prevent deep nesting in cases where
we know that we want 3 of our 5 databases to connect to reading and
leave the rest on writing.
With this API, instead of writing:
```ruby
AnimalsRecord.connected_to(role: :reading) do
MealsRecord.connected_to(role: :reading) do
Dog.first # read from animals replica
Dinner.first # read from meals replica
Person.first # read from primary writer
end
end
```
This API would allow you to write:
```ruby
ActiveRecord::Base.connected_to_many([AnimalsRecord, MealsRecord], role: :reading) do
Dog.first # read from animals replica
Dinner.first # read from meals replica
Person.first # read from primary writer
end
```
This would come in especially handy for deeper nesting past 2 databases.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
- This is similar to other railties blocks (such as `console`,
`tasks` ...). The goal of this block is to allow the application
or a railtie to load code after the server start.
The use case can be to fire the webpack or react server in
development or start some job worker like sidekiq or resque.
Right now, all these tasks needs to be done in a separate
shell and gem maintainer needs to add documentation on
how to run their libraries if another program needs to run
next to the Rails server.
This feature can be used like this:
```ruby
class SuperRailtie < Rails::Railtie
server do
WebpackServer.run
end
end
```
Originally strict loading violations would always raise an error if
turned on for an association. This change allows for an application to
optionally log instead of raise. The behavior here is similar to how
strong parameters work. By default all environments will raise. An
application may want to use log in production while working on finding
all lazily loaded associations.
Set `config.active_record.action_on_strict_loading_violation` to `:log`
in your application to log instead of raise.
Follow-up to #34218.
This removes some filters that could filter innocuous fields such as
`author_name`. Filtering such fields might be surprising, especially to
people generating their first Rails app.
This commit also changes the `:password` filter to `:passw` so that it
can also filter fields such as `passwd`.
Reorders the methods since we usually go role, shard, then prevent
writes. I think it makes it easier to read.
Added documention to the methods for `current_shard` and
`current_preventing_writes`. These were originally marked as `nodoc` but
that doesn't make sense, apps may need to call these so we should make
them public.
