Action to send HTML mails

I tried using the patch in #2 and ECA to send an HTML email. There is a new action in ECA - Send HTML email - but still comes in plain text.

Wonderful #11 got it working with eca - thank you so much - (I had to delete mailer a symfony mailer sub policy relating to symfony mailer - but I now can send html Mail via eca - thanks

Patch in #11 works for me. A new ECA Action to send html mail is available and works.

To commit this patch to this module then the comments from #4 need to be done. If you want to commit to ECA module then you can do it how you like😃.

I still find this "simplified action plugin" intriguing and wonder if it wouldn't be valuable for some use cases (not only for ECA), where a counterpart for Drupal core's mail action plugin with low complexity still benefits from the power of symfony_mailer.

One of my goals with this module is to nudge developers to remove their private code to edit policy elements and instead use the standard Mailer Policy GUI.

If there is a demand for a lower complexity version, then I would propose to allow that with an option in the framework. It could be renderEntityPolicy($simplified = FALSE), and the simplified version could include only the "common_adjusters" from the annotation. This still might use AJAX if one of the adjusters was complex.

One of my goals with this module is to nudge developers to remove their private code to edit policy elements and instead use the standard Mailer Policy GUI.

Well, the main focus of ECA is not the GUI, but automation. The GUI only comes into play where site builders are setting up the rules for those automations. Once that's done, the GUI is turned off, and the ECA processor runs them whenever appropriate.

When it comes to sending emails, the requirement is that the ECA model builds all the properties (to, cc, bcc, subject, body, attachments, etc.) that are necessary for an email and then wants to trigger symfony_mailer to send that email with fully dynamic properties. So, that would require a profile that accepts variable values for each of its properties.

So, that would require a profile that accepts variable values for each of its properties.

VBO uses dynamic actions, and it seems that other action types in core work dynamically. So I feel that we should allow the same. The configuration form anyway contains a Mailer Policy editor GUI which VBO would presumably automatically show. Currently that editor works by saving its values to an entity, however I hope that somehow we can extend it to be dynamic. It seems to me that we'd end up with HtmlEmailAction->execute() being called with $this->configuration containing a MailerPolicy or perhaps a configuration array that can be used to call MailerPolicy::setConfiguration().

I can see two options for ECA to use your own static form/GUI:

1. Use the action in this module, and manipulate the properties you have to match the configuration array of MailerPolicy.
2. Create a separate action in your module, which could likely reuse the EmailBuilder from this module

These would probably work however neither of these would be the "official supported" way of doing things (which is of course to use the official Mailer Policy GUI) . The discussion of ECA non-standard options is probably better done in a separate issue within ECA.

I find it helps to keep each issue for one thing, so I raised ✨ Enhancements to Email Policy embedding Active . If the changes to BodyEmailAdjuster are needed let's do them elsewhere also, maybe along with 📌 Safeguard against missing policy config entries Closed: cannot reproduce which seems similar.

I now understand why we need $this->configuration['action'] in HtmlEmailAction::execute() as the action entity is apparently not reachable from here. However it would still seem better if possible to avoid writing this value to the database, and instead somehow insert it when the action entity is loaded.

After #3347010 this function could perhaps look something like this:

if ($this->configuration['action']) {
  // As in patch
}
else {
  // Configuration from configuration form is for a Mailer Policy that was never saved.
  $policy = new MailerPolicy()->setConfiguration($this->configuration);
  $action = new HtmlEmailAction();
  $this->emailFactory->sendEntityEmail($action, 'action', $entity, $policy);
}

Happy to keep this on topic, just one last question in general as ✨ Enhancements to Email Policy embedding Active is on a GUI approach. Is there a chance to also talk about an API approach? I.e. making symfony_mailer available for other modules without them having to be GUI related? If so, that would then have to be another separate issue.

I.e. making symfony_mailer available for other modules without them having to be GUI related?

When I say "Email Policy embedding" I mean embedding one form within another, so it's entirely a GUI feature.

However in general the idea sounds good yes. I can't really say more without a specific request for a particular API function. Please go ahead and raise an issue.

