Warning: Invalid argument supplied for foreach() in webform_submission_send_mail()

I just beat my head on my desk all morning with this problem, but I think I've found--and corrected, no less--the issue!

It seems that when saving email notification settings, the 'extra' column (used for storing information about component email mappings) isn't getting properly emptied when using a custom email address.

Line 518 of the webform_email_edit_form_submit() function is to blame, I believe.

  509  foreach (array('email', 'from_name', 'from_address', 'subject') as $field) {
  510    $option = $form_state['values'][$field . '_option'];
  511    if ($option == 'default') {
  512      $email[$field] = 'default';
  513    }
  514    else {
  515      $email[$field] = $form_state['values'][$field . '_' . $option];
  516
  517      // Merge the email mapping(s) into single value(s)
  518      $cid = $form_state['values'][$field . '_component'];
  519      if (is_numeric($cid) && isset($form_state['values'][$field . '_mapping'][$cid])) {
  520        $email['extra'][$field .'_mapping'] = $form_state['values'][$field . '_mapping'][$cid];
  521      }
  522    }
  523  }

When $field = 'email' and $option = 'custom', this line still adds any information in the field mapping elements to the 'extra' array if $form_state['values']['email_component'] is numeric. Really, it shouldn't be checking 'email_component' if we've chosen to use 'email_custom'.

The side effects are that webform_email_edit_form_submit() populates $email['extra'] with information from the field mapping elements. Then webform_email_insert() or webform_email_update() writes that 'extra' data to the DB. Later, when webform_submission_send_mail() wants to send the notification, it simply checks that $email['extra'] is set (line 234 of webform.submission.inc), sees that it is, and tries to populate the email 'To' field from a whatever random info is sitting in $email['extra'].

My solution is simply to change line 518 of webform_email_edit_form_submit() from this:

$cid = $form_state['values'][$field . '_component'];

To this:

$cid = $form_state['values'][$field . '_' . $option];

Then 'email_component' is ignored when $option = 'custom'.

EDIT

You must also re-save the email settings for any Webform email that should use a custom email address but has data in the 'extra' column of 'webform_emails'. For me, this was all the emails I edited after upgrading Webform to 7.x-4.0.

The patch above should keep bad data from being written to the DB when saving email settings, but won't do anything unless you re-submit '/node/%nid/webform/emails/%eid'. Alternately, you could probably remove the data in the 'extra' column of 'webform_emails' for any record where 'email' is an email address instead of a component id. Don't alter the DB directly if you don't know what you're doing.

I have the same issue, attempted the fix in comment #1 with no change.

Let's set the Status back to active, since the suggested fix doesn't seem to work for everybody.

I'm suffering the exact same problem. Solution #1 did NOT work for me either.

See my edit on the original post.

I forgot to mention that, after making the changes, you must re-submit the webform email settings form so the faulty 'extra' information gets cleared out. I believe you could also just go into the DB table and empty out the 'extra' column instead.

The whole point of the patch was to save the correct data on form submission, so the patch changes won't do anything for you unless you resubmit the email edit form.

Let's see if the patch works with that added bit of instruction.

I swapped that line and re-submit the webform email settings == success.

Thanks guys, excellent report, sleuthing, and solution. I reproduced the problem exactly as described by the original poster and fixed the problem as @bjcooper reported. I've committed this patch to fix the problem per his recommendation.

Nitpicking, but there is a trailing space...

Geez, and I just downloaded 7.x-4.0-alpha8 yesterday.

Patch provides a most excellent fix. Thanks.

The patch didn't work for me. Please take a look at the attached file if it has been applied properly.

I patched it again using Cygwin and manually with the same results.

@Vako: Can you try just using the alpha9 version that came out a few days ago? It includes this fix.

I deleted the folder and copied over alpha9 version. Cleared the cache and got the same error.
Here are some info that might help:
Using Drupal 7.22
Webform 7.x-4.0-alpha9
Webform Report 7.x-1.0
Webform Share 7.x-1.2
Theme is Zircon

>>Solved<<

The solution was to delete the email setting and recreate it. Now everything's working fine. thank you!!

The solution was to delete the email setting and recreate it. Now everything's working fine. thank you!!

Ah yes, I think you could also just re-save the existing form and that would work also.

Sounds like an update hook need to fix this.

I don't believe the alpha10 release included an update hook for this, is it still planned? I would be happy to help code it, but I'm not familiar enough with Webform's internals to tackle the whole thing. Can anyone shed some light on what db problem is fixed by deleting the email settings and re-enabling?

With less than 0.1% of Webform installs running alpha8 at this point, I don't think we're likely to include an update that fixes this issue for users who were running that particular version. Resaving the e-mail settings can solve this problem for that limited number of users.