Simple examples to show the possibilities?

+1 for me.

As I see I the email attachment is not supported yet for all modules.
I read about people who was able to send attachments in simplenews newsletter, but it's uncomplete. I don't know how to achieve this in webform module, which basically work with Symfony Mailer without any particular configuration. I guess that this is part of the to-do list, but any help/documentation to get it work would be much appreciated.

+1

What is "Policies"? What does it do? I added some elements, but no clue what I just did. Email sent from my site still looks like standard Drupal plain emails.

Need twig examples.

Need examples.

Much of the documentation is written for the back end. I'm just an average jo that want's what's written in the first sentence on your project page: "A new mail-system based on the popular Symfony Mailer giving full support of HTML mails". Tell me how to get there.

Please help.

I added this to the beta release plan. Hopefully someone can help out with it soon. I'm the developer/maintainer but I can't do everything myself so it will depend on the community.

Thanks, AdamPS for your hard work. This is a much needed module for everyone getting a little dizzy trying to figure out the SMTP module now.

I can confirm that SMTP transport works for me.

I think I've got Policies figured out, sort of. I've uninstalled Alpha and installed Beta so that I can play with it more (later).

Sorry, I don't code else I'd help with it. This module is so import to my needs that I'm running Beta on my live site. At the very least it appears that my transports will satisfy getting [plain] mail sent out. Like I said, I'll play with Policies later.

Also, the name "Back-capability" is/was confusing. I didn't install it initially because I misunderstood what it was. Once I did install it I seen that it gave Policies access to my email types, contact, user, I forget the others. I think, now, if I re-read your documentation is will make better sense.

Again, thank you1

Adam, I am very happy to add a step-by-step guide to the documentation to help simplenews users migrate from their current dependencies on Mail System and Swiftmailer based on my (as yet unsuccessful attempts) of doing so. (Many thanks for what you’ve done on this already)

At the moment, however, I keep stumbling upon things I don’t understand because naturally you haven’t had time to describe the process. I could do with some help with the initial couple of steps from which I can discover by experimentation. Here’s what I’m looking to find out either by experimentation or through the issue queue:

1. What do you mean by “transport settings” other than the sendmail setting in php.ini
2. When setting should (fpm’s) php.ini what should have here:
   

   [mail function]
   ; For Unix only.  You may supply arguments as well (default: "sendmail -t -i").                                                                                           
   sendmail_path = /opt/mailhog/mhsendmail
   

   People testing the migration from Mail System and Swiftmailer will quite likely want to test their emailing with mailhog

3. You mentioned that a simplenews setting mail.debug should be switched off. I cannot find it in either simplenews’s config YAML (there is a lot!) or its GUI
4. In which directory is Symfony Mailer looking for the TWIG templates used to construct the html of emails?
5. How to specify the css library used to format the html of emails .You already answered this one in response to a previous issue.
6. What are the naming conventions for TWIG templates and theme preprocess functions?
   I can answer these myself by inspecting in mailhog the html coming through TWIG debugging output … providing I can get as far as getting my simplenews messages to reach mailhog!

Great thanks for the offer. I'll give quick answers as best I can without taking the whole time to write the documentation myself😃 - sometimes you'll need to work a bit to figure it out.

1. /admin/config/system/mailer

2. The symfony mailer library supports some 3rd party transports but unfortunately not mailhog. You can alter the sendmail command. You can't yet do this in the GUI for SMTP transport, but you could with DSN transport. See #3256740: Add options to SMTP transport.

3. Correct it is not present in the GUI. So it can only be on if enabled with drush or something similar.

4. The template directories are the same as for any other Drupal template such as node.html.twig.

5,6. See documentation.

OK Adam. One step at a time.

An Administrator going with the the default, the Native transport setting in Symfony Mailer’s settings GUI: From what I read in the Symfony documents, this will use whatever is specified in php.ini’s sendmail_path.
(Side note: I’d need to qualify this as a typical Linux system will have several php.ini’s e.g. take care to choose the correct /etc/php subdirectory for PHP version; cli; apache; fpm)

Qs:

1. Can you confirm that Symfony Mailer treats this native transport as a black box or does it have an opinion about php.ini >> sendmail_path i.e. if the sendmail_path was sending mails before installing Symfony Mailer, it should so be doing now that Symfoner Mailer is configured with Native Transpport
2. OR … When you say “SM supports 3rd party transports” does this mean SM’s Native Transport will override what it finds in php.ini >> sendmail_path
3. Also, to confirm what I assume: There is a lot of stuff in the Symfony Mailer docs about .env where the DSN Potocol is specified … which I assume your Drupal module is there to address and whose settings a Drupal Administrator need not be directly concerned

