1. 19 8月, 2020 1 次提交
  2. 04 8月, 2020 1 次提交
  3. 02 8月, 2020 1 次提交
    • J
      Add baseline defaults section [ci skip] · ff881137
      Jonathan Hefner 提交于
      Mentioning the baseline default for a config option can be confusing
      when that default is overridden by `config.load_defaults`.  To avoid
      that confusion, this commit relocates such baseline defaults from their
      explanatory paragraphs to a "Baseline defaults" section that flows with
      the other `config.load_defaults` sections.
      
      Ideally, when we override other baseline defaults in the future, we will
      relocate mention of them as done here.
      
      Closes #39387.
      ff881137
  4. 13 7月, 2020 1 次提交
  5. 08 7月, 2020 1 次提交
  6. 06 7月, 2020 1 次提交
  7. 15 6月, 2020 1 次提交
  8. 12 6月, 2020 1 次提交
  9. 11 6月, 2020 1 次提交
  10. 01 6月, 2020 2 次提交
  11. 28 5月, 2020 1 次提交
  12. 20 5月, 2020 1 次提交
  13. 19 5月, 2020 1 次提交
  14. 13 5月, 2020 1 次提交
    • E
      Revert "Remove deprecated `ActionMailer::DeliveryJob` and... · 336a07b9
      eileencodes 提交于
      Revert "Remove deprecated `ActionMailer::DeliveryJob` and `ActionMailer::Parameterized::DeliveryJob`"
      
      This reverts commit 0f9249c9.
      
      Reverted because this wasn't warning in custom jobs and therefore
      applications may have not seen the deprecation. We'll need to fix the
      deprecation to warn for custom jobs so that applications can migrate.
      336a07b9
  15. 12 5月, 2020 1 次提交
  16. 08 5月, 2020 1 次提交
  17. 05 5月, 2020 2 次提交
  18. 01 5月, 2020 1 次提交
    • A
      Add mention to shared section in `config_for` docs [ci skip] · 8bae32ba
      Alberto Almagro 提交于
      37913 added the possibility to deeply merge configurations by grouping
      them within a shared section. This powerful alternative was not reflected
      in any documentation, which made my team think it was not possible until
      I found out this feature after looking at the source code.
      
      This patch reflects this change in the documentation so that it is
      easier for other developers to know about this behavior.
      8bae32ba
  19. 22 4月, 2020 1 次提交
    • J
      Add web_image_content_types config option for ActiveStorage · 2a12b723
      JvH 提交于
      Add `config.active_storage.web_image_content_types` to allow applications
      to add content types (like `image/webp`) in which variants can be processed,
      instead of letting those images be converted to the fallback PNG format.
      2a12b723
  20. 17 4月, 2020 1 次提交
  21. 12 4月, 2020 1 次提交
  22. 06 4月, 2020 2 次提交
  23. 04 4月, 2020 1 次提交
  24. 30 3月, 2020 1 次提交
  25. 11 3月, 2020 1 次提交
  26. 16 1月, 2020 1 次提交
    • C
      Allow ActiveSupport deprecation warnings to be configured as disallowed · 10754f79
      Cliff Pruitt 提交于
      This allows deprecation messages to be matched by substring, symbol (treated as
      substring), or regular expression. If a warning is matched, the behaviors
      configured for disallowed deprecations will be used. The default behavior for
      disallowed deprecation warnings is `:raise`.
      
      Also adds `ActiveSupport::Deprecation.allow` for thread-local, block level ignoring of deprecation warnings which would otherwise be disallowed by ActiveSupport::Deprecation.disallowed_warnings.
      10754f79
  27. 08 1月, 2020 1 次提交
    • G
      Delayed middleware delete does not allow move operations · 40fc1651
      Genadi Samokovarov 提交于
      While trying to fix #16433, we made the middleware deletions always
      happen at the end. While this works for the case of deleting the
      Rack::Runtime middleware, it makes operations like the following
      misbehave.
      
      ```ruby
      gem "bundler", "< 1.16"
      
      begin
        require "bundler/inline"
      rescue LoadError => e
        $stderr.puts "Bundler version 1.10 or later is required. Please update your Bundler"
        raise e
      end
      
      gemfile(true) do
        source "https://rubygems.org"
      
        git_source(:github) { |repo| "https://github.com/#{repo}.git" }
      
        gem "rails", github: "rails/rails"
      end
      
      require "action_controller/railtie"
      
      class TestApp < Rails::Application
        config.root = __dir__
        secrets.secret_key_base = "secret_key_base"
      
        config.logger = Logger.new($stdout)
        Rails.logger  = config.logger
      
        middleware.insert_after ActionDispatch::Session::CookieStore, ::Rails::Rack::Logger, config.log_tags
        middleware.delete ::Rails::Rack::Logger
      end
      
      require "minitest/autorun"
      require "rack/test"
      
      class BugTest < Minitest::Test
        include Rack::Test::Methods
      
        def test_returns_success
          get "/"
          assert last_response.ok?
        end
      
        private
          def app
            Rails.application
          end
      end
      ```
      
      In the case ️  the ::Rails::Rack::Logger would be deleted instead of
      moved, because the order of middleware stack building execution will be:
      
      ```ruby
      [:insert, ActionDispatch::Session::CookieStore, [::Rails::Rack::Logger]]
      [:delete, ::Rails::Rack::Logger, [config.log_tags]]
      ```
      
      This is pretty surprising and hard to reason about behaviour, unless you
      go spelunking into the Rails configuration code.
      
      I have a few solutions in mind and all of them have their drawbacks.
      
      1. Introduce a `Rails::Configuration::MiddlewareStackProxy#delete!` that
      delays the deleted operations. This will make `#delete` to be executed
      in order. The drawback here is backwards incompatible behavior and a new
      public method.
      
      2. Just revert to the old operations. This won't allow people to delete
      the `Rack::Runtime` middleware.
      
      3. Legitimize the middleware moving with the new `#move_after` and
      `#move_before` methods. This does not breaks any backwards
      compatibility, but includes 2 new methods to the middleware stack.
      
      I have implemented `3.` in this pull request.
      
      Happy holidays! 🎄
      40fc1651
  28. 02 1月, 2020 1 次提交
  29. 28 12月, 2019 1 次提交
  30. 23 12月, 2019 1 次提交
  31. 18 12月, 2019 1 次提交
  32. 13 12月, 2019 1 次提交
  33. 11 12月, 2019 1 次提交
  34. 07 12月, 2019 1 次提交
  35. 03 12月, 2019 1 次提交
  36. 24 11月, 2019 1 次提交
  37. 11 11月, 2019 1 次提交