I'm unclear how to move forward on this issue. Here is a summary where I've got to with the various options and problems.

3 ways of using actions to send email:

• A) ECA
• B) VBO
• C) Core Views UserBulkForm

With the old EmailAction:

• A) I've not tried it, however from your comments it sounds like it works.
• B) and C) I can use the deprecated Action module to create an advanced action, however it is of type "system" so I can see how to use it. In my testing, it doesn't appear on views of user or node.
• It sets tokens for node, but apparently not for any other entity.

With the new HtmlEmailAction my prediction is:

• A) Doesn't work because of 🌱 [meta] Replace property panel with Drupal Form API Active and ✨ Enhancements to Email Policy embedding Active .
• B) Doesn't work because of ✨ Enhancements to Email Policy embedding Active .
• B) and C) This one has type "symfony_mailer" rather than "system" however the problem is likely basically the same.

B) and C) I can use the deprecated Action module to create an advanced action, however it is of type "system" so I can see how to use it. In my testing, it doesn't appear on views of user or node.

I took a detailed look into VBO's logic how it filters out actions. It removes any action that does not match its "type" annotation property with the entity type ID of the used content entity in the view. There is one exception for actions that implement VBO's action interface - these are allowed to set type = "" and they will appear on any view.

So it seems we cannot serve VBO from here, unless we derive one action plugin for every content entity type ID or implement a VBO-specific action using its interface. Which doesn't seem to make much sense for this type of action. And the same is currently happening for core's send email action, which also doesn't appear on VBO views fields because of the non-match of entity type ID.

ECA on the other hand, should already be able to make use of the implemented patch from #31. The module can execute the configured action of an action entity. It will show up under "pre-configured" actions within ECA. It's a detour to get this working with ECA, but at least it's a possible way.

Maybe it's just not possible to serve all needs all at once from here. I'd vote for continuing with the approach from #31 using an action entity, and making sure that it doesn't break other components such as VBO and ECA.

Thanks @mxh. It seems that the existing EmailAction is not especially useful, and of the options we have considered it can only serve ECA. Patch #31 would have the same limitations, plus the ones I mentioned in #41 which force "a detour", plus one more thing I've just noticed:

This module doesn't replace tokens within the 'To' field. NB for Symfony Mailer an address is not a string, it's an array of Symfony\Component\Mime\Address objects which contain an email plus an optional display name. This module expands that class in Drupal\symfony_mailer\Address which can accept a user, Address::create($user).

When creating a Mailer Policy with a 'To' address it uses ToEmailAdjuster which is based on AddressAdjusterBase. It's hard to see any way to accept a token at this point - the necessary parameter context is not even really available.

What can work is for the calling module to evaluate a token such as [node:author] and pass the result to Address::create(). This means the calling module needs code specific to HtmlEmailAction. It sounds like it's possible for ECA, but not in general e.g. for VBO.

In summary, the only way we've seen to use this action is in ECA. If we put the action in this module, we have to do so in a generic way which is inconvenient for ECA. So I wonder, should we instead just move this issue to ECA, then you guys can write it in the most convenient way.

I feel that there are a lot more modules/sites using RulesAction rather Action. I believe may of the problems we face here won't apply to rules actions, which are always saved and aren't locked to a single entity type. See #3265749: Add full integration for Rules module → and #3272131: Add support for Business Rules module → .

Working with Drupal 10.1.4, symfony_mailer 1.4.0.-beta1 and ECA 1.1.4
I don't know if my feedback as an humble site builder can help but the patch created by jurgenhaas in #2 and then corrected by s.sinitsa in #11 does indeed work, while the more elaborate patch in #34 crashed my ECA model test (cf screenshot eca-model-test.png).
In my case, I will need to send several emails depending on the status of a node set by Workflow module and these emails will contain information from tokens that I want to see formatted in HTML and not in plain text (and also attachments if possible).
With patch #11 and its related action "Send HTML Email" (second task on ECA model test), I was able to receive HTML Email (cf screenshot html-email.png) whereas with the basic action "Send an email" offered by default by ECA (first task on ECA model test) I received an unformatted email (cf screenshot standard-email.png).
Is this issue still on?