Can you confirm that Symfony Mailer treats this native transport as a black box

Yes.

SM supports 3rd party transports

The Symfony Mailer library supports 3rd party transports. This module knows nothing about them.

.env where the DSN Potocol is specified

With this module, then you can add a transport of type DSN (url = admin/config/system/mailer/transport/add/dsn). The page has a field for "DSN for the Transport" with a documentation link. When that documentation link explains to put something in .env, instead type that same thing into this DSN field.

Hi iainH
I tried to setup Symfony Mailer with simplenews myself and I kept some notes.
Hope this helps as input for your guide. In my example I used mailtrap instead of mailhog
------------------------

Install the module with composer or the normal way https://www.drupal.org/docs/extending-drupal/installing-modules
Enable the modules
"Symfony Mailer" and also "Symfony Mailer Back-compatibility"

Note that enabling the "Symfony Mailer Back-compatibility" sub-module is important because simplenews and most drupal modules are still only level 2 compatible
see explanation is
https://www.drupal.org/docs/contributed-modules/symfony-mailer-0/support... or
https://www.drupal.org/docs/contributed-modules/symfony-mailer-0/feature...

Then go to the admin page /admin/config/system/mailer to create an SMTP transport
select SMTP in transport type and then press "Add transport"
You may use mailtrap.io as a test smtp server

Then make sure that you make this new transport the default one here /admin/config/system/mailer
and also make sure you do NOT have installed and enabled competing modules like these 2 popular ones
https://www.drupal.org/project/mailsystem or
https://www.drupal.org/project/smtp

Since the Symphony Mailer does not yet have a test email function you can try to.
Simplenews should be also now working via Symfony Mailer without any other configuration required

I try to rewrite a simple custom module based on symfony mailer module, which just has to send a hard coded html email via my module controller - without want to give someone else the opportunity to change anything with policy etc.
Is this possible and how?

And what are "common_adjusters"? Are these the email params?

If this module shall be used widely, it needs URGENT more documentation.

The documentation https://www.drupal.org/docs/contributed-modules/symfony-mailer-0/feature... claims what could be possible, but don’t show and don’t explain.

PLEASE provide some simple examples for basic functionality on level3.
If it is easy as claimed, please show.

• - Give a minimal hello_world example what is needed to send an email (on level3 inside of a new module).
• - Give another example with attachment, using of templates etc.

More on question 6 from comment #7:

For modules (not themes) previously using hook_preprocess_swiftmailer() to add css libraries for inlining, what is the equivalent procedure to add a module library and have its css inlined using symfony_mailer?

Unofficial answer, and untested but a few ideas to try:

1. Specify which theme you want to use in your policies, eg "mytheme".
2. add the "email" library to mymodule.libraries.yml following the instructions in getting started
3. add an empty "email" library to mytheme.libraries.yml with a dependency on mymodule/email

