Add EmailBuilder for Webform

This is currently documented as a restriction of Legacy mode.

I understand your motivation here, but I am reluctant. If we add this one field, then someone else will want another and so on perhaps without end. And the code we add will have restrictions - for example I expect that code will only work for a single reply-to address without a display name.

My preference would be to push forward adding more email builders in the Proxy mode, like you did for UserRegistrationPasswordEmailBuilder. The documentation link explains various advantages, and it is a stepping stone to a native implementation.

What do you think?

Great thanks for your work here.

Also, I've added an extra functionality to cancel the email sending.

I absolutely agree this is a good idea. I have added an issue for it #3262457: Cancel email sending with an explanation of what I think is the right way to do it. Please can you take a look and see what you think?

I've added the new WebformEmailBuilder to the existing merge request.

Great thanks. I suggest we resolve the above issue first then revisit here.

One review comment I noticed in my first quick look: I think it should include a hook_mailer_bc_MODULE_alter() similar to symfony_mailer_bc_mailer_bc_contact_alter() that will set the entity. This would allow configuring policy specific to a single web form.

I would be very interested in your thoughts on #3262540: [META] Use Policy GUI even with back-compatibility please. Webform is a very good example, as almost all of the EmailBuilder duplicates Symfony Mailer policy.

Ah I see what you mean. I never used webform and didn't realise how complex the configuration is.

So the next step here is to integrate #3262457: Cancel email sending and apply the comment from #6.

FYI I have reconsidered on the matter of the legacy email builder if you are interested in that: #3262946: Add support for more headers on legacy emails

Of course let's still keep this new EmailBuilder in any case.

Great thanks

It is not necessary as users can add multiple email handlers (with different body, sender etc.) on each webform. Also, the webform_submission entity is not an instance of ConfigEntityInterface.

I do think it will be useful to allow per-webform Symfony Mailer policy. It has functions not available in webform (transport, theme, skip sending, ...) and also some sites might prefer to keep the policy in a single place.

I'm not familiar with the code, however the entity I had in mind from a quick look was Drupal\webform\Entity\Webform. It's similarly for contact module: the entity is ContactForm rather that Message.

Thank you, Balis and Adam for working on this new feature issue

Testing to apply the MR in a site ( with the back-compatibility module )
But I'm facing the following error, right after applying the 13.patch

The website encountered an unexpected error. Please try again later.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "mailer_transport" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 143 of core/lib/Drupal/Core/Entity/EntityTypeManager.php).

Should this only work when the back-compatibility module is off?

Great thanks for the updated patch. webform is a pretty complex example so it's a very useful testing ground for symfony mailer. I feel very comfortable with the direction this patch is heading - integrating with symfony mailer where possible yet also being pragmatic where needed.

Also, I have setted all the webform variables in the email template. So, from mailer policy, users can override the email body and subject too.

Great idea

Now, the webform sub-types are provided dynamically. Unfortunately, users have to clear all caches after adding/removing webforms/handlers.

I guess that might cause confusion. Perhaps we would ideally use the entity API to do it automatically.

Also see comments in the review. Many thanks.

OK, I think I've got a much better idea.

• I raised #3271395: Re-use policy configuration with "pre-sets". As far as I understand it, this would be equivalent to email handlers, and it's a good idea.
• Then we go back to the "natural" idea that the entity ID is the webform ID. It removes the need for extra code in symfony_mailer_bc_mailer_builder_info_alter().
• Later on it should be possible to apply #3265253: Add policy listings to module entity/settings forms to webform.
• The @todo comment at the top of WebformEmailBuilder can say to remove the concept of email handlers entirely. Also should use Email::appendBodyEntity() instead of setBody().

What do you think??

I hope you don't mind me suggesting that until this is fixed you add a fairly prominent warning on the project page explaining that there are currently compatibility issues with Webform (reply to, cc, bcc etc). Webform is one of the most widely installed contrib modules, and with the expectation that symfony mailer is a straightforward swap-out for swiftmailer, this issue is likely to catch a lot of people out.

the expectation that symfony mailer is a straightforward swap-out for swiftmailer,

Eventually yes. But this module is currently an alpha, and not ready for live use. I realise that people are using it anyway because swiftmailer is unsupported. Possibly many modules won't work, not just webform and there is already a documentation page dedicated to that linked from the project page. I've updated the project page generally to make this clearer.

Since #3262946: Add support for more headers on legacy emails Webform should work much better without this issue. Please can someone test? Currently requires the dev release.

This issue should stay open for the next level, an EmailBuilder will give significant advantages.

However, if a webform has a custom reply-to address the final email has the sender email address as reply-to address.

I can confirm that this issue does not exist with the current alpha 10 release.

Hi,

I am trying to send webform attachment with Symfony Mailer.

So I have created a new MR, rebased against last dev branch to test it.