Non-Unique Conditional Email Addresses with Webform.Module

In:

22Feb2009

I recently ran into two problems when using the "conditional recipients" functionality of the Drupal Webform module - recipient addresses must be unique, and addresses are exposed in the page markup. My solution involved creating mail "aliases" via hook_mail_alter().

Update: The methods discussed in both this post, and in the comments work with Webform 2.x, but not Webform 3.x. As of January 2011, there appears to be no preferred method for implementing non-unique conditional email addresses in Webform 3.x.

The Webform module's conditional recipients feature is a flexible function that allows the values of a select box to be tied to email notification recipient addresses. A simple example for dropdown field such as "I need help with" could have the following options:

orders@example.com|Orders 
customer_service@example.com|Customer Service
technical_support@example.com|Technical Support

By selecting this "I need help with" select box under "Conditional e-mail recipients" form configuration, Webform will send a confirmation message to the appropriate address based on the option selected by the user. You can read more about Webform's conditional recipients on Drupal.org. However, there are two basic problems with this functionality.

While the email addresses are not formatted as mailto: links, they are exposed in the form markup, which could lead to them being harvested by SPAM bots.
The addresses must be unique. If in our example above, Customer Service and Technical Support both went to "support@example.com", only one of them would actually appear on the form. Keys must be unique when entering key/value pairs for Webform select fields. For example, the following will only display "Orders" and "Technical Support":

orders@example.com|Orders support@example.com|Customer Service support@example.com|Technical Support

Happily, there is a (fairly) simple solution that fixes both problems -- use hook_mail_alter() to set up mail aliases for the site. I generally create a "sitename_overrides" module for all of my sites as a place to put simple hook implementations, block implementations, etc. However, the following two functions could be added to a new module if necessary. For help setting up a new module, see the module developer's handbook.

Step 1: Create a function to generate an array of aliases and replacements (this must be placed inside a module -- "sitename_overrides.module" in this example):

<?php
/**
 * Private method to define email address aliases.
 *
 * Returns a two-dimensional array: $aliases['search'] and $aliases['replace']
 *   meant for calls to str_replace().  
 */
function _sitename_overrides_mail_aliases() {
  $aliases = array();

  /* User aliases. */
  $aliases['search'][]  = 'orders_at_example';
  $aliases['replace'][] = 'orders@example.com';
  
  $aliases['search'][]  = 'customer_service_at_example';
  $aliases['replace'][] = 'support@example.com';

  $aliases['search'][]  = 'technical_support_at_example';
  $aliases['replace'][] = 'support@example.com';

  return $aliases;
}
?>

Step 2: Implement the mail_alter() hook for our mythical "sitename_overrides" module to replace our aliases with actual email addresses:

<?php
/**
 * Implementation of hook_mail_alter().
 */
function sitename_overrides_mail_alter(&$message) {
  /* Replace to: aliases defined in _modulename_mail_aliases(). */
  $aliases = _modulename_mail_aliases();
  $message['to'] = str_replace($aliases['search'],$aliases['replace'],$message['to']);
}
?>

Step 3: Add or update the select field in the Webform with the aliases defined in step 1. So from our example:

orders_at_example|Orders
customer_service_at_example|Customer Service
technical_support_at_example|Technical Support

Now when Webform calls drupal_mail() to deliver your messages, the aliases will be turned into actual addresses, and can be delivered properly, all without exposing your email addresses online!

Eric Weik's blog

Comments

#1 alternative

Submitted by Visitor on Tue, 03/03/2009 - 07:03.

why dont you just use the additional processing? eg:

<?php
if ($form_values['submitted_tree']['subject']=="orders_at_example") {
  $node->webform['additional_emails'][] = "orders@example.com";
}
?>

etc..

or am i missing something? (just started using webforms)

Timothy : www.spiraleye.com

#2 Interesting Method

Submitted by Eric Weik on Sun, 03/08/2009 - 21:15.

Timothy,

