Correction to project page

@AdamPS, thanks for the heads-up about the trademark issue. I've changed the name of your module in the project description here, and renamed this module just to be safe.

And thanks for letting me know about the inline CSS issue. I have created a follow-up issue to test that functionality on 10.1.

With regard to my description of your module: Does your module now support hook_mail_alter() for emails sent using templates in the module? I believe that it did at one point and that it lost that functionality. I ran into this issue when Reroute Email stopped working on a site of mine in development, and emails got sent from a staging copy of the site. I ended up having to write an Email Builder to re-implement the rerouting functionality. That experience is what I'm referencing in the description.

Looking at the code for Drupal Symfony Mailer this morning, it appears that it does support hook_mail_alter(), but only for emails sent without using the templates (being defined in hook_mail instead). That seems reasonable as a way to support drop-in replacement for Swiftmailer, but I think your module also automatically creates templates or overrides for many of the default system emails, and for some other things like the Commerce order receipt, doesn't it? This potentially means you would need to go in and adjust those for any behavior that was implemented through hook_mail_alter(). Is that right? I'm not totally sure about that, so please correct me if I'm wrong. I haven't tested it recently, and the code has changed a lot. If it's the case now that you can alter all emails sent from the site with hook_mail_alter(), I'm happy to change the description on the project page. Or if you can confirm exactly when that would work, I could make my description more precise.

Thanks again for the heads-up on those issues.

Thanks @zengenuity

I understand that the early versions of Drupal Symfony Mailer had some gaps causing pain to developers. Hopefully now I've fixed them giving good compatibility with swiftmailer (but not 100%) plus many options for upgrading if desired.

Does your module now support hook_mail_alter() for emails sent using templates in the module?

It supports hook_mail_alter() for emails sent with hook_mail(). It doesn't for emails sent directly with the new API, because there's no $message array to alter. This matches the direction being proposed for Core in 🌱 [META] Adopt the symfony mailer component Needs review .

So it doesn't require your module or application to be rewritten if you're upgrading from Swiftmailer, however it does allow you to do so if you want to take advantage of the features of the new API.

I think your module also automatically creates templates or overrides for many of the default system emails

This is a feature, but it's disabled by default (maybe in the very early alpha versions it was automatic?). In v1.3+ there is a configuration page called "Overrides" and you can enable/disable each email type independently. In v1.2 there was a module symfony_mailer_bc that enabled all overrides. I believe that for a while the Commerce kickstart distribution required symfony_mailer_bc so this may have given the idea that overrides were automatic.

I had a quick glance at the code. It looks like you have kept close to swiftmailer, which should be a big help to sites who want to move onto supported code with minimal change. Once this module has a stable release, and the project page has been corrected I would be happy to link it from Drupal Symfony Mailer and swiftmailer. It seems likely that we can then mark swiftmailer as unsupported, people can choose to here or DSM.

I recognise a lot of code I wrote in swiftmailer and Drupal Symfony Mailer and I'm glad it's can be useful here also. It would be nice to have credit/acknowledgement on your project page😃.

I planning to move the transport code into a new project → which can be used with Drupal Symfony Mailer, Core, and here.

Sorry for the delay in updating the project page. It's been a crazy last week.

I just updated the page with a more precise description of when someone would need to rewrite custom code or change modules when using Drupal Symfony Mailer. I also added an acknowledgments section to credit you for the code I ported over in this module.

I saw your new your project yesterday, and I thought it looked interesting. Please let me know when you thinks it's ready to test, and I will try it with a new branch of this module.

This module should have a stable release soon. Maybe in the next week or two. I'm currently running on it on three sites in production, including DrupalTutor.com. So, I think any issues with it now are probably for edge cases, but I'm going to write a few tests to confirm that before I make it stable.

Great thanks.

The updated project page is clearer thanks. Still it's not exactly as I would say it myself, but then I guess I get to say it my way on my project page😃😃. More seriously though - I'll put together a comparison page of the two modules in a place we can both edit, which we could then both of us link to.

The easiest way for the Mailer Transport project would be based on 📌 [PP-1] Add symfony mailer transports to DIC Postponed - it would add a minimal Core service without a GUI that Core, DSM and DSM-L could all use. Then the Mailer Transport project would override that service with the current MailerTransport code.

However Core might well take forever to make progress, so also we could just do our own thing.

Please excuse me re-opening, however I believe it's still confusing/misleading.

In contrast, Drupal Symfony Mailer Lite sends emails using the Drupal core APIs, using the same approach as the Swiftmailer module. It’s designed to be a direct drop-in replacement for Swiftmailer, so it should work with your existing code and other contrib modules you may be using.

This paragraph strongly suggests that DSM would not "work with your existing code and other contrib modules you may be using." In fact it does that well, 1000s of sites are doing exactly that.

When using the templating system in Drupal Symfony Mailer module, your emails will no longer pass through the Drupal core email API, which may require you to rewrite parts of your application or change the modules you use for ones that are compatible with Drupal Symfony Mailer module’s API.

Nobody is required to rewrite anything. If you want to rewrite you application you can, if not then don't. True, if you choose the new API then the old style hooks are not called, that's inevitable, and something to be aware of before choosing the new API. I suggest we should avoid presenting the existence of a new API as a drawback and a reason to choose DSM-L. Actually the new API is an opportunity - an advantage that you can take if you like, or ignore if you don't like - and you would never be worse off because it exists.

===

DSM-L: good swiftmailer replacement for people who want minimal change - the same features, the same limitations, stable codebase
DSM: good for people who want new features and modernisation, and a more dynamic code-base. It's still a drop-in swiftmailer replacement for 90% of sites.

Once swiftmailer finally dies, your module will get plenty of installs based on the above advantages. Plus the existence of your module will likely accelerate the death of swiftmailer.

I've updated the project description.

Many thanks, and sorry for the hassle.

Automatically closed - issue fixed for 2 weeks with no activity.