Changes to EmailInterface

Phases

Previously the language/theme/user switching occurred after build. This meant that most of the work occurs in build with the wrong (not yet switched) settings, so we get emails with the wrong language. Changes:

• Switching occurs before the build phase.
• Calls to Email::setTo() and setTheme() must be made in the initialisation phase.
• Pre-render phase is removed.

Email processing

Previously EmailProcessorInterface was not used on EmailInterface. Classes had to register each function separately and there was no way to alter existing callbacks. Changes:

• Email::addProcessor() is renamed to addCallback() as it relates to callback functions.
• New function Email::addProcessor() that uses EmailProcessorInterface.
• Processors can now be examined and altered using removeProcessor() and getProcessors()

Tags

Previously Emails were identified by a combination of type/sub-type, similar to module/key in the Core mail system. We've discovered that in most cases, this split is unhelpful, and it's more convenient to have a single combined tag, like symfony mailer library. Changes:

• New function Email::getTag() which replaces getType() and getSubType(). The tag is a sequence of identifiers joined by dots. The first should be the module name, then the module can choose how to allocate subsequent values. Passing an integer to Email::getTag() returns a specific single identifier.
• Remove Email::getEntity(), which related to the idea that policy configuration could be specific to a related config entity such as ContactForm. This feature still exists (with the entity type indicated in the annotation for the mailer plug-in), but the entity is handled as a normal variable with getVariables().
• In the mailer override code, in most cases the tag is formed from the previous type.sub_type. However there are some changes ( see table below) – to remove ambiguity, and to make sure the tag starts with the module name. Existing config is migrated automatically on upgrade.

contact.* => contact.user.*
contact_form.* => 'contact.page.*
simplenews.* => simplenews.subscriber.*
simplenews_newsletter.* => simplenews.newsletter.*
commerce_order_type.* => commerce_order.*

Other

• EmailInterface::setBodyEntity() is confusing, as really it is just setting a variable by rendering an entity. Hence rename to setEntityVariable(), and the variable name automatically uses the entity type, rather than always being body. This variable name change affects some of the mailer override configuration, and existing config is migrated automatically on upgrade.
• New convenience function setEntityParam() which automatically uses the entity type as the key, as recommended.
• Rename setTransportDsn() to setTransport(). The value can be either a DSN or the identifier of a config entity..