If that doesnt work (and I'm guessing might not)...

4. remove the module library dependency from the theme library, add an empty "css/mail.css" in the theme library.
5. alter the theme library using https://api.drupal.org/hook_library_info_alter in mymodule.module to swap out the path to the css file to point to the one from the module folder.

Argh, I hope not. The theme and module are completely independent of each other. It should be possible for a module to send mail and inline its own css without relying on any theme.

What I need is, how to natively create an email with this module directly. Like:

email_entity = $email_factory->newTypedEmail('MYMODULE', 'my_awesome_email_subtype');
$email_entity->setParam('user_display_name', $user_recipient_name);
$email_entity->setSender($email_from);
$email_entity->setSubject($email_subject);
$email_entity->setTextBody($email_body_plain);
$email_entity->setTo($user_recipient_email);
$operation_status = $email_entity->send();

Unfortunately it doesn't work.
I get "Call to a member function newTypedEmail() on null"🙈

Or how can I do the "native implementation" in the docs it's called "Level 3" correctly?

what is the equivalent procedure to add a module library and have its css inlined using symfony_mailer?

This seems to be a completely general Drupal question - how to alter a theme library in a module. Try hook_library_info_alter()

how to natively create an email with this module directly

It's a good question- I wrote a page for it: https://www.drupal.org/docs/contributed-modules/symfony-mailer-0/develop...

I just installed 1.2.0. Thanks for all of the work to get this to a stable release.

I've read the documentation I could find, and still have the legacy Mail System, Mime Mail, and Swift Mailer modules installed in addition to Drupal Symfony Mailer. While reviewing the *All* policy and enabling the "Emulate swiftmailer" option, I noticed this description:

Emulate wrapping from the swiftmailer module. This is intended as a short-term workaround and you should migrate to the new template when possible.

I can't find any documentation that describes how to "migrate to the new template". Help, please?

If there are instructions available to configure sending email with attachments I'd appreciate a pointer to that, too.

I can't find any documentation that describes how to "migrate to the new template". Help, please?

What we have is here https://www.drupal.org/docs/contributed-modules/symfony-mailer-0/migrati....

If there are instructions available to configure sending email with attachments I'd appreciate a pointer to that, too.

If your attachments worked with swiftmailer then they should also work here. It's the module that sends the mail that sets the attachment.

There's not yet a GUI - see #3261807: [META] Attachments support for status.

Am I correct in assuming that some of these instructions are intended for module developers, and some are intended for site administrators? For example, "migrate to the new template" appears to be a developer instruction. There's no GUI for it that I can find so there's nothing I can do as a site administrator, but I understand how a module developer would need to switch if their module is sending email.

I just did some testing with my existing webform configuration in which email with attachments is sent. It still works just fine, without changing anything, after configuring Symfony Mailer (with import of my Swift Mailer settings) and removing the legacy applications.

One last question: at what point can I (or should I?) disable the "Emulate swiftmailer" option as a site administrator?

Thanks again!

Am I correct in assuming that some of these instructions are intended for module developers, and some are intended for site administrators?

Yes unfortunately it's a bit muddled up, #3342954: Improve the documentation. I'm a developer not a writer😃.

One last question: at what point can I (or should I?) disable the "Emulate swiftmailer" option as a site administrator?

If you only use the GUI, then I guess you never wrote templates or CSS files. SO it makes no difference to you, you can do it immediately.

Thanks @AdamPS for providing Symfony Mailer!

In case it is useful for others, as I played with using Symfony Mailer to create my first custom email using it, I developed a "Hello World" email example module. See here: https://github.com/chipcleary/symfony_mailer_example/blob/main/README.md.

This provides a basic example of how to programmatically define and send custom mail, including:

• Defining a custom EmailBuilder
• Providing and using twig variables
• Providing a mailer policy
• Providing CSS

All of this is already covered in the existing documentation. But it took me some hunting-and-pecking to identify which parts I needed and how to apply it.

Caveats:

• I'm a novice developer and am unfamiliar with Symfony Mailer. I wrote this as I worked through how to create a first custom email. It's only meant to provide a minimal "starterkit" example. It is emphatically *not* authoritative.
• It does not address either of the two examples used in the issue statement, which are a step more advanced (theming system emails, sending attachments).

@chipcleary Nice example thanks

@chipcleary Your example is similar to TestEmailBuilder from this module, but better😃. I would like to bring the extra parts into here.

1. libraries.yml
2. CSS file
3. A variable - e.g. the date (a bit more 'serious' than a lucky number😃)

I would welcome a patch.

@chipcleary Thanks a lot

@AdamPS, glad you like it and I'd be happy to provide a patch! I should be able to provide it by the end of the week.

@AdamPS, here's a stab at the patch. Happy to make modifications.

I extended the email to include:

• A header and footer, which use custom CSS for formatting.
• A "day" variable which captures day of the week.

To implement this, I modified:

• symfony_mailer.libraries.yml
• TestEmailBuilder.php
• symfony_mailer.mailer_policy.symfony_mailer.test.yml

And I added test.email.css.

Great many thanks, I'll take a look soon

It's good thanks, please can you just tidy up some details:

1) TestEmailBuilder
I like that you added clear explanations to help anyone using this file as an example to copy. Please can you avoid splitting a line of code with comments, and instead put the comments first as separate bullet points, then $email->addLibrary('symfony_mailer/test'). Also check the coding standards, keep to max length 80 characters.

2) symfony_mailer.mailer_policy.symfony_mailer.test.yml
I have made the yml files easy for a human to read, to help people using it as an example. Please keep the syntax value: |- then use a separate line for each paragraph and, for consistency, keep with the single quotes around the subject.

3) test.email.css
The initial comment should contain a @file annotation and remove the 2 lines with only a star.

4) Please add an extra line into TestEmailTest to check that one of the styles is present. Use a comment to say the style comes from test.email.css.

Helpful feedback, thanks. Here's an updated patch. Would you be able to check in particular whether I've addressed #4 appropriately? I'm least confident about that one.

Great it looks good. I changed it slightly, hopefully it fixes the tests.

Super, thanks @AdamPS. Let me know if there's anything else you'd like.

It's good thanks. I've left the issue open because there's still more that could be done.