Include a recipe to send HTML emails

[mandclu]

People evaluating a modern CMS will expect it to send professionally-formatted emails. Starshot could include a recipe to send emails in HTML.

The Easy Email module could be a good starting point, and works with the ECA email being proposed for comment notifications.

[phenaproxima]

This sounds like it might be a good follow-up to #114.

[jurgenhaas]

@mandclu Shall I add easy email to the recipe that we're building for #99 in #114 ?

[mandclu]

I'm inclined to say we should keep the HTML email as a separate recipe and then require it in the notification recipe. They could both be in the same PR though?

[phenaproxima]

I agree that it should be a separate recipe. If it gets added in the same PR, though, that sounds fine to me. I'd also be okay doing it later.

[jurgenhaas]

Separating this is difficult. The notify ECA model only consists of 1 event and 1 action. The latter is sending the email. And that would be replaced by the other recipe. As a consequence, the notify recipe that we have now, is not doing anything anymore 😄

Having said that, we could provide some sort of "framework" where we have two generic "Send Email" recipes, one that uses the default core mailer, and another one that uses easy email. And all other recipes, that want to send email call the email recipe just like a service, and depending on which one is available will be used.

This sounds a bit complicated, but we could sort this out pretty nicely I guess. It's just so that with easy email, the template which should be used for the email is most likely linked to the task of the recipe that wants to send an email. In other words, each recipe that wants to send email with easy email should provide their own email template.

[phenaproxima]

Well, wait a sec. Can we not create an HTML email recipe that builds on top of the other one? Or vice-versa? Surely we could modify the ECA model via config actions, to change the template. (ECA might have to provide a new config action, which would require a change upstream, but I get the feeling that the spirit is willing.)

[jurgenhaas]

It's more that the way easy email works requires an entire different workflow for sending emails. With plain text emails, there is a simple action where the recipient(s), the subject and the body is provided. That's it.

With easy email that's different. That module requires an email template, which is a bundle for the email entity type in technical terms. Then, when ECA wants to send an email through that, it creates an email entity of the correct bundle, fills the fields of that entity, and then tells the easy email module to send (and optionally also save) that email entity.

The easy email is really powerful and the easiest to use email module that supports html. But it comes with that requirement as described before. So, it's not just a simple replacement for the core email action plugin.

[jurgenhaas]

@mandclu maybe there's a way to simplify the usage of easy email in ECA: we could provide an action plugin in easy_email that combines all the steps that I've described above into a single one, at least for the less complex requirements. If you agree to give that a try, I'd be happy to open an issue for that and provide an MR to show case how that could look like.

[mandclu]

IIRC there is a way to set up Easy Email so it becomes the default email framework. Maybe this approach would be easier than trying to have separate ECA models based on whether or not Easy Email is installed?

[jurgenhaas]

Even then, easy email needs an entity of a specific type, only that can be sent.

[catch56]

I think the underlying e-mail system needs to be figured out first, because it's a nightmare at the moment.

Core does not yet send HTML e-mails.

Up until a year or so ago, SwiftMailer was the main contrib option, but the upstream library is deprecated.

https://www.drupal.org/project/symfony_mailer_lite and https://www.drupal.org/project/symfony_mailer both exist in contrib and are competing.

https://www.drupal.org/project/drupal/issues/1803948 is adopting Symfony Mailer into core but is moving very slowly.

symfony_mailer_lite is less of a jump from core's e-mail system so probably a safer option, but it likely still won't be the same as what we end up with core.

[thejimbirch]

I don't think this should be included in Starshot. Some thoughts from my humble opinion:

1. The idea is that demo platform is meant to allow anyone to spin up a site. To allow them to send html emails from their demo site is a spambots dream. If this recipe is included and we block the sending of email, it would just seem broken.

2. In my experience, there isn't much need for html email from Drupal. Drupal should be used for transactional emails (lost password, new account, etc). Any emails that would need html emails should be handled by services that allow for the safe and secure management of personally identifiable information (PII).

While I agree that such a recipe should exist to define best practices and make reusable/shareable functionality, I don't think it should be included in Stashot.

[znerol]

Shameless plug. I believe there is a chance that mail gets a fair bit saner in Drupal if we manage to build up some momentum around https://www.drupal.org/i/3379794

Theme/template based HTML mail isn't that far away after the transports infrastructure code landed. I'm ready to help push that forward - wherever it makes most sense (either in starshot or in core).