Rename mailer module to mailer_symfony and avoid namespace conflict with contrib mailer module

The contrib module is currently not compatible with D11 and also has only 34 sites that report using it.

When the mailer ceases to be experimental, do we still need a Core module? If so, then I feel we should keep the name "mailer". If this is only a temporary module, then one option is to give it a name that indicates the temporary status.

Maintainer of the mailer contrib module here.
The D11 version of this module is being worked on and will be available in the future.

Move the module
I am willing to move the module and rename, document, ... if the decision is made to keep the name of the core project.

Alter the core version
I prefer this option as this will be less work / effort for all people impacted.
I could move the project, and document this, but it would always be a pain for users of the contrib mailer module while updating existing websites.
As this is an API module the needed changes would involve altering the use statements of all mailer plugins in all projects using this module.

As potential errors would occur when updating Drupal Core and not mailer we can't expect people to have read the documentation / release notes of the mailer module. It's an option to place a note in the core release notes, but that would be weird for a module with only 34 reported installs.

Do nothing
If the plan is to only keep the core module in experimental phase, and then move the code to the core framework, this could potentially never impact any website. If the users of the contrib mailer module keep the experimental core module disabled and do not use the new functionality before frame work inclusion.

I was wondering if we sould also alter the module name? This is still 'Mailer' It might be clearer if the name is Mailer Symfony

Services are not yet renamed (mailer_symfony.services.yml)
- 30: Drupal\Core\Mailer\Transport\SendmailCommandValidationTransportFactory -> Drupal\Core\mailer_symfony\Transport\SendmailCommandValidationTransportFactory
- 38: Drupal\Core\Mailer\TransportServiceFactory -> Drupal\Core\mailer_symfony\TransportServiceFactory
- 41: Drupal\Core\Mailer\TransportServiceFactoryInterface -> Drupal\Core\mailer_symfony\TransportServiceFactoryInterface

Mailerhooks:
25: The Mailer module provides an experimental -> The Mailer Symfony module
25: nline documentation for the Mailer module< -> Mailer Symfony module
26: Should the link change?

src/Kernel/TransportTest.php
30: If we alter the name, these comments should mention mailer_symfony

I think we explicitly don't want to do use Symfony there, if they didn't like Symfony Mailer in contrib, then they also wont' like "Mailer Symfony". It's the underlying system, but the current direction is that we will provide our own API on top of it, just like Drupal as a whole is built on top of some Symfony components.

The name is much easier to change than the machine name, so there I think we could use Experimental, so I'd go with "Experimental Mail(er) API". We can change once it's no longer experimental.

We are also not renaming the Core component, there is no conflict here and things like "mailer DSN" is a concept of the Symfony Mailer component, not the module name.

What about just mail for the core module?

https://www.drupal.org/project/mail exists but seems to be abandoned, we could ask the maintainers whether we could take over the namespace?

And I am kind of tempted to see if we can move all mail related code into a module eventually - not all sites need or want mail, and it forces separation of concerns.

The only commits since 2017 are Drupal 9 and 10 compatibility fixes, there are no published compatible releases and it is "seeking new maintainers", next week I will contact the maintainers and ask.

Mail module is my project for a new config-based mail system in core.
I've not managed to get any traction for getting it into core, but it's not abandoned.

https://www.drupal.org/project/email is a D7 only module that was merged into core for D8.

Trying to find something short and simple here, because I think mailer_symfony is both long-winded and could easily be confused with symfony_mailer.

@longwave in the meeting at 03/09/25 mails or email were also suggested.
https://www.drupal.org/project/drupal/issues/3544898#comment-16256380

Mails is still available, emails is indeed an unsupported d7 module.
mailer_symfony was selected as the module will provide a wrapper around the symfony_mailer component.

mailer module in core is just about sending emails, not at all about configuring / translating / altering / etc?

If so, its name should reflect that it's low-level.