The additional-processing method seems like a great idea. For the particular application I was working on there was actually a long list of possible addresses and multiple forms, so a more centralized approach made sense. But for a single contact form, using the additional-processing method looks great because it wouldn't involve module development.

Thanks for the tip!

-Eric

#3 Thanks loads to both of you

Submitted by Will (not verified) on Mon, 02/01/2010 - 07:34.

Thanks loads to both of you for posting this information. It has helped me out massively.

One thing that confused me for a while was that in my example I was using multi select check boxes. It seems that in this case webform puts an additional form value into the mix. In my example I had to use the following code to get this working:

<?php
if ($form_values['submitted_tree']['webform_component_name']['webform_component_key']=="webform_component_key") {
  $node->webform['additional_emails'][] = "orders@example.com";
}
?>

Where webform_component_name is the name you've given to the specific webform checkbox element, and webform_component_key is what you've named that option's key.

Just thought I'd post this for any other beginners like me, hopefully it'll save you the 2 hours I've just spent working this out! :)

Thanks again

#4 Devel.module and dpm() are great!

Submitted by Eric Weik on Mon, 02/01/2010 - 13:07.

Thanks for posting this tip Will!

I find that one of the single most useful tools for Drupal development is the dpm() function provided by the Devel module.

If you cannot figure out where that variable is that you need, if you have devel module installed, you can simply add the following to your code:

<?php
  dpm($form_values);
?>

It will output a clickable hierarchy of values defined in the $form_values variable.

If you don't have any idea what variable you are even looking for, then you can try this:

<?php
  dpm(get_defined_vars());
?>

For more information see the following:

#5 Great, many thanks. Will

Submitted by Will (not verified) on Thu, 02/04/2010 - 07:30.

Great, many thanks. Will definitely look into. It's one of those modules I've heard mentioned a lot but never looked into fully. Once I've got time I want to have a proper explore of Drupal under the hood so this sounds perfect.

In this instance I found out the variable by looking at the source code being outputted with Firebug.

By the way the switch code for multiple email addresses you posted below definitely does work. Just implemented and tested it with what I'm doing.

Thanks again, you're very much bookmarked!

#6 How I can use this code in

Submitted by Visitor (not verified) on Tue, 11/16/2010 - 12:29.

How I can use this code in D6? (Which function in my custom module I must create)?

#7 This is interesting. Thanks

Submitted by Visitor on Wed, 07/29/2009 - 11:03.

This is interesting. Thanks for posting about it. I don't really understand all of these terms and stuff, but it's good to learn new things.

#8 Seems a litle dificult to do,

Submitted by Visitor on Sat, 08/08/2009 - 00:42.

Seems a litle dificult to do, im new to drupal and made me difficultto understand completely, but your guide is so complete and detailed, i will try it, hope dont messed up the things.

Thanks for your info.

#9 additional-processing method

Submitted by Visitor (not verified) on Tue, 01/12/2010 - 16:12.

Hey there, coming to this thread very late, but I am curious how you would implement your idea the way "Timothy" did using additional processing. His example only swaps out one email address. How would you do it with more than one?

Thanks!

Paul

#10 Additional processing with multiple addresses

Submitted by Eric Weik on Sun, 01/17/2010 - 11:54.

Hi Paul,

I've not actually tried this, but I think the syntax to extend Timothy's example to add recipients based on the subject would look something like this:

<?php
switch ($form_values['submitted_tree']['subject']) {
  case "orders_at_example":
    // Add two different CC address for "orders_at_example"
    $node->webform['additional_emails'][] = "orders@example.com";
    $node->webform['additional_emails'][] = "fulfillment@otherexample.com";
    break;
  case "info_at_example":
    $node->webform['additional_emails'][] = "info@example.com";
    break;
  case "support_at_example":
    $node->webform['additional_emails'][] = "support@example.com";
    break;
}
?>

-Eric

#11 looks very useful

Submitted by Paul (not verified) on Sun, 01/17/2010 - 12:09.

Hi Eric,

That actually looks very useful. I may try that. Cheer!

Paul

#12 Would there be a way to

