HTML Email Template Functionality (MIME mail support)

No new features are being added to the 2.x version, so this won't happen there.

I'm actually rather glad this issue was raised though, because I've been thinking about how to solve it for a while now. In the 3.x version, we just now got an HTML version of output in #181077: Printable page for webform submissions. Prior to that (I'm sure you're aware) the "View" versions of submissions were just the same form with values prepopulated. We didn't even have a way to output HTML submissions.

Now however we have a standard mechanism for outputting HTML for any component (it actually uses the same mechanism as printing out e-mails, or rendering the form itself). We can easily create HTML e-mails.

In the 3.x version of Webform, e-mail templates are also built into the interface, so situations requiring custom theming will be much less likely. The only area I know of that might cause some trouble is what to do about differences in templating between HTML and Plain Text e-mails. The only way I can think to solve this is to automatically insert line breaks or paragraph tags into templates, so the exact same template would work for both HTML and Plain Text.

To give you an idea of the interface, this is basically what I'm thinking.

So just by checking the box, appropriate headers would be set, and you could use (nearly) any HTML you wanted in the e-mail template. All tokens would immediately convert to their HTML equivalents instead of the text versions. Like I said above, we'd probably run the "Convert line breaks" filter so <p> tags would be added automatically so the template wouldn't need any changing.

Sorry my screenshot seems to be missing the main token %email_values which prints out the entire tree of the submission, just like when you view an individual submission through the site.

I should also note if you want you can print out individual fields as %email[field_name]. I'm sure with the appropriate CSS you can output the fields exactly as they show up when displayed in Drupal. If you haven't already, I'd suggest you try out the 3.x version (though on a separate installation or after a database backup, you cannot downgrade). In 2.x you have only plain text to work with. If we output the content of the e-mail AS HTML, that is, exactly the way it is output when viewing the submission through the browser; you have much more control over how things look because they are split up into <label> and <div> tags, not like when trying to shoehorn plain text into become HTML. In addition, every component is run through the theme system, so you can theme every type individually if you need more control.

If I submit a patch for 2.x that will do the plaintext-to-html conversion, would you be willing to include it in the 2.x version?

I won't be supporting 2.x with any new features. I anticipate the 3.x version will have a beta here in a few weeks, with the final version about 2 months out, hopefully around the same time D7 comes out.

How about this: I'll commit it to the 2.x version if you port it to both 3.x (for Drupal 6) and to the 2.x version for Drupal 5 (since the 2.x branches are maintained in sync). The support of 3 branches simultaneously is what I'm trying to avoid. If you're willing to put in the effort to make it so I don't have to test this in all 3 branches I'll commit it. Please make patches against the latest CVS version, not 2.9, as there have been other fixes to the code since 2.9 was released.

You don't need a CVS account to get code out of CVS, just use the anonymous/anonymous user and password. See the instructions under the CVS Instructions tab from the Webform project page. http://drupal.org/project/webform/cvs-instructions

Yeah, multiple branches like this is exactly the problem. It's easy to get it working once, but then you have to do it all over again 2 or 3 more times (we'll have 4 branches as soon as I port the 3.x version to Drupal 7). This many branches really isn't manageable, which is why 2.x is deprecated as soon as 3.x comes out and we'll drop support for Drupal 5.

Thanks for the patch presented. It's still useful for reference to see the approach and concept, kind of like a set of instructions for porting.

Subscribing

Subscribing

Super, sounds great gregarios. The advent of 3.0 will end all support for Drupal 5, so no need to backport to previous versions. Thanks!

A list of things that don't seem quite right:

Manually building lists like this isn't common within Drupal, you should be using theme('item_list', $items) when building a UL.

+        $items[] = '<li><span class="title">' . $element[$key]['#title'] . ':</span> ' . $element[$key]['#value'];

Choices affecting the e-mail output should be made on the e-mail configuration screens, not on the component configuration screens. So for example:

+  $form['advanced']['webform_template_output_style']  = array(

This code doesn't belong in select.inc. It should be part of the e-mail configuration form.

Code that is conditional like below should be performed automatically based on the $email variable available in the templates. Again, the configuration option to send an HTML-email should be configurable per-email, basically as shown in comment #1.

+/** if using HTML as your email output type, uncomment the unordered list tags below. **/
+/*  <ul>   */
+

Lastly the "global" HTML e-mail configuration option should simply be a "default" value for the per-email configuration options.

Again, if this isn't ported back to Drupal 5 (which I don't think it should be), this set of changes will only go into the 3.x branch.

I'm definitely planning on adding HTML-email functionality at some point, though hopefully with this issue as a guide it will speed up the process a bit. I'm not at all familiar with MIME mail though, so I'll need to spend some time understanding how that system works.

Thanks a lot for this patch (#10). It's working perfectly and it's just what I was looking for. Saved me a lot of time.
After applying the patch I did some editing to the webform-mail.tpl file and there $form_values is available which contains all submitted data. So if you've got an email field (machine readable name: email) you could access the entered data by calling $form_values['submitted']['email']. And by using foreach $form_values['submitted'] AS $field_name => $field_value one doesn't even need to know the machine readable names. I know it's far from being an honest solution but it might help in specific situations or as another starting point of new features.

Best,
Paul

Of course not, just as I wrote it's far from being a real solution, especially if you have hundreds of web forms. But for some admins/dev this may be a quick'n'dirty workaround. In my case the current project only needs one form for a event registration and the users receives a copy of it. That's why I needed some styling.

I have several drupal projects running and I am looking forward to version 3 (especially performance since there is a project featuring web forms including a few thousand elements, altering these forms is a real pain in t....).

Subscribe.

Wow, I just commented on an issue over here: http://drupal.org/node/255356 and it looks like you guys are already on it, maybe you could add an optional span tag with classes on the textfields, this would permanently solve the inline fields problem without css.

Also this whole idea of outputting in lists is awesome! I'm not sure about line breaks and stuff, but [li] and [span] would make a huge world of differance for themers.

In my situation, we're trying to make a finance application and it will need to fit nicely onto a single sheet of paper, with a signature space at the bottom, so having inherent inline fields would just rock!

Have a look at how it's done in cck with the drop-down option to display the label inline, hidden, or above. (span, none, div).

could I put a site logo image in the html email template ?

As I said, if this isn't ported to the Drupal 5 version, this will not be included in the 2.x branch at all. In addition (just to make things crazy) the Drupal 7 port is also now available, meaning we need to port this across FOUR versions of Webform across three different Drupal versions. Clearly that's not sustainable. So I'm pretty sure this is going to be 3.x only. I'm caught up with more pressing data-integrity features/bugs at the moment, but I'll review this when I have time.

At a quick glace, I can say a few things need cleanup:
- Follow coding standards. The first IF statement in your patch needs to be separated into individual lines.
- This kind of templating is not acceptable, it should be automatic based on the e-mail style:

+/** if using HTML as your email output type, uncomment the unordered list tags below. **/
+/*  <ul>   */

- Template style should be specified per-email, not site-wide (though a site-wide default like you have currently is a good idea).

Oh, seems I already reviewed this once in #23. See those comments too. :P

I said:

The advent of 3.0 will end all support for Drupal 5, so no need to backport to previous versions. Thanks!

In response to you saying:

After looking at the new 6.x-3.0-beta1, I may try porting it to the 3.x branch after all...

Which I assumed meant that you only needed it for 3.x and not at all for 2.x. I haven't changed my mind on the fact that 2.x is maintained in-sync between versions. Basically I meant if you want this in 3.x only, there's no need for a Drupal 5 version, since 3.x doesn't exist for Drupal 5 (but does exist for Drupal 7).

The more important thing is addressing the issues I laid out in #23 and #37. Usually I can apply a patch to both versions in same version Webform version number with little or no changes. I was only requiring a patches for multiple branches if you're asking for a feature in the 2.x version (which is feature-frozen and I don't want to spend additional time working on it). If working only in 3.x, just a single patch for either D6 or D7 will work and I'll handle the differences.

I would strongly prefer the option of HTML e-mails to per webform, using the site-wide setting as a default.

It's more a matter of user preference than a form-by-form basis. Making it per-email means that certain users could get a plain text e-mail versus an HTML one. It's commonplace on any mailing list to be able to choose if you want your e-mails in HTML or plain text, I personally always opt for plain text when given the choice. I think I made it pretty clear what I envisioned way back in #1, it's just a checkbox when configuring the e-mail.

I tested the patch about a month ago and it worked great. I am also using the Mime mail module, and it passed through perfectly. I recently upgraded, so I'll need to re-apply and test the patch again.

I do not understand either of you but here's what I think is happening:

gregarious, you want Webforms to pass the email through another module to turn it into plaintext. Thus, all email Webforms sends out is in HTML as a matter of course.

Advantages:
All forms automatically send out HTML email, if you have hundreds of forms you do not need to go into each specifically to set it to HTML.
Plaintext and HTML for all users.

Disadvantages:
Dependancy on another module, therefore dependancy on someone elses code, therefore learning about someone elses system.
Extra processing on the server.
Plaintext and HTML for all users is frankly not important in the modern web climate.

quicksketch, you want Webforms to build and send out HTML directly, and to send out plaintext directly. You do not want the email received by users to be both plaintext and HTML. You want the option to set within the webform whether to send HTML or plaintext.

Advantages:
No external module dependancy.
Less processing on the server.

Disadvantages:
Users that can only accept plaintext email are shit out of luck if the form is set to HTML email.
Need to manually set each and every single webform to the email style you want, a problem if you have already built many forms.

From my point of view, you are both right. Go with gregarious' method and you end up relying on an external module. Go with quicksketches method and you end up doubling up functionality that has already been coded. I personally would prefer the checkbox option in quicksketches mockup but both acheive the same result. I think it's fair to say that maybe quicksketch could let this one slide just maybe because someone else has already done the patch? If quicksketch doesn't like it he can change it to his preferred method at a later date, but in the meantime users would have access to HTML email! I mean it is all about the user experience right, not to step on any developer toes (look I'm sorry if I'm being rude I know it's your project and your decision quicksketch I'm just putting it out there).

OK.

So what you are saying is that the email template should be HTML code. Let's say for example, someone uses CKEditor to create the email template. So the email that is sent from Webforms is pure HTML code.

Except the email isn't sent - MIME module intercepts the output, keeps a copy of the HTML code, converts it into plaintext, and sends it as an HTML enabled email that will display plaintext for the email clients that do not have HTML email enabled. Correct?

And what you are saying is the form field values which Webforms passes into the email template via a token are plain text. So above and below those values you will have HTML code but the values themselves will be plaintext, presumably missing paragraph tags, line breaks etc etc. Right?

So your patch ensures that the form field values are "HTMLified" and the email template is capable of outputting HTML code as the email, and MIME module does the heavy lifting to turn it into the appropriate email.

It seems to me this is what quicksketch wants to happen as well - except for relying on MIME module. In his solution, unless I'm mistaken, those fields are also outputted in HTML - after all, he creates a HTML webpage to display the results of the submission. I think he wants that page to be used as the email template. In addition to this, he wants the option for there to be no HTML version of the outputted email if he wants. From the sounds of it, MIME module creates the HTML/Plaintext email no matter what and that may be behaviour he is not happy with. To be specific, even if a client is set to only display plaintext email, they still receive the HTML portion of the email. He wants either plaintext OR HTML, not both in one. I think.

Now I'm not a developer and I'm definately not quicksketch and this is his project to develop however makes him happy. But I can understand why he would not want to introduce a dependancy on another module for this functionality. On the same note, webforms is already dependant on some other modules such as "Select or other..." and "Webform Validation".

Frankly I think you have made an intelligent method, and I would deeply love to see it committed "in the meantime" while quicksketch works on his own preferred way. Having it in there wouldn't hurt and he can replace it once he gets time to implement his preferred solution. It would be nice if quicksketch could confirm whether he would commit this code if the errors he has pointed out in previous comments are corrected, but again this is his personal project, his hobby so it's all his choice.

Quicksketch, do you mind posting a comment so gregarious know's which way to go?

subscribe

I'm using 3.0 beta5 but I cannot see any email template on the webform interface.

Okay well here's my up-front apology: @gregarios I've reviewed your patch several times and I'm not satisfied with the implementation. With all the back and forth we both had priorities and ideas about how it should be done. I wasn't happy with the approach you took and so I've completely rewritten the whole thing. I'm sorry (really) that you spent a lot of time putting this together but I won't be using what you've written for the project. I hope this hasn't completely put you off of contributing code to existing modules.

Here's my rewrite so far that includes what I consider to be important:

• Per e-mail configuration of HTML settings
• Re-use of the existing rendering system for creating HTML output rather than hijacking the "text" formatting of each component

It does not include important features that should be added:

• A global configuration of e-mail format default

I'm thinking that on the admin/settings/webform page we should add something like the following:

E-mail format default:
(•) Plain text
( ) HTML

E-mail format option:
(•) Per-webform configuration of e-mail format
( ) Send all e-mails in the default format

Sending all e-mails in the default format would remove the options for HTML from the e-mail configuration form. Obviously none of these options would be shown unless Mime Mail was installed.

This patch also makes the start of supporting attachments, since it seems like a trivial addition. All that's missing is a loop through the submission to find the file paths that will be added as attachments. Attachments are also configured per e-mail.

It's for the 6.x-3.x dev version (against the DRUPAL-6--3 branch) it should apply to 3.1 I think. I'll port it to Drupal 7 once we finish the coding.

This update includes functionality for including attachments in e-mails.

Marked #159678: Send file attachments in email duplicate.

patch reroll against 3.2

Thanks @stella and @gregarios for your feedback. Updated patch to fix the foreach() error noted in #65 and added the options for "E-mail format" and "Override default format" to the Webform settings page. I think this is all the functionality needed, though it could use additional testing.

Minor update removing an unnecessary check.

I ran into a bug with MIME Mail while testing this patch. It would probably be good to get it corrected in MIME Mail before adding this to Webform. See #897346: Plain text e-mails with attachments get sent as HTML

Here's another minor update that includes our new variables in hook_uninstall().

Turns out the bug I had was present only in the 6--1 branch, not in HEAD where current development is. Drupal 7 port attached, though it doesn't do anything visible since MIME Mail does not exist for Drupal 7.

I've committed these patches to ease porting/patching of #248157: Allow any Webform to be displayed as a block. Please post any problems with the dev version here or open a new issue.

I'm using webform 6x3.2
Is it possible to strip the %email_values and send the email as HTML now?
Do I have to apply a patch? Could you please explain it a bit?

Click "view all releases" on the project page, then find the 6.x-3.x-dev version. I don't post dev releases on the project page because I prefer people to use the official releases when posting bug reports. This feature will be in the 3.3 version of Webform.

I took a look at this now. As I see it isn't part of 3.2.

+++ webform.module	30 Aug 2010 17:25:59 -0000
@@ -2059,7 +2055,30 @@
+                if ($file) {
+                  $file->list = 1; // Needed to include in attachments.
+                  $attachments[] = $file;
+                }

The list parameter won't be needed in the upcoming releases of Mime Mail, see #629038: Attachements dont respect ‘list’ setting.. However this will work for now and can be postponed until a new release, or left as it is though will be unnecessary.

+++ webform.module	30 Aug 2010 17:25:59 -0000
@@ -2059,7 +2055,30 @@
+          mimemail($email['from'], $address, $email['subject'], $email['message'], !$email['html'], $email['headers'], $email['html'] ? NULL : $email['message'], $attachments, 'webform');

We should use a more descriptive mailkey like "webform-$nid" in order to support features like #882528: Template suggestions based on mailkey, so the messages would be able to have their own .css and .tpl files.

@sgabe I think these issues may need further discussion than immediately making the changes, could you open new issues?

THANK YOU for the Mime support! It saved my life. Kudos!

Has this been added to 6.3? I couldn't get the patch to work. The checkbox wouldn't stay checked when submitting the form.