I have a scenario on a site I'm building that looks like an error somewhere in uc_signup or uc, or the interaction between them. Forgive me if I've put this issue on the wrong module and guide me to the right queue if it's not for here.
The scenario is as follows. I get to the site as an anonymous user. I follow the uc-signup steps into the uc module, filling in email, three required profile fields, credit card details on the checkout screen.
I review the order.
I submit the order.
The order confirmation email arrives just fine. As does an email to the administrator letting them know an account creation request is pending - this site is configured to require admin approval on all new accounts.
But on the order confirmation screen I get two messages. The notice that my account was created, but no email was sent, and then a failure from mail.inc about being unable to send an email.
See the attached png for a screen shot.
Over a few hours of sitting in the debugger and working my way through the call stack, the problem is quite clear. The "Addresses" field in the "uc_order_email_invoice" trigger is empty.
[#settings] => Array
(
[from] => admin@myfabulousexamplesite.com
[addresses] =>
[subject] => New Order at [store-name]
[template] => admin
[view] => admin-mail
When drupal_mail fires, there's no to address.
But why it is blank has been elusive.
I have included a debug_backtrace() from within drupal_mail()
// Optionally send e-mail.
if ($send) {
$message['result'] = drupal_mail_send($message);
// Log errors
if (!$message['result']) {
watchdog('mail', 'Error sending e-mail (from %from to %to).', array('%from' => $message['from'], '%to' => $message['to']), WATCHDOG_ERROR);
drupal_set_message(t('Unable to send e-mail. Please contact the site administrator if the problem persists.'), 'error');
$backtrace = '<pre>'. print_r(debug_backtrace(), true) .'</pre>';
file_put_contents('c:\uc_signup_1.txt', $backtrace);
}
}
and attached a screen shot of the error. Hopefully that's enough for you to ask some good follow-up questions or route me to another module to report this issue.
I believe it's with uc_signup and the handling of how it populates fields, but I'm not 100% certain.
Another interesting piece of this is in the last screen shot. When running multiple attempts at causing this failure back to back, I found that the session variables contained a combination of my first attempt (failtosendemail@) with my current attempt during the debug session shown (anotheruser@).
My gut says this is complicit - that somehow the combination of the old and the new email address in the session variable is behind the empty email address on the attempt to send mail.
| Comment | File | Size | Author |
|---|---|---|---|
| 2009-12-15_005239.png | 16.06 KB | scott.mclewin | |
| uc_signup_1.txt | 39.1 KB | scott.mclewin | |
| 2009-12-15_003115.png | 9.84 KB | scott.mclewin |
Comments
Comment #1
scott.mclewin commentedNot your problem, which you probably suspected but were too polite to say. :) I tracked this to it's rather embarrassing root cause. No "store email" defined. The problem was not with sending out the registration message to the new user - that message was not sent because the action was ordered after sending out a message to the store email to alert the store owner to a new order, and that message was the one that failed.
There are two patches within UC itself that will make this condition clearer. I'm rolling those now and submitting them.
Closing issue. Hope this issue helps somebody else who has created a similar problem for themselves...
Comment #2
ezra-g commentedActually, I hadn't looked into it but thanks for following up here, and I look forward to your UC patches!