| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This make the config/initializers run before the railties are loaded
what can break some configurations.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This stems from [a comment](rails#17227 (comment)) by @dhh.
In summary:
* New Rails 5.0 apps will not accept `return false` as a way to halt callback chains, and will not display a deprecation warning.
* Existing apps ported to Rails 5.0 will still accept `return false` as a way to halt callback chains, albeit with a deprecation warning.
For this purpose, this commit introduces a Rails configuration option:
```ruby
config.active_support.halt_callback_chains_on_return_false
```
For new Rails 5.0 apps, this option will be set to `false` by a new initializer
`config/initializers/callback_terminator.rb`:
```ruby
Rails.application.config.active_support.halt_callback_chains_on_return_false = false
```
For existing apps ported to Rails 5.0, the initializers above will not exist.
Even running `rake rails:update` will not create this initializer.
Since the default value of `halt_callback_chains_on_return_false` is set to
`true`, these apps will still accept `return true` as a way to halt callback
chains, displaying a deprecation warning.
Developers will be able to switch to the new behavior (and stop the warning)
by manually adding the line above to their `config/application.rb`.
A gist with the suggested release notes to add to Rails 5.0 after this
commit is available at https://gist.github.com/claudiob/614c59409fb7d11f2931
|
| |
|
|
| |
Railties need to be used without having to require any dependecy first.
|
| |
|
|
|
| |
Let users require `active_support` before loading any ActiveSupport modules
http://guides.rubyonrails.org/active_support_core_extensions.html
|
| |
|
|
|
|
| |
configuration"
This reverts commit 39374aa925a7d670b039c0c0c9aa9f4aef19466b.
|
| |
|
|
|
|
| |
now lives in the application initializers.
Fix #8711
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
actionmailer/lib/action_mailer/base.rb
activesupport/lib/active_support/configurable.rb
activesupport/lib/active_support/core_ext/module/deprecation.rb
guides/source/action_controller_overview.md
guides/source/active_support_core_extensions.md
guides/source/ajax_on_rails.textile
guides/source/association_basics.textile
guides/source/upgrading_ruby_on_rails.md
While resolving conflicts, I have chosen to ignore changes done in
docrails at some places - these will be most likely 1.9 hash syntax
changes.
|
| | | |
|
| |/
|
|
| |
option added (default is Monday)
|
| |
|
|
|
|
|
| |
The new option allows any Ruby namespace to be registered and set
up for eager load. We are effectively exposing the structure existing
in Rails since v3.0 for all developers in order to make their applications
thread-safe and CoW friendly.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* Refactor log subscriber, use select! to avoid a new object
* Remove deprecation messages related to AS::Deprecation behavior
This was added about 2 years ago for Rails 3:
https://github.com/rails/rails/commit/d4c7d3fd94e5a885a6366eaeb3b908bb58ffd4db
* Remove some not used requires
* Refactor delegate to avoid string conversions and if statements inside each block
|
| | |
|
| | |
|
| |
|
|
|
|
| |
use find_zone! as well as adding Railtie tests
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
| |
|
|
| |
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
| |
|
|
|
|
| |
[#5012 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
notices, and make the behaviors independent of the environment names.
* In Rails 2.3 apps being upgraded, you will need to add the deprecation
configuration to each of your environments. Failing to do so will
result in the same behavior as Rails 2.3, but with an outputted warning
to provide information on how to set up the setting.
* New Rails 3 applications generate the setting
* The notification style will send deprecation notices using
ActiveSupport::Notifications. Third-party tools can listen in to
these notifications to provide a streamlined view of the
deprecation notices occurring in your app.
* The payload in the notification is the deprecation warning itself
as well as the callstack from the point that triggered the
notification.
|
| | |
|
| |
|
|
| |
backend if it was set through config.i18n.backend.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
default in production [#4428 state:resolved]
Allows to configure locale fallbacks through config.i18n.fallbacks. The default setting
config.i18n.fallbacks = true in production.rb will make I18n.t lookup fallback to the
I18n.default_locale if a translation could not be found for the current or given locale.
config.fallbacks = true
config.fallbacks.map = { :ca => :es }
config.fallbacks.defaults = [:'es-ES', :es]
config.fallbacks = [:'es-ES', :es]
config.fallbacks = { :ca => :es }
config.fallbacks = [:'es-ES', :es, { :ca => :es }]
Signed-off-by: Pratik Naik <pratiknaik@gmail.com>
|
| |
|
|
|
|
|
|
| |
should run during framework load do:
ActiveSupport.on_load(:action_controller) do
# Code run in the context of AC::Base
end
|
| |
|
|
| |
remove railtie_name and engine_name and allow to set the configuration object.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
add lazy_load_hooks.rb, which allows us to declare code that
should be run at some later time. For instance, this allows
us to defer requiring ActiveRecord::Base at boot time purely
to apply configuration. Instead, we register a hook that should
apply configuration once ActiveRecord::Base is loaded.
With these changes, brings down total boot time of a
new app to 300ms in production and 400ms in dev.
TODO: rename base_hook
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
paths, load active_support/railtie since we need it and ensure default logger is set before config.
|
| | |
|
| | |
|
| | |
|
| |
|
