Closed (won't fix)
Project:
Ubercart
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
7 May 2009 at 02:51 UTC
Updated:
13 Feb 2014 at 18:01 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
rszrama commentedNot sure, looks like it's lying. : P
Double-check your server's e-mail settings and post back if you can track this down. If you need further support, please refer to the support forums.
Comment #2
agerson commentedAre these the global email settings for the site or does ubercart have an email settings of its own that might cause this?
Comment #3
agerson commentedI would also add that the order confirmation email is delayed by a few minutes, while other drupal emails appear right away.
Comment #4
rszrama commentedI guess I was thinking something more along the lines of server e-mail settings. If e-mails are working for the site, I don't know what to tell you. Ubercart is sending e-mails through the normal Drupal channels, so there's nothing really special about the e-mails Ubercart would be sending out.
Comment #5
shiroitatsu commentedI have a similar problem, but it is activated by changing the settings for order confirmation mail in CA. Actually even saving the settings without changing anything cause the error which would lead to think that something funny is happening there. Earlier issue about that.
Comment #6
Island Usurper commentedTry using the Devel module. It has a setting to let you log emails to watchdog instead of actually sending them. Make a test purchase, and see if there are any other emails or funky activity at admin/reports/dblog.
Comment #7
DanielJohnston commentedSubscribing. I'm getting this too.
Comment #8
DanielJohnston commentedQuick update: dblog shows message 'Attempt to e-mail invoice for order 2 to failed.' indicating attempt to send email to a blank email address. How odd.
Comment #9
paulnem commentedReceived the same message on my first attempt to purchase in cc debug mode. Email was sent however so it`s just an annoying error message as far as I see.
Where does the error come from and in what conditions does it display?
Comment #10
DanielJohnston commentedIn my case, the error happens whenever a user buys something, at the end of the purchase process, when it's meant to email an invoice to the user. For some reason it doesn't seem to be passing a destination email address across.
Comment #11
Island Usurper commentedBy default, an email is sent to the store administrator, whose email address is stored in the Store settings. It appears this is blank by default, so that might be the problem.
Comment #12
DanielJohnston commentedThat appears to be my problem. Don't know if it's everyone else's or not.
Comment #13
Island Usurper commentedThat's a setting that everyone should fill out, so I think this should be the way to deal with the issue. If it ends up being not the problem some people have, then they can post it here.
Comment #14
tr commentedI agree all these things should be filled out. With the huge number of menus and settings, these things are sometimes overlooked when first setting up Ubercart. Would a warning on the store status page be appropriate if the e-mail and store address is not entered? I've also been thinking that there should be an entry on the site status page admin/reports/status that gives an overall status for Ubercart - the line on the site status ought to be red if there are any red lines on the store status, and there should be a link to take you to the store status page for details.
Comment #16
mikejoconnor commentedThis seems to be a common problem, and I believe we should address it, since there are two other issues in the queue about it.
http://drupal.org/node/351103
http://drupal.org/node/337588
Here is a patch to throw a watchdog error instead of a customer facing error. In the future we should consider adding a hook_store_status() message.
Comment #17
frost commentedi get this error with rc6. the log entry is:
We do have an email address set up for the shop and the customer's email addrss does NOT have p tags in it (checked directly in sql), so the p tags are being added somewhere before the email is attempted.
I haven't tried the patch because from its description, it will only mask the problem.
I note that this p tag issue was mentioned in http://drupal.org/node/422518 where it was reported as fixed in beta5.
Comment #18
rszrama commentedfrost, I believe your issue is that your WYSIWYG editor must be active on the "e-mail to" field where you're setting up this e-mail. You must disable that and resave it to avoid getting the p tags.
Comment #19
fp commentedPerhaps the approach of using the default site email if the store email would be a good one?
Comment #20
frost commentedjust found your response, yes you're right, there were p tags there, i've removed them but havent tested yet, but am assuming that was the probelm
thanks!
Comment #21
Edzila commentedI have this problem also.
When an order is placed, the user receives the confirmation invoice via email. However when the admin updates the order status and checks the box that sends the user an email when the status changes, the email does not send. I just get the error:
Unable to send e-mail. Please contact the site administrator if the problem persists
My store IS properly configured with an email address...
I'm at a loss.
Comment #22
tr commentedRelated issue with some good suggestions for a fix: #374633: If no shipping address is requested, uc_order.ca.inc still tries to send email to delivery address
Comment #23
sobi3ch commented+1 works for me
http://drupal.org/files/issues/ubercart_mail.patch
Comment #24
YK85 commentedsubscribing, is this still an issue in the latest dev?
thanks!
Comment #25
tr commentedYes, users can still forget to enter their site's e-mail address, and users are still able to misconfigure WYSIWYG editors, and users can still use servers that don't have mail set up properly. I will eventually add something like I described in #14 to help users see if they haven't entered all required information, and #686988: uc_store_email_from() returns invalid From: header when store name includes non-ascii characters also adds e-mail validation which will help prevent the WYSIWYG problem.
Comment #26
trinin commentedI have yet to find a fix for this! does anyone have any really solutions?
Comment #27
sfyn commentedOK I have done some digging and found this code in the uc_order.ca.inc file, in the function uc_order_action_email_invoice:
$addresses = token_replace_multiple($settings['addresses'], $settings['replacements']); (line 1239)
I did some watchdog dumps of the $settings object:
Comment #28
sfyn commentedI fixed my problem by marking the product in question as non-shippable and entering an email address for the store.
Comment #29
mgiffordThis is a particularly annoying error as it's hard to grep for and it works! The order is complete so why is it giving an error message.
That being said there's stuff here to try which is good!
Comment #30
PlanetPHP commentedWhen looking in admin/reports/dblog I see that the to field is empty for the admin email, the user email has all the information and is received.
Comment #31
PlanetPHP commentedI think the problem for me was details of the store owner being missing, the admin page to enter these can be found here: /admin/store/settings/store/edit
Comment #32
ronnienorwood commentedWe got the error message when we put an email address that was not formatted correctly (ie. xxxx@xxxxxxxx.com) in the sender box but ALSO in the recipients box when you type in one or more email addresses then hit enter and the cursor goes to the next line. Press the backspace key to make sure the cursor is sitting at the end of the last email address. This may have been what DanielJohnston was alluding to in #8. How odd indeed :)
Comment #33
samdds commentedI had the error as well, but I solved it to reset the conditional actions (/admin/store/ca)
Comment #34
crystaldawn commentedThis problem has never been addressed although it has been acknowledged. It should be marked as a low priority bug since the error is extremely common and will result in a lot of issue queues (if it hasnt already which it sounds like it has 3+ and thats more than enough to qualify as a bug imho). The proper way to handle this is to simply put an error message thats states the Admin email is missing and then tell the user how to fix it or at least give them a hint as to where to set this. It's buried in the menu and not easily found. It should be marked as a bug because if the dev is anything like myself, he only looks at bug reports and fixes those and this particular one is going on 2 or 3 years now as not being addressed, probably because it was not marked as a bug, but as a feature request which is incorrect. Its a flaw, a bug, not a request.
Comment #35
sean-gnu commentedHere is a patch to address a few errors I found in the file uc_order.ca.inc.
It appears that when needing to set custom options in the conditional action for emailing that errors crept in. Resetting the conditional action is not always desirable !
I experienced the <p> tag problem, even with the wysiwyg editor disabled, so this patch also strips out html tags in the recipients list.
Another issue in this file was the token replacement code. This seemed to be only partly implemented. So now the "from", "recipients", "subject" and "message" should all work even when customizing the action.
When editing the conditional actions from field, you can now have "[store-name]" <[store-email]> .
I have added a drupal_set_message when a "from" address is not specified (in the ca or the store settings).
Also added a watchdog info to log successful emails sent. I feel it is important to log both successful and errors when emailing invoices.
Comment #36
webchickSubscribing. Here's another one of those errors where I lost an hour of my life checking totally unrelated things due to lack of specificity of what was going on.
#19 seems like a very low-impact fix that would prevent many people from bashing their faces in the same way.
#35 is more ambitious. A couple of notes:
* If I'm not mistaken,
this will actually show up to hapless end users trying to place an order, while this is a message intended solely for site administrators. An alternative would be to implement hook_requirements which would flag an error in the admin status panel, and then change the language here to be more "Contact the site administrator"-esque.
* On this:
I believe you mean "use your site email address" (I could be wrong; I can't tell the context from the diff)
* Be careful about your coding standards compliance. There are a few tabs in there, for example.
Comment #37
webchickI guess another alternative would be to add another status check here:
That would be pretty eye-catching and people would be less likely to miss it if it was given the same importance as "Dude, you can't take credit cards until you fix this."
Comment #38
sean-gnu commented#19 - addresses a slightly different issue. It addresses the situation when the store-email address defaults to NULL when not set. This is good to include.
#35 - addresses email addresses within a conditional action. It is supposed to allow overriding the store-email address with another in the Action. This was very buggy. So now leaving the Action from field blank will default to the store-email - not the site-email. Combined with #19 patch this will then default to site-email.
Since this is a once off configuration setting - and IMO - i don't think its critical that the message is shown to the "end-user" as this will probably be the dev / tester anyway!
Yes - coding standards are very important, I will try to provide patches that adhere to them in future.
Comment #39
sean-gnu commentedCode highlighting one of the "bugs" found and fixed in #35:
function uc_order_action_email($order, $settings) {
.......
// Apply token replacements to from and recipient e-mail addressses.
$from = token_replace_multiple($settings['from'], $settings['replacements']);
........
$sent = drupal_mail('uc_order', 'action-mail', $email, uc_store_mail_recipient_language($email), $settings, empty($settings['from']) ? uc_store_email_from() : $settings['from']);
........
}
As you can see the original token replacement as stored in $from is never actually used.
Comment #40
sean-gnu commentedAnother highlighted problem area :
function uc_order_action_email($order, $settings) {
....
$addresses = token_replace_multiple($settings['addresses'], $settings['replacements']);
// Split up our recipient e-mail addresses.
foreach (explode("\n", $addresses) as $address) {
$recipients[] = trim($address);
}
.....
}
This assumes every line in the textarea is an email address. This means even if a line feed is entered an email will be sent to an empty recipient.
Comment #41
crystaldawn commentedWoo down with the nasty tabs! Thats my favorite rule in the standards docs lol. Cause no one in their right mind would use the editor I use (KDE's Kate, its f'n awesome :) ) and tabs look all wonky in it haha.
Anyways, why are there so many elaborate ways to fix this one? The only real "problem" I see is the store admin email field being blank. Simply dont allow the store to work until it's set (showing a link on where to set it of course), just like CC's. Then once that simple bug is fixed, move on to the more elaborate scenarios with CA's (which imho are separate issues anyways) and what not. But at the very least, lets get the original bug fixed first (the one thats been here for like a billion years). One step at a time is better than trying to steamroll the whole thing all at once.
Comment #42
tr commentedPlease re-examine the necessity of some of these changes now that #686988: uc_store_email_from() returns invalid From: header when store name includes non-ascii characters has been committed. Also please review #321633: Exclude textarea's widgets from WYSIWYG editors which should fix the WYSIWYG issue - commitment of that patch is pending review from people who use WYSIWYG editors.
When the above two issues are both fixed, I would like to proceed with what I outlined in #14. This fixes things up top rather than having to patch every place that uses the store e-mail address.
Comment #43
alb commented/admin/store/settings/store/edit
there is a tab Contact Settings;
if field email is filled, no more messages error;
problem is that in this section there are other tabs;
how can I superadmin assign only the tab's Contact Settings at one role (the shop's owner)?
_________________________
Other:
you have resolved problem regards permissions?
when enabled for to see the menu's item si necessary enable access administration pages, but so all the
administer's menu is visible and not only the item of permission enabled
Comment #44
askibinski commentedWell this took me an hour to figure out...
Sure hope one of the checks gets comitted soon.
Comment #45
stevejohnson commented#40 Sean-gnu, is correct. Having a cr/lf or any blank lines after the last email address in a conditional action ca will result in this error message--getting rid of the "enter" at the end of the last line fixed this and now my users don't see an "e-mail not sent" error nor is my log filled with the ca/mail error messages.
This should be a bug as "empty lines" should not be treated as email addresses. Ever.
Comment #46
totkoo commentedI'd been battling with this for the past hour, I removed the period from the end of the store name "ABC Dist." and the problem has gone, email are now sent. I hope that helps someone.
Comment #47
asb commentedsub
Comment #48
tr commentedMade changes similar to #39 and #40 in both the 6.x-2.x and 7.x-3.x branches.
Comment #49
mayur.pimple commentedHi
im also facing the same problem.
but mail is sent by the system , why show the error message .
Comment #50
Jey.keu commentedThanks. #43 works for me.
Comment #51
tr commentedRestoring status/version/component.
Comment #52
JonasK commentedThanks, #45 solved my problem
Comment #53
landike commentedPeople, looks like I have similar issue. So to not populate duplicate tickets, I ask you here:
Drupal 6.20; php 5.3; Ubercart 2.4
uc_order.info:
====
; Information added by drupal.org packaging script on 2010-08-11
version = "6.x-2.4" ; core = "6.x" ; project = "ubercart" ; datestamp = "1281551792"
====
When i make my order, it is ok, invoice email sent to user, but Drupal is trying to generate this code twice:
uc_order.ca.inc:
and as result
$recipients first time is enmpty, and after is ok. And this code:
Gives me an error on UI:
So what I did: I added additional condition for sending email:
uc_order.ca.inc. uc_order_action_email_invoice($order, $settings) - ~line: 1252-1254
This FIX works for me, BUT I AM WONDERING about ubercart 2.x, cause latest release is on my Client production site. And I planned to rollout contributed module.
Please tell me if this is BUG at all, and when it will be fixed in future release.
Comment #54
drupalfever commentedWhen an order is complete, Ubercart sends an e-mail to the customer and another one to the Store Owner. If your test customer is getting the e-mail but you still see an error message, it means that you forgot to configure the Store Settings.
You have to go to the following address on your website:
http://YOUR_WEBSITE/admin/store/settings/store/edit/contact
Replace YOUR_WEBSITE with your website address.
There you will be able to add your e-mail address. After you save this setting the error message should go away and you should start receiving two e-mails every time you complete an order.
Comment #55
asb commented@eliasb: As it was mentioned several times before, this issue is not limited to a missing and/or misconfigured shop contact configuration.
And, by the way, Ubercart is actually sending the e-mails, to be precise: multiple duplicates.
#644538: Duplicate order notification e-mail, and duplicate stock decrement, #881606: Paypal WPS only works with the primary e-mail address for a Paypal account, et al.
Comment #56
longwaveSo, is this still a problem in 6.x-2.x-dev? (ignoring the duplicates issue linked in #55, which is being dealt with separately)
TR's commits in #48 sound like they should have fixed this; can someone who previously posted in this issue re-test with 6.x-2.x-dev and let us know whether it is fixed or not?
Comment #57
longwaveOK, so there's still the issue of not having set up a store email address. I think the store status table is the best place to show this, but what about also setting a sensible default when uc_store is installed? We could use the email address of the uid 1 account.
Comment #58
DTB commentedFirst, sorry for poor english... and if duplicate post.
I find in wathcdog the mail error when user checkout complette.
Previusly, i added two mail adress to "Trigger: Customer completes checkout" in store administration...
Unfortunaly, press ENTER after write two mail address, and uc strore 1 empty line...
WHEN user checkout complette, and sending admins mail notification, always generate error to display and watchdog.
I debug all stored variables and settings, and I found the problem just described, STORED EMPTY LINE in ca_predicates table in actions field.
The error prevention? Always watching what is the number of recipients, and if not equal to 1, then each line must verify that the value is not empty.
Now, the code (uc_order.ca.inc, -> function uc_order_action_email_invoice
Rather, the following code should be used:
foreach ($recipients as $email) {
if($email){
$sent = drupal_mail('uc_order', 'action-mail', $email, uc_store_mail_recipient_language($email), $settings, empty($settings['from']) ? uc_store_email_from() : $settings['from']);
if (!$sent['result']) {
watchdog('ca', 'Attempt to e-mail invoice for order @order_id to @email failed.', array('@email' => $email, '@order_id' => $order->order_id), WATCHDOG_ERROR);
}
}
}
Comment #59
tr commentedComment #60
sukr_s commentedI had the same problem and identified this happens perdictably when the validation during checkout fails i.e. the user does a submit and the validation fails (like missing mandatory entries), then when he corrects the errors and submits the order, the email sending fails.
attached is a patch that solves this issue.
------------------------
http://www.drupalfx.com
Comment #61
royerd commentedI was seeing this issue for some orders and not others. Very strange since I could find no pattern. I was able to replicate the problem simply by going to "view invoice" and trying to email the invoice to myself. I would get the error on some invoices and not others.
It turns out that the problem was in my mime mail settings. I had not checked the box for "Use Mime Mail for all messages." When I checked that box, all of my emails of invoices went out.
This problem was of course affecting the conditional actions emails since those invoices are sent to both customer and admin.
There must be something in those invoice templates that requires that one use mime mail. This explains why my contact form worked fine--but email of invoices were intermittent problems. I've seen other users describe intermittent problems with this, and I wonder if they should check this setting too. I will also post this comment over at Ubercart since I can't ever tell if Ubercart is supported here at drupal.org or over at ubercart.org.
Comment #62
gillisig commented#60, Skukr_s identification was the same as the problem I was experiencing and his patch seems to have worked.
Thanks!
Comment #63
sukr_s commented@s2sz: Would be great if you can set the status to "reviewed & tested by community". This will help in getting the patch to into the core module
Comment #64
gillisig commentedComment #65
Island Usurper commentedWell, I don't have a problem that the patch fixes. Causing a validation error on the checkout page doesn't prevent an email from being sent once checkout is completed, for my test site, anyway. The email address still shows up on the review page, doesn't it?
Comment #66
sukr_s commentedI dont' use a review page, it's a direct checkout, probably that's the reason for the error.
Comment #67
longwave@sukr_s: What module/code are you using to achieve that? Perhaps the fix should be committed there instead?
@s2sz: Are you also skipping the review order page?
Comment #68
sukr_s commentedI use uc_optional_checkout_review. I would really appreciate if you can integrate the very simple patch.
Comment #69
longwaveWhat happens if the user is anonymous? Is primary_email set correctly?
Comment #70
sukr_s commentedI don't believe that the mail will be sent for anonymous users. however we don't allow anonymous checkout and presume, review becomes mandatory if anonymous users are doing a checkout, unless there is a way to get the mail for anonymous users as well and set it in the order variable.
Comment #71
LEternity commentedI have the same issue. A fraction of my users doesn't receive the automated e-mail. (I can confirm that since I'm set up to receive a copy on every e-mail...)
Comment #72
royerd commentedThat's not a really valid test since users can be wrong about not seeing their email--it could go into junk mail.
Comment #73
gillisig commentedI'm not skipping the review page but I do not display which e-mail the order info is being sent to the user during checkout so it is not displayed during review for me. And I also don't allow anonymous checkouts.
Comment #74
LEternity commentedWhat I meant is that I don't get 30% of the e-mails either and they're not in my junk mail folder...
Comment #75
yesct commentedI found the comment #45 to help. One of my site owners had edited the emails in the conditional action and left a blank line in the text area.
Comment #77
longwaveThis issue is very confused with lots of conflicting reports and possible causes for this error. What seems to be the primary cause for many people - blank lines in the recipients text areas - was fixed by TR in #48.
#1305516: Add uc_store_email() function to standardize store email address will improve the code so a sensible default is always available.
Other users who are still experiencing this issue should open a new issue with specific details.
Comment #78
Lucience commentedThank you! #33 solved my Problem ...
Comment #79
shahidbscs commentedHi,
I have solve this problem by just setting on this page.
yousite/admin/store/settings/store/edit
in this page just unchecked this line check box
(Include the store name in the from line of store e-mails.)
Image of this also attached with this post.
It work for me. just try it because some server not support this so this error show on page.
I hope this will work for you.
Thanks,
Shahidbscs
www.moralgroups.com
Comment #80
tr commentedRemoving tags.
Comment #81
lancewig commentedThis was my issue. It started with CK editor putting in P tags in "Store Administration" >> "Conditional Actions" >> "E-mail customer checkout notification" and then under 'Actions" and "Recipient" Then when I shut that off I didn't check that the curser was on the second line. Once you back up to to last text on the first line ( [order-email] )with no spaces, you can save and it should work.
Comment #82
MtRoxx commentedI am still receiving the error.
I need to get past this error. For now I have disabled the E-mail admin checkout notification and created my own notification when content was added to the site. Works like a champ. I do not have the pre approval, but I can log into the system and check it myself. Not a great system, but a good temporary one.
Comment #83
langelhc commentedHi,
I just would like to write what happend in my case, if someone else arrives here trying to resolve this error message,
I found this error when I use the same emails in the store and for the user who buy a product in the store, this look like if one email can't be the 'from' and the 'to'(destinatary), so I just change for differents emails and works fine for me. But I think the message must be differente, more specific, something like, 'hey, you are using the same email'.
Comment #84
caktux commented#45 solved it for me using 6.x-2.11, removing an empty line in the recipient's conditional action.
Comment #85
keithm commentedThe problem in #45 is still active as of 6.x-2.13. Removing an empty line in a CA usage of "Action: Email an order invoice" solved it for me.
In #77, longwave writes "What seems to be the primary cause for many people - blank lines in the recipients text areas - was fixed by TR in #48." Unfortunately this appears to be mistaken since the problem persists in 6.x-2.13.
Comment #86
longwaveAgreed that this does seem to still be an issue in that particular action in 6.x-2.x, reopening.
Comment #87
tr commentedPeople have used this issue as a dumping ground for all sorts of unrelated things that can eventually lead to an "Unable to send e-mail" message. So much so that it's not clear what anyone is talking about at this point.
@keithm: Please open a new issue for this problem, as requested in #77, and please provide details for how to reproduce the problem.
The part I fixed in #45 was in the function uc_order_action_email(), which was the subject of the original issue. I did not do anything to uc_order_action_email_invoice(), which controls the action mentioned by @keithm in #85.
This is why we need a new issue.