What about using symfony_mailer, since the project page for that says it'll be retired after D11?

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

> We are trying to avoid a namespace conflict with an existing contrib module. Claiming the namespace of another existing contrib module doesn't seem to make much sense.

One says it's to be retired, the other does not.

Removing tag as this was dropped from 11.3.x.

Maybe dumb question won't this cause issues if mailer is installed?

Rebased so no credit there.

Since this one has been sitting for a while I don't mind marking, I also verified my own comment in #32 (which was the same as #4) for the mailer module.

But know there was back n forth around the name, personally I think symfony in the name makes sense since that's what the module is centered around. Mailer sounds right but seems very vague.

@longwave @catch  and I have discussed a new idea that involves completely removing the module:

• Move the test modules to system
• Move the tests to core/tests
• Delete the help hook
• Move the services to core/experimental/mailer.services.yml (name and location up for discussion)
• Add a helper to tests to set the the container yamls in settings to make it simple to enable.

For local development it becomes a case of making a change to your settings.php to enable the services.

Implemented #36 - it looks good to me. There's a way to add it to the container build for both...

Kernel tests

  /**
   * {@inheritdoc}
   */
  public function register(ContainerBuilder $container): void {
    $yaml_loader = new YamlFileLoader($container);
    $yaml_loader->load($this->root . '/core/experimental/mailer.services.yml');
  }

Functional tests

   */
  protected function prepareSettings(): void {
    parent::prepareSettings();

    // Load the mailer.services.yml file.
    $filename = $this->siteDirectory . '/settings.php';
    $line = "\n\$settings['container_yamls'][] = '" . $this->root . "/core/experimental/mailer.services.yml';\n";
    file_put_contents($filename, $line, FILE_APPEND);
  }

Realised we can do this in an even nicer way by providing a trait for kernel tests and modules that wish to experiment to use... and we can use it in our own test module... so

Kernel tests

Add in the trait Drupal\Core\Experimental\MailerServicesTrait

Functional tests

Add core_mailer_services_testto the modules list.

Contrib experiments

Add a service provider (a class in src/ModuleNameServiceProvider.php that implements ServiceProviderInterface) and use the Drupal\Core\Experimental\MailerServicesTrait.

Local dev

Add $settings['container_yamls'][] = $app_root . '/core/experimental/mailer.services.yml'; to your settings.php

@znerol and that would involve change to the test system and this involves none and provides a simple way for contrib to opt-in too.

1. Kernel tests could just enable the test module - but there's no need - the same trait just works fine - so why do that?
2. Just i noticed that - at best this feels like a follow-up but this is follow-up material and not necessary to solve here.
3. I don't think that we should be shipping this in the sites directory. We've never shipped an experimental services file before this is a new pattern I don't think there an really any expectations to meet here.

Can't kernel tests install core_mailer_services_test too? Then we don't need the trait and have one unified way of setting it up.

Probably too early to think about this but if we do #3111008: Use native Symfony YamlFileLoader and later enable imports in YAML then we could split up core.services.yml into more manageable chunks. Mailer could just be one of those chunks, that isn't included by default, but one day we just switch it on by including it globally.

@longwave yes they can but the trait is really nice for any contrib that wants to depend on the services and explore using them. I'm fine to drop it and then contrib can just copy the service provider from the test module and be done...

Removed the trait - now everything is using the test module to add the services to the container. And any contrib module can just add a service provider in the same way.

#51 has great points... tagging for the CR update. I think it is okay to leave the policy thing to a follow-up that we should create now. Will do that later today. FWIW option B would require editing all those pages too. So I've copied the list to the issue summary to ensure it is not lost when we merge.

I really like option C.
It was always the plan to remove the module after acceptance into core. This approach eliminates the overhead of a later transition and the risk of bugs during that phase.
The services being in the right place from the start will make it easier for contrib to start supporting the new functionality when not stable.
Services are namespaced so this approach also removes the naming conflict with contrib modules.