Zen Cart Logo
Forums / Bug Reports / sending order emails....

sending order emails....

Views: 853

Results 1 to 5 of 5
16 Jan 2016, 3:49 PM
#1
carlwhat avatar

carlwhat

zennedOut

Join Date:
Nov 2005
Location:
los angeles
Posts:
2,967
Plugin Contributions:
8

sending order emails....

my experience says there has to be a better way......

in includes/modules/checkout_process.php there is the line:

//send email notifications
$order->send_order_email($insert_id, 2);

in addition, there is also a flag in the configuration table called:

EMAIL_FRIENDLY_ERRORS

if the flag is set to false and the email fails, the customer gets a weird message, items remain in the cart, the customer submits the order again, and the processing of payments does not happen.

obviously the developers have taken this situation into consideration as that is why the flag is there.

BUT, if the flag is set to false and things are running smoothly for an extended period, and then emails start failing due to the web host changing something on the mail configuration, and double orders start coming in without payment information (as customers rarely report errors) AND there are no logs in the log folder, how would someone maintaining the site know that the email failing is what is causing the troubles?

perhaps i am just venting, but to me, it would have been AWESOME to at least have generated a log, or better yet to move the sending of email notification much further down the order process.

rant over. thanks.

19 Jan 2016, 9:37 PM
#2
drbyte avatar

drbyte

Sensei

Join Date:
Jan 2004
Posts:
63,513
Plugin Contributions:
176

Re: sending order emails....

carlwhat:

there is also a flag in the configuration table called:

EMAIL_FRIENDLY_ERRORS

if the flag is set to false and the email fails, the customer gets a weird message
That EMAIL_FRIENDLY_ERRORS switch was created to be used by the storeowner/developer to decide whether to display an ugly technical email failure notice on-screen, or to simply flag up a friendly message that says "sorry there was a problem while sending the email".
Nothing more than that.

Your suggestion about taking further action if outgoing emails are failing is good.
And it also introduces a chicken/egg situation: most of the time when that sort of problem exists the first thing the storeowner asks for is to be emailed when the problem occurs ... but since it's a problem with email, it could trigger an endless loop.
So the only safe option then, which is what you suggested, is to simply log it to a file. That would at least log the existence of an email problem even if there is no other PHP-level error that's getting logged.

20 Jan 2016, 5:53 AM
#3
carlwhat avatar

carlwhat

zennedOut

Join Date:
Nov 2005
Location:
los angeles
Posts:
2,967
Plugin Contributions:
8

Re: sending order emails....

dr b,
first off, thanks for the response!

second, i think the switch is a bit more than what you suggest. as the description states:

"Setting this to false will display PHP errors and likely cause the script to fail."

and forget about "likely...." the script will no doubt fail. as we look at the code from the function zen_mail:

if (EMAIL_FRIENDLY_ERRORS=='false' && $ErrorInfo != '') die('<br /><br />Email Error: ' . $ErrorInfo);

in my experience, the die statement will cause all additional processing to cease. IMHO, not a good thing.

while i'm dealing with highly customized carts here, i can only state that i believe at this point in a vanilla install, ZC has created the order, but has not cleared the cart (it has certainly not cleared the cart in my install). in addition, the after_process function for the payment module has not executed. again, for my installs, another NOT so good thing.

i can only agree with you that this situation is NOT a bug per se, as the system operates as designed/coded. i just think the design is a bit flawed.

as i previously stated, and it sounded like you agreed, i think this flag should indicate whether to log the error using the AWESOME logging feature of ZC without the die statement. in this way, the store owner/developer can see the error (or not) and the script can continue to function (assuming the logging does not kill the process).

while an interesting idea, i never intended to suggest to email the store owner about the error; merely to log it in the same manner that PHP errors currently get logged (without hopefully killing the script; but even if they do, IMHO it would be better than the current design).

best