Submitted by Will (not verified) on Fri, 02/05/2010 - 06:29.

Would there be a way to specify an email address to send to if no fields are selected? I've been trying to figure it out but can't get it working.

#13 Default

Submitted by Eric Weik on Fri, 02/05/2010 - 08:49.

Will, have you tried simply adding a default case to the switch statement?

Updating the above example, it should look something like this:

<?php
switch ($form_values['submitted_tree']['subject']) {
  case "orders_at_example":
    // Add two different CC address for "orders_at_example"
    $node->webform['additional_emails'][] = "orders@example.com";
    $node->webform['additional_emails'][] = "fulfillment@otherexample.com";
    break;
  case "info_at_example":
    $node->webform['additional_emails'][] = "info@example.com";
    break;
  case "support_at_example":
    $node->webform['additional_emails'][] = "support@example.com";
    break;
  default:
    $node->webform['additional_emails'][] = "contact@example.com";
}
?>

#14 How rude of me, I didn't

Submitted by Will (not verified) on Wed, 02/24/2010 - 12:22.

How rude of me, I didn't notice you posted this. Sorry for not replying. Many thanks once again. I ended up just putting an 'other' option and making it a required field as we were in a hurry to get the site out on time (which we did, hooray). Now I've got a bit of breathing space I'll have a proper look over this at some point, as it seems a much more elegant solution.

All the best - Will

#15 This is genius! Great work!

Submitted by Chris Free (not verified) on Tue, 02/02/2010 - 17:11.

This is genius! Great work!

#16 reducing the number of emails

Submitted by Visitor (not verified) on Wed, 02/10/2010 - 14:22.

I have a form which I have created individual emails for each topic and piped them.
me@here.com|apples
you@here.com|pears
us@here.com|oranges
them@here.com|grapes

In those groups say me, us and them recieve the email. I don't want to receive 3 emails but I do want to know that apples, oranges and grapes were checked.

How can add additional php code that does some sorting to reduce the email output to one email?

#17 Default Behavior

Submitted by Eric Weik on Thu, 02/25/2010 - 00:00.

I'm not 100% sure I understand your question, but I believe what you are looking for is the default behavior of the Webform module.

If you add a "topic" field as outlined above and check "e-mail a submission copy" and "include in e-mails" for that field, a copy will be sent to each to the appropriate address(es), and the email will also show which options were checked.

#18 Thanks for all the

Submitted by Moz_D (not verified) on Wed, 02/24/2010 - 08:47.

Thanks for all the interesting help. I'm quite new to all of this and I'd really like to include this on my site, but I still have a problem. For some reason I keep getting an error:

warning: mail() [function.mail]: SMTP server response: 501 : recipient address must contain a domain in C:\Program_Files\wamp\www\includes\mail.inc on line 193.

It appears that the first part "hotmail_at_lr" isn't recognised in:

hotmail_at_lr|Orders
customer_service_at_example|Customer Service
technical_support_at_example|Technical Support

It only works when the first part is a real email address. But I'd really like the email address to be hidden and use the methods you've described. Can anyone suggest why this is happening ?

#19 Replacement isn't working

Submitted by Eric Weik on Wed, 02/24/2010 - 09:48.

Moz_D - It looks like "hotmail_at_lr" isn't being replaced with an actual e-mail address. Which of the methods discussed above are you using (e.g. the "write a module" method from the original blog post, or the "use additional processing" method discussed in the comments)?

#20 I first tried the module

Submitted by Moz_D (not verified) on Wed, 02/24/2010 - 11:17.

I first tried the module approach (with .info and .module files) and then I tried the additional processing. I also tried putting the code in the Additional Validation section without any luck. I really appreciate your help.

#21 Field identifiers, dpm, etc.

Submitted by Eric Weik on Wed, 02/24/2010 - 11:37.

If you only need to add aliases for a single form, the "additional processing" model is probably better (I originally developed my solution as a module because there were lots of forms on the site and it seemed like a good idea to have e-mail aliasing for the entire site).

