Problem/Motivation
Part of #1803948: [META] Adopt the symfony mailer component but benefits the current mail system as well. Also see #2621018: Support rendering from a manually specified theme for why we need this no matter how the mail building part is going to look in the future.
Steps to reproduce
Proposed resolution
Implement a mail theme negotiation mechanism following the pattern already known from core page theme negotiation and provide a way to execute a closure inside the scope of the negotiated mail theme.
- Add a
Drupal\Core\MailTheme\MailTemplateId
value object. The mail template id unambiguously identifies the email to be sent in the current mail manager based mail system. In addition it is forward compatible with mail templates of a different kind in the upcoming mail API based on Symfony mailer. - Add a
Drupal\Core\MailTheme\MailThemeManager
with one method:executeInMailTheme(MailTemplateId $templateId, callable $function)
- Add
Drupal\Core\MailTheme\MailThemeNegotiator
which works analogous to theme negotiation - Add
Drupal\Core\MailTheme\DefaultNegotiator
with a low priority which falls back to the configured theme. - Switch the theme before building / sending mails from within
plugin.manager.mail
This is basically cherry-picking from contrib Mailsystem.
Other approaches
Some attempts were made in the past to allow specify the theme to be used for rendering (with no resolution yet):
- #2621018: Support rendering from a manually specified theme
- #3103382: Allow specifying which theme should be used for rendering a render array
The Drupal Symfony Mailer project implemented this functionality in a more flexible way. However, since it is reusing patterns unique to that module, the mechanism isn't easily portable to current core architecture.