I think this issue got stuck because we couldn't find a way to use the action without an extra contrib module such as ECA. If it's only useful with ECA then I feel it belongs in that module. If it's going to come in here then it needs to be possible to test and maintain the code without installing other modules.

Thank you for your reply, I understand your point.
Maybe ECA maintainers have an answer for this?

The ECA module maintainers have not followed-up on this, since we (a) don't have that requirement and could at most review solutions provided by other contributors, and (b) there is another module which is built on top of Symfony mailer and works nicely with ECA, see Easy Email → .

That looks really promising, I will definitely try this tomorrow!
Thanks for the advice.

If anybody is willing to explain, then I would be interested to understand what easy email has done to meet the needs of ECA, and how come that isn't possible in this module.

Don't think Easy Email has done anything ECA specific. They just provide an action plugin that's able to send emails, and that action can be used in ECA. But I haven't looked at the code, just used it in a demo to show that it works.

Thanks.

The Core action_send_email_action has type = "system" which makes it hard to use in Core. If we made the action in this patch type = "user" then it would be much more useful I think. For example, you could add it to a view of users and send them all an email.

What does anyone think of that??

Adding possibly related issue, I am not sure. Feel free to remove if it isn't.

Actually not related😃

Just wanted to mention that #31 doesn't work with Drupal Symfony Mailer 1.4.1 but it does with 1.3.2.

@gge

Perhaps try this module instead: https://www.drupal.org/project/symfony_mailer_lite →

For some reason we ended up using symfony_mailer_lite to replace swiftmailer and it is working well so far. Seems to be an easy drop-in replacement for swiftmailer.

> Just wanted to mention that #31 doesn't work with Drupal Symfony Mailer 1.4.1 but it does with 1.3.2.

I'm still using the patch from #11 and it still works with Drupal Symfony Mailer 1.4.1. Are there any disadvantages against the newer patch #31 ?

@FeyP @AdamPS

I tried to apply this patch ( https://www.drupal.org/files/issues/2023-03-07/3332684-31.patch → ), the message is:

Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2023-03-07/3332684-31.patch →

I am currently on on ECA 1.1.6 is Drupal Symfony Mailer 1.4.1. I double checked the patch code in composer.jason file.

Is there any new development on this topic? Do I need to do anything else in addition to applying this patch to get it to work?

Thank you very much! I use ECA to send emails A LOT, so this feature is critical for me, but I am not technical to contribute to the code development. Appreciate any advice!

In case some people are still looking for solutions, I resolved mine this way:

1. install Symphony Mailer Lite
2. in System Mailer configuration, set system to use Symphony Mailer Lite formatter. ECA use the system module to send emails
3. create a custom module. I let chapgpt help me. It took quite awhile for it to realize what is the key until I asked it to check the configuration of webform to send email using Symphony Mailer Lite, and then apply that to system. That works great...so far!

I am using Drupal 10.3, patch #31 can't be applied for ECA 2.0 but #11 works.

But I am getting another error while saving the rules:

action "Send HTML email" (Send HTML Email to Guest): Enter a valid email address or use a token email address such as [node:author:mail].

I used a field value token ([node:field_guest_email:value]) for mail, but its not accepting it. How we can fix it?

This sounds like Drupal Symfony Mail provides their own form validation? If that's the case, I'd say this is not necessary. If the field type is email, i.e. '#type' => 'email', then validation is done by core validation and ECA is prepared for that, even if a token is being used.

The issue is that, the field "field_guest_email", in my case, is not an email field. I see ECA previous/ non html action "send email", do not validate the token as email field. But the new "Send Html Mail" action doing the validation and I can't use/update my old ECA rules.

I have updated the #31 patch with additional adjustments

Same here with #11. It works with ECA2, and also the problem of not being able to use a locally defined token with an e-mail as value.

For now I can hardcode the e-mail address, but it would be great to use a local token instead of hardcode of an entity token.