So that said, probably the easiest place to make a mistake is in the field identifier / hash index when pulling the value out of the $form_values[] hash. E.g. in #9 above it is pulling from a hypothetical "subject" field with:
$form_values['submitted_tree']['subject']

I usually put "dpm($form_values);" at the top of my code to make sure I'm using the right identifier for the form field (like "subject" above). This only works if you have the devel.module installed though.

The other thing to check is that since you are using additional processing to add recipients, you do not need to specify your conditional field in "Conditional e-mail recipients" section of the form configuration (you did with the "module method", but not the "additional processing" method).

This is probably a little confusing since the "additional processing" method has been developed entirely in this comment thread. Perhaps I should make a new post outlining it in detail.

Hope this helps!

#22 Thank you once again for your

Submitted by Moz_D (not verified) on Wed, 02/24/2010 - 16:25.

Thank you once again for your help. I think you're right and I should be going for the simpler solution of "additional processing" rather than a module.
I've unselected everything in "Conditional e-mail recipients" (I only had "subject" selected) and I've taken away the email address in Configuration under "Webform mail settings" "E-mail to address:". I have the devel.module installed.
However I still can't seem to get the first part ("hotmail_at_lr") converted into an email address. When I look at the output from "dpm($form_values);", I get:
submitted (Array, 6 elements)
11 (String, 13 characters ) hotmail_at_lr
and:
details (Array, 4 elements)
email_subject (String, 2 characters ) 11
and further down the list:
submitted_tree (Array, 1 element)
email_us (Array, 6 elements)
subject (String, 13 characters ) hotmail_at_lr
I'm afraid I don't really understand the "field identifier / hash index", but I think that the above output tells me that the field is correctly called "subject" and that I'm getting the right "subject" value as shown under "submitted_tree". But I can't see the email address that I want anywhere in this devel output. What should it be under ? I'm also not sure why "email_subject" is "11".
I've also made sure that php is selected in the Input Format just in case it's not recognising this php code that I've put in "Additional Processing" under "Webform advanced settings". And I've tried all the different combinations of the php code from #1 to #12 above. It's as if the php code isn't working. Strange.
Any ideas ?
Many many thanks once again.

#23 Puzzling

Submitted by Eric Weik on Wed, 02/24/2010 - 23:29.

Moz - The output from dpm($form_values) is just to double-check that you are using the right identifier to access the submitted field value. And based on what you've written above, it looks like $form_values['submitted_tree']['subject'] should correct for your form. In which case the code from #9 or #12 should also work. Without seeing your setup, I'm at a loss to explain why it doesn't work.

#24 One possibility...

Submitted by Eric Weik on Wed, 02/24/2010 - 23:48.

Moz - I just set up a test form to make sure this does indeed work as expected, and it worked for me with drupal-6.15 and webform-6.x-2.9.

Two things I thought of while setting up the form:
1) Make sure that your "subject" field does NOT have "email a submission copy" checked. This would try to send the email directly with the submitted value of "hotmail_at_lr". Instead, we're using it to add recipients with "additional processing" code.

2) The sample code from #1, #9, or #12 will not work if have have marked your "subject" field as "Multiple". If it is marked "multiple", then $form_values['submitted_tree']['subject'] will be a list of selected options instead of a string.

#25 What now? Code re-write!

Submitted by tscad (not verified) on Sun, 03/28/2010 - 15:51.

I might just be wishing for a miracle here but here goes. With 3x Beta 2 out and still no conditional recipients option what are we to do? It appears as if 'additional_emails' has been removed and is no longer an option. I like the functionality and ease of use of 3x, but they are still way behind the times with leaving emails visible in the source code. Anyone have any ideas of how to simply search and replace the select key with an email? Or is 'additional_emails' re-written so that I can't find it?

#26 Ill News

Submitted by Eric Weik on Mon, 03/29/2010 - 15:28.

I've not tried the betas yet. Some of the new features look really useful (I could have used "conditional logic in multi-page forms" a number of times in the past), but if the "additional_emails" functionality was removed completely, without a clear replacement, that would be sad news indeed.

