The Rails documentation uses the `:include:` directive to inline the
README of the framework into the main documentation page. As the
README's aren't in the root directory from where SDoc is run we need to
add the framework path to the include:
# :include: activesupport/README.md
This results in a warning when installing the gems as generating the rdoc for the gem is run from the gem/framework root:
Couldn't find file to include 'activesupport/README.rdoc' from lib/active_support.rb
The `:include:` RDoc directive supports includes relative to the current
file as well:
# :include: ../README.md
This makes sure it works for the Rails API docs and the separate gems.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
Fixes https://github.com/rails/rails/issues/48477
Using forms inside emails is not common, but it's possible, and it's also possible to share views between controllers and mailers. Currently if a controller sets a `default_form_builder` that's different from the global config, mailers that use the same views will not default to the same `FormBuilder`. To fix this, this PR adds a `default_form_builder` method for mailers that does the same thing as its controller sibling.
The `Type` class was introduced in https://github.com/rails/rails/pull/23085
for the sole purpose of breaking the dependency of Action View on Action Dispatch.
Unless you are somehow running Action View standalone, this is actually
never used.
So instead of delegating, we can use constant swapping, this saves us
a useless layer.
Ultimately we could consider moving `Mime::Types` into Active Support
but it requires some more thoughts.
Currently when opening the main framework pages there is no introduction
to the framework. Instead we only see a whole lot of modules and the
`gem_version` and `version` methods.
By including the READMEs using the `:include:` directive each frameworks
has a nice introduction.
For markdown READMEs we need to add the :markup: directive.
[ci-skip]
Co-authored-by: zzak <zzakscott@gmail.com>
* Remove Copyright years
* Basecamp is now 37signals... again
Co-authored-by: David Heinemeier Hansson <dhh@hey.com>
---------
Co-authored-by: David Heinemeier Hansson <dhh@hey.com>
The `deliver_later_queue_name` is already configurable on ActionMailer::Base,
however the value is inherited by all subclasses. Use a class-inheritable
attribute instead, so that subclasses can override.
Refs:
- https://github.com/rails/rails/pull/18587#issuecomment-324975192
This commit adds `ActionMailer.deprecator` and replaces all usages of
`ActiveSupport::Deprecation.warn` in `actionmailer/lib` with
`ActionMailer.deprecator`.
Additionally, this commit adds `ActionMailer.deprecator` to
`Rails.application.deprecators` so that it can be configured via
settings such as `config.active_support.report_deprecations`.
These classes are relatively small, however they include lots of
modules as helpers. And if any of the included module hold constants
including it cause the global constant cache to be invalidated
which is really bad for performance.
So when eager loading is enabled we create all the possible classes
as part of the application boot.
details_cache_key already references Template::Types.symbols and view
resolvers cache based on default_formats and other values. This
previously wasn't an issue because no views had been looked up before
this was set. Now that we are building a regex from the values of
Template::Types.symbols we need to clear cache after changing this
setting.
This reverts commit 0f9249c93f402d276730fcfaba1ed1b876ee7c26.
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.
* Eager autoload mail gem when eager load is true
We had a production issue where our Sidekiq worker threads all became
deadlocked while autoloading a file within the mail gem, required via
ActionMailer, despite setting our Rails applicaiton to eager load.
`Mail.eager_autoload!` exists and works great, ActionMailer just doesn't
call it during eager loading. Adding it to the ActionMailer Railtie's
eager_load_namespaces takes care of calling `Mail.eager_autoload!`
during the `eager_load!` initializer.
* 'Mail' isn't defined yet, use before_eager_load instead
* Make sure mail is loaded
* Move eager load of Mail into ActionMailer.eager_load!
[Samuel Cochran + Rafael Mendonça França]
Without this, Action Mailer doesn't work like it used to on version 4.
The following snippet fails since version 5:
> require 'action_mailer'
> ActionMailer::Base
NameError: uninitialized constant ActiveSupport::Rescuable
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.
This is a private place to put those AS features that are used
by every component. Nowadays we cherry-pick individual files
wherever they are used, but that it is not worth the effort
for stuff that is going to be loaded for sure sooner or later,
like blank?, autoload, concern, etc.
