Email template should use front-end theme when configuring/sending e-mails

You need to make sure that your e-mail configuration (node/x/webform/emails/x) is configured to use the "default" template, otherwise the template won't be pulled from the theme, it will use the user-defined one.

I too am having this problem.

I have a webform whose nid is 92. I am using a custom theme based upon fusion.

I placed a file named webform-mail-92.tpl.php in the fusion subtheme directory. However webform is not picking up the custom template from the subtheme directory. Rather - it is using the default code on the Webform -> Emails page (under Email template) - Submitted on %date Submitted by user: %username Submitted values are: %email_values The results of this submission may be viewed at: %submission_url

I have set and reset it to Default Template and saved the page. However the next time you edit the Email Settings it has reverted to "Custom Template". If you delete that setting and add a new one leaving the Template setting at "Default", then re-edit the setting it will be set to "Custom"

I have cleared all drupal caches as well as browser cache and Webform will only send emails based upon the default format. I actually copied webform-mail-92.tpl.php and made a very slight change in the wording and saved it in the fusion subtheme directory as webform-mail-92.php to ascertain for certain what was being used. Same result - just the default email template format.

THIS IS V6.x-3.9

Please help . . . Mike

I have determined that Webform is not even using the default webform-mail.tpl.php module in the sites/all/modules/webform/templates directory. It is only using the default code on the Webform Emails page. If that code is deleted a blank email is sent.

Again - it is impossible to set the email template to "Default" and have it stay that way. It continually reverts to "Custom Template".

THIS IS V6.x-3.9

Thanks . . . Mike

ecsmike: I'm positive that it uses the themed template if you don't change any other settings. If you set up a new e-mail setting and just save it without changing the template, it will save into the database the string "default". If "default" is stored in the webform_emails table for that template, Webform will theme the e-mail itself instead of using the user-defined template. If you're experiencing trouble getting the default to revert back, you may try just entering "default" into the template area and nothing else then save the settings. That would have the same effect as reverting to the default template.

If you're using CKEditor, you may also be affected by #1087926: Webform refuses to use 'default template' when template fieldset uses CKEditor.

Hey I'm using 6.x-3.9 too - apologies if this is the wrong place to post this.

I can confirm that the 'Custom' e-mail template setting does revert back to 'Default' when I save the webform and re-open it again. (This is tested with an existing webform node, after a recent upgrade to 6.x-3.9)

I can confirm that a copy of webform-mail.tpl.php in my theme dir *is* being picked up - however, my problem is that not all of the template variables seem to be available to this template now it is in the theme dir - to be specifc: $form_values, $sid and $cid.

Have I missed something obvious?!

P.S. Thanks for this module it's great - especially like the option you've added to choose the format of the From headers for us poor souls obliged to maintain Drupal sites on Windows servers :)

I can't provide support on old versions of Webform. If you upgrade to 3.11, the issue with "Default" being selected is corrected.

I can confirm that I am having the same problem as Mike. I do not use CKEditor. drupal and all modules are latest versions as of today.

I can't stop webform from using whatever is in the custom template textarea. If I make sure that Default template is selected, I get the popup asking if that's OK. I confirm and submit the form, but it still uses the custom template in the email settings form, and if I go back to edit the settings in that form, Custom template is selected again. This happens even if I delete all existing email recipients and add a new one, submitting the form without changing default to custom template. It's just 100% determined to use the custom template on the email form.

I need to process the submitted text before sending the email as I am using it to input to a CRM that requires a specific format in the email body, so I can't just use the tokens. But $submission is effectively inaccessible to me because of this problem.

In function webform_email_edit_form_submit in includes/webform.emails.inc, is this right?

  // Set the template value.
  // TODO: Support reuse of templates.
  if (strcmp(trim($form_state['values']['templates']['default']), trim($form_state['values']['template'])) == 0) {
    $email['template'] = 'default';
  }
  else {
    $email['template'] = $form_state['values']['template'];
  }

This appears to ignore the value in the template_option select box and determine whether the default or custom template should be used according to whether the text in the template textarea is identical to the text in the hidden default template textarea.

That should produce the same outcome unless the user has strangely selected default but then edited the textarea anyway (although this is not entirely intuitive and that behaviour would not be totally unexpected).

But something is going wrong with the strcmp test, because I can change the template_option setting to default (at which point the text in the default template textarea is inserted into the template textarea), do nothing else before submitting the form, yet when I check the row for this email in the webform_email table in the database, the template field still contains the text in the textarea, not simply "default", as it is intended to do.

I suggest changing the relevant line in the snippet above to:

  if ($form_state['values']['template_option'] == 'default' || strcmp(trim($form_state['values']['templates']['default']), trim($form_state['values']['template'])) == 0) {

That should produce the same outcome unless the user has strangely selected default but then edited the textarea anyway (although this is not entirely intuitive and that behaviour would not be totally unexpected).

If the user sets the template to "Default" but then edits the textarea, JavaScript on the page automatically changes the template back to "Custom". This PHP-side level check is just ensuring that the string-check takes precedence in the event that the user does not have JS enabled but changes the template.

My guess is that the strcmp is failing because, well, the fields are no longer the same. I'd like to figure out *why* these fields are not the same. Perhaps something is modifying the hidden textarea's value (like CKEditor. Again.)?

I can confirm this as well. I am using 6.x-3.11 and using webform-mail-*.tpl.php files to template submissions, and if I change any options within the e-mail settings, it will show my template selection as being 'Default template' while still in the edit view -- however, once I've saved, and go back into the edit form again, the template has been reset to 'Custom template' -- which, if I don't go in the 2nd time after changing a value and reset it to 'Default template' -- it completely breaks the emails that go out and presents them with blank values. It really is a pain to have to save the e-mail settings twice in order to make the webform-mail-* template files work.

Webform 6.x-3.11 also, copied the webform-mail.tpl.php file into my theme folder, cleared the cache and it is using the new file. It loads in as my 'Default template' but it is not loading in the way I would expect it.

Standard Default Template without copying the webform-mail.tpl.php into my theme is:

Submitted on %date
Submitted by user: %username
Submitted values are:
%email_values

The results of this submission may be viewed at:
%submission_url

Default Template after copying the webform-mail.tpl.php into my theme and making NO modifications:

Submitted on 2011-07-26 07:44
Submitted by user: sjordan [10.XXX.XXX.42]

Submitted values are:


The results of this submission may be viewed at:
http://www.XXXXXXXXXXXXX.com/node/28/submission/

I have replace some info with X's, but it is actually displaying all of the information hardcoded into the default template. Then, when it sends the e-mail, this exact information is sent without replacing anything else. Shouldn't this behave the same exact way, since I did not modify the template, just merely copied it into the theme folder?

Thank you,
Shane

I haven't ever been able to reproduce this problem. Are you guys still experiencing it? Seems like reports stopped coming in about this after 3.12 and higher were released.

Just adding a "gotcha" that I encountered in case anyone stumbles across this. I was putting the modified email template into the theme for my website and it wasn't taking effect. Apparently I needed to put it in the ADMIN theme for my website.

I can confirm #15. Impressed you were able to figure that out, harlandcp.

This behavior doesn't seem right. Should probably be documented, at least.

Actually, thinking about this a bit more, this is a bug that needs to be changed.

If I'm using Seven as my admin theme and don't want to change it, my templates will be overridden on core updates.

@harlandcp and john-ess: If the "Theme to render the emails" selection on the admin/config/system/mailsystem page is set to Current, emails will use the admin theme when you're logged on, or the site default theme for general users - that will dictate which theme you need override templates in.

Thanks @vernond! Great tip. I didn't know you could do that. Of course you'd need to have Mail System module installed to take that approach.

An alternative that I use on most of my sites is I subtheme Seven and then set that as my admin theme. I haven't used this specifically for Webforms, but it would obviously work for this need also.

At the same time, I do think it would make sense to at least attempt to use the front-end theme when resending e-mails. Mailsystem would probably win out anyway as it sets the theme at the time the e-mail is sent, a little later in the process.

Not sure why this issues is needs review, moving to active.

I'm moving this to a feature, since although it's confusing, it's a natural result of how Drupal functions between its admin and front-end themes. If you have something that is displayed both in the admin and front-end theme, you need to theme it in both places.

Thinking about how to solve this problem, I'm not even sure it would be possible to use the front-end theme for e-mails after the admin theme had already been loaded. Because Drupal sets a global $theme variable, you can't load more than one theme at a time, so I'm not even sure how Mailsystem handles this.

#15 is indeed the solution to having a custom Webform email template.

Custom email template file needs to go in the admin theme folder and not the site theme. Took me an hour to finally find this post and get the answer I needed.

Closing for lack of activity and/or patch, and what seems to be an adequate solution above.