I guess I'll install it on a sandbox site and look into this more!

#27 Some feedback from Webform 3.x

Submitted by akalata (not verified) on Mon, 07/12/2010 - 13:13.

Eric, in case you get around to playing with the 3.x betas, here's my experience:

Using the "module method" originally described in your post, I cannot get webform submissions to send, BUT can successfully generate other emails (such as a test of the SMTP Auth module) to the aliases defined in the module. So we know the module is okay, just doesn't play nice with webform anymore.

Right now I'm poking through what /index.php/cat/c3_Abendtaschenquicksketch provided at http://drupal.org/project/webform_php, and hoping to figure out that module's code enough to modify it with your "module method" code.

#28 3.x Beta

Submitted by Eric Weik on Tue, 07/13/2010 - 11:03.

Thanks for the feedback! I knew that the webform['additional_emails'] method no longer words in the 3.x beta, but I don't know why implementing hook_mail_alter() in a module would not work (since it should be altering core drupal_mail() behaviors independently of Webform.module).

I will look into this further myself.

#29 Anna, Eric - any progress?

Submitted by Jen (not verified) on Mon, 08/30/2010 - 23:52.

Obviously node->additional_emails no longer works, but I absolutely need to do this, and nobody knows how!! Google is only returning discussions about webform 2.... need help in this, if it's module code then so be it, but how do I alter the email appropriately to add a CC based on a form field?

#30 Webform 3

Submitted by Eric Weik on Sun, 09/12/2010 - 17:58.

Well, I'm using Webform 3 in a project right now, so I guess it is time for me to figure this out! -- Eric

#31 CR

Submitted by tscad (not verified) on Sun, 09/12/2010 - 18:54.

To my knowledge there is no documentation or information on how to make conditional recipients work with 3.0. There is however "plans" to make conditional recipients a part of webform 3. I have made a number of posts stressing the importance of conditional recipients to the author of webform and I usually get "snobish" replies. I would love to see more people push for this feature. Please go to drupal.org and search the tickets for "conditional recipients" and help push this request onward.

Thanks

#32 GOOD NEWS

Submitted by tscad (not verified) on Tue, 10/12/2010 - 00:04.

There's now a module to fix this problem.

http://drupal.org/node/282436#comment-3561298

If you don't understand how to use it reply to this and I'll be more than happy to help.

#33 Good News Indeed!

Submitted by Eric Weik on Tue, 10/12/2010 - 07:42.

Thank you for the update! This is a good first step.

#34 Need help :)

Submitted by Twisterforever (not verified) on Thu, 10/21/2010 - 10:08.

Hi, i tried to use that but actually i'd need only to hide email in the source page and it doesn't work.

Is it working for this too?

Please help i need to hide email and i don't know how i can, i'm noob with php :/

#35 Update

Submitted by Eric Weik on Wed, 01/12/2011 - 17:35.

As has been well covered in the above comment thread, the method discussed in my original post (as well as the alternate methods discussed in the comment thread) no longer works in Webform 3.x.

After spending some time debugging, I think the most significant reason is that the value of fields used to generate email messages must pass a call to the Drupal core valid_email_address() function. So the trick of using values like "orders_at_example" fails because valid_email_address("orders_at_example") returns false and halts the process before the mail is ever handed off to drupal_mail() or its hooks.

As it turns out, you can replace "orders_at_example" with something like "example.alias.orders@example.com" and then use hook_mail_alter() to convert this to "orders@example.com". However, as a work-around, this is pretty ugly IMHO as there is no clear indication of what is an alias and what isn't.

The approach I am currently using attempts to addresses the combined issues of address obfuscation (for spam bots), and the requirement that email addresses be unique. The approach looks something like this:

Using the new hook_webform_select_options_info() hook, the module adds a new "pre-built option list" called "Notification Aliases". This list is user customizable, and allows the same address to be entered multiple times (but the aliases / keys must be unique). E.g.:
Sales Alias|foo@example.com
Support Alias|bar@example.com
Media Alias|foo@example.com
When converted into an option array for the form, these are converted into MD5 hashes based on the unique alias / key). E.g.:
ef1dfe9b594f34b97db4b4b082fce422@example.com|Sales Alias
db464bdff782ffe49a9b0ef15a94f34b9@example.com|Support Alias
082fce69ba94f24ef1dfe34b974bdb6d@example.com|Media Alias
These are now obfuscated (so spam bots will not harvest them), are unique to the option label (instead of the email address), and will pass a check to valid_email_address().
Using hook_mail_alter(), the hashed value is converted back into the target email address so drupal_mail() can deliver the message.

Its a little convoluted, but seems to work well enough.

I'm going to review the module code, run the whole idea past folks in the Webform.module issue queue, and possibly release this module into the wild.

My concern is that if this issue will eventually be fixed in Webform.module I don't want to waste resources or add confusion by adding a new module.

- Eric

#36 Webform Additional Processing

Submitted by Greg (not verified) on Fri, 02/11/2011 - 16:01.

Hi Eric,
I've been keeping an eye on this webform issue since last summer, and just recently realized the 3.x branch renders the additional processing snippet you came up with useless. I see your post on http://drupal.org/node/282436#comment-3939038 but still don't know when/where the solution is. This hashing idea is intriguing to me. Do you have more info, or module posted anywhere?

I really can't understand why the maintainer of webform has been fighting a solution to this issue for this long. People have been requesting this basic feature for years. I don't understand the push-back and don't follow the logic of displaying every email address a webform could possibly be sent to in tags. Why bother having a contact form, an unordered list of subject: mailto: links would suffice.

Even if you bend to this dumb way of doing things, you CAN'T do something like this for a select box in 3.x anyways. Can't have keys like this. Can you?:
person@company.com|Subject 1
person@company.com|Subject 2

person1@company.com|Subject 1
person1@company.com, person2@company.com|Subject 1

#37 Hi Erik, I would be

Submitted by Joel (not verified) on Thu, 02/10/2011 - 20:16.

Hi Erik,

I would be interested in the fix, even if it's temporary. It seems a little more elegant. I really need obfuscated email addresses.

Joel

#38 A Module to Address This...

Submitted by Eric Weik on Fri, 02/11/2011 - 16:49.

Joel and Greg,

I posted about my module in the issue queue about a month ago - E.g.: http://drupal.org/node/282436 but have not gotten much feedback (I think everyone there is hoping that this will be addressed within Webform directly). Someone did point out that the "hashed recipient name" solution will not work for domains that utilize a "catch-all" email address, but I think that can be addressed without too much trouble.

The thing holding me back from simply releasing my module is wondering if I should release it on drupal.org, or just as a download somewhere. The "hashing" solution seems like kind of a kludge, and @quicksketch backs the "conditional email" feature discussed here: http://drupal.org/node/687606

I don't want to release something onto drupal.org that could lead to confusion, muddy the waters, or will be unnecessary after the next Webform release (particularly as this would be my first module contribution!). But releasing a Drupal module as a tarball somewhere seems less than ideal too. So I'm sort of stuck trying to decide how to proceed.

I'll think about this more this weekend and decide something one way or the other.

-Eric

#39 Webform Additional Processing

Submitted by Greg (not verified) on Fri, 02/11/2011 - 17:15.

Thanks Eric,
Even if you don't release this module for the contrib community, I think even a quick and dirty tutorial (simliar to your 2.x branch snippet) about your new 3.x method would be SUPER beneficial to those of us in the drupal community that aren't leet enough to sway the drupal-contrib module contributors' minds. I've also tried contributing modules, in order to give back and this process of submission and code review is not as easy and "open" as drupalites are told to believe. Even harder to crack that shell when maintainers disregard feature requests for many years, just sayin.

None the less, good work on your webform 2.x branch snippet. It really helped me grasp the workings of webform. I hope this issue isn't still around in webform 4.x, doesn't seem like a need to address this by anyone with the control to do so.

#40 Thanks for your efforts to

Submitted by Joel (not verified) on Fri, 02/11/2011 - 17:09.

Thanks for your efforts to solve this problem.

Here is what I came up (which isn't elegant at all, but achieves obfuscated email addresses and allows for non-unique email addresses)

This module code will replace email addresses like this:

nop.alias0@xyz.com => abc@xyz.com
qrs.alias0@xyz.com => def@xyz.com
tuv.alias0@xyz.com => ghi@xyz.com
tuv.alias1@xyz.com => ghi@xyz.com 
tuv.alias2@xyz.com => ghi@xyz.com

...etc...

<?php
/**
* Implementation of hook_mail_alter().
*/
function [module]_mail_alter(&$message) {
  # replace [rot13].alias[num]@... with real email addresses
  $message['to'] = preg_replace_callback('/^(.+?)\.alias[0-9]*(?=@)/', '_[module]_deobfuscate_email_address', $message['to']);
}
function _[module]_deobfuscate_email_address($matches) {
  return str_rot13($matches[1]);
}
?>

#41 Kludge away!

Submitted by Eric Weik on Fri, 02/11/2011 - 23:08.

Nice one Joel! This is just the sort of approach I am taking too - only I'm trying to spare the site administrators the rot13 (md5 hash in my case) step. ^_^

Thanks! --Eric

#42 A Simple Solution with Webform 3.x

Submitted by Ran B. (not verified) on Thu, 05/05/2011 - 02:44.

Hi,

I am using Drupal 6.20 and Webform 3.9

I needed conditional e-mails for sending webform results to one of three recipient e-mail addresses, according to the country selected in the form. If the selected country is US/Canada the form goes to email #1, EU counties go to email #2, all other to email #3. I was struggling a few hours with this one. Finally, thanks to the help I got here and in the Drupal site, this is the solution that I found...

The country "Options" list in a webform select Component named "Country" is set as follows:

Afghanistan@some-non-existing-domain.com|Afghanistan
Albania@some-non-existing-domain.com|Albania
Algeria@some-non-existing-domain.com|Algeria
... 

The implementation of hook_mail_alter() in a generic custom module:

<?php
function [the_custom_module_name]_mail_alter(&$message) {
  // Only if the form is addressed the non-existing domain some-non-existing-domain.com
  // do the email replacement (do not screw up other Webforms)
  if (strpos($message['to'], 'some-non-existing-domain'))
  {
    $email1 = "SalesUSA@real-domain.com";
    $email2 = "SalesEUROPE@real-domain.com";
    $email3 = "SalesWorld@real-domain.com";
    switch($message['to'])
    {
      case 'Canada@some-non-existing-domain.com':
      case 'United_States@some-non-existing-domain.com':
        $message['to'] = $email1;
        break;
      case 'Austria@some-non-existing-domain.com':
      case 'Belgium@some-non-existing-domain.com':
        [more EU countries cases...]
        $message['to'] = $email2;
        break;
    default:
        $message['to'] = $email3;
    }
  }
}
?>

This simple code seems to work just fine for me. I believe it is secure - the real e-mail addresses are concealed in the form. Selection of one of the many countries would lead to one of the three recipients. Hope this code would be useful to others.

#43 Email by country

Submitted by James L (not verified) on Wed, 11/09/2011 - 10:02.

Thanks to Eric for the article and Ran B for this.

I've got a similar situation whereby I need to send an email to the correct office based on the country chosen. But what I'd really like to do is keep the 2 letter country code that the default webform country selectbox uses.

Is there any reason why I can't just simply bypass the conditional email, leaving it blank. and call the hook_webform_submission_insert and then run a conditional statement based on the saved country and then use drupals in built mail functions like drupal_mail() to email? Although not an ideal solution does seem like a way to get around having to put email symbols in the select box.

function hook_webform_submission_insert($node, $submission) { }

Thanks

#44 D6 Help

Submitted by Mark (not verified) on Tue, 05/10/2011 - 09:52.

How would I go about getting this to work in Drupal 6 with webform 3?

#45 A module/patch

Submitted by Ken Hawkins (not verified) on Mon, 06/27/2011 - 04:51.

There's a conditional formatting module/patch in the making over on Drupal.org that does all this quite well.

(Guards against spam, protects DB keys, and is very very flexible.)

http://drupal.org/node/687606#comment-4454712

#46 Recipient email addresses still exposed?

Submitted by Arne (not verified) on Tue, 08/09/2011 - 21:36.

Are conditional recipient email addresses still exposed in the page markup when using the current Webform module 7.x-3.11?

If not is there a workaround yet?

#47 #42 worked well for me

Submitted by Paul T (not verified) on Wed, 01/11/2012 - 13:17.

The solution provided by Ran B (thanks!) in post #42 worked really well for me.

Previously I tried the fix suggested by post #32 'webform_select_email.zip' but this seemed to cause errors in my database and gave me quite a scare.

I am working on Drupal 6.22 with Webform 6.x-3.9

Has anyone tried this solution with and updated there webform version? Is the solution still stable?

A note for any drupal newbies like me the php that Ran B provides starts:

<?php
function [the_custom_module_name]_mail_alter(&$message) {
?>

However you want to replace [the_custom_module_name] with the name of your module without the square parentheses [ ]. so mine starts:

<?php
function sitename_overrides_mail_alter(&$message) {
?>

Also bear in mind that the closing 'question mark then greater than' symbols are required to post code in this blog. When you write your module it seems to be best practice to leave out the closing 'question mark then greater than' symbols.

This blog was a godsend when working on this issue. Many thanks.

Post new comment

Warning

I strongly encourage and welcome links and feedback. However, this site is moderated and comments with inappropriate links are rejected. Please do not post a one-line "Me too" or "Great post!" comment just so you can link to your site. Thank you for your understanding.

Your name:

E-mail:

The content of this field is kept private and will not be shown publicly. If you have a Gravatar account associated with the e-mail address you provide, it will be used to display your avatar.

Homepage:

Subject:

Comment: *

Web page addresses and e-mail addresses turn into links automatically.
Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.
Lines and paragraphs break automatically.
Use to create page breaks.

More information about formatting options

Notify me when new comments are posted

All comments

Replies to my comment

Non-Unique Conditional Email Addresses with Webform.Module

Comments

#1 alternative

#2 Interesting Method

#3 Thanks loads to both of you

#4 Devel.module and dpm() are great!

#5 Great, many thanks. Will

#6 How I can use this code in

#7 This is interesting. Thanks

#8 Seems a litle dificult to do,

#9 additional-processing method

#10 Additional processing with multiple addresses

#11 looks very useful

#12 Would there be a way to

#13 Default

#14 How rude of me, I didn't

#15 This is genius! Great work!

#16 reducing the number of emails

#17 Default Behavior

#18 Thanks for all the

#19 Replacement isn't working

#20 I first tried the module

#21 Field identifiers, dpm, etc.

#22 Thank you once again for your

#23 Puzzling

#24 One possibility...

#25 What now? Code re-write!

#26 Ill News

#27 Some feedback from Webform 3.x

#28 3.x Beta

#29 Anna, Eric - any progress?

#30 Webform 3

#31 CR

#32 GOOD NEWS

#33 Good News Indeed!

#34 Need help :)

#35 Update

#36 Webform Additional Processing

#37 Hi Erik, I would be

#38 A Module to Address This...

#39 Webform Additional Processing

#40 Thanks for your efforts to

#41 Kludge away!

#42 A Simple Solution with Webform 3.x

#43 Email by country

#44 D6 Help

#45 A module/patch

#46 Recipient email addresses still exposed?

#47 #42 worked well for me

Post new comment

About

Contact Details

Content Tags

Recent comments

Popular content

Today's:

All time:

Activity Stream

Sun, 01/29/2012 - 22:31

Mon, 01/16/2012 - 10:43

Fri, 01/06/2012 - 07:54