[meeting] 2026-01-07 core mailer beta planning

Changes discussed in #3564527: [meeting] 2025-12-17 core mailer dev meeting were incorporated into the current MR in #3539651: Introduce email plugins. Most notably mail plugins can now be defined either in a YAML file or using the #[Email] attribute. It was briefly discussed whether this could hamper discoverability. A developer looking through the code of a module now has to search in two places to find plugin implementations (the {module}.email.yml file and in src/Plugins/Email).

The plugin discovery code was copied from layout manager but without the annotation compatibility. It looks like it works, but it needs to be checked by somebody more familiar with the plugin API. Another area which needs a reality check is multilingual sites.

In order to verify the viability of the approach, the update email was converted to a plugin in a separate branch. The current API works quite well for the email body. This isn’t the case for the email subject. In order to set that from within the plugin implementation, it is currently necessary to override getHeaders(). Maybe there is a way to make it more convenient for plugins to set the subject.

The same situation exists for the recipient and maybe some other headers.

The participants also discussed how third-party code would change message headers (see EmailManager::build()). If a custom or contrib module wishes to change the subject of a core email, it would need to do that directly on the Symfony email object from within hook_email_presend - or alternatively from within hook_email_prerender. In the latter case, the hook implementation would have to operate on the Symfony email object in the context - which seems to be a code smell.

It looks like this problem can be fixed if the headers would be part of the alterable data passed into the prerender hook. In that case, instantiation of the Symfony email object could be moved to a place after body rendering.

Another area which needs closer examination is the bubbleable render metadata. This code was adopted from earlier prototypes but it is currently unclear what it does and whether it still works as intended.

We briefly touched on future work which probably will need to be done after the first patches landed. Especially CSS inlining, attachments, and embedding images. Several contrib modules implement those things in different ways.

We talked about strategies to speed up the development and tighten the feedback loop a bit and decided to move the technical discussions to the #symfony-mailer channel on Drupal slack.

Next planning meeting takes place February 4th 2026 at 4PM UTC+1.