[Done v1.3.9a] Duplicate Orders/Order Confirmation

MODERATOR UPDATE: SEE FIX POSTED HERE: http://www.zen-cart.com/forum/showpost.php?p=847721&postcount=49

================
As described by Beerman:

Beer_man:

This problem is intermittent, and I have no firm idea why it happens...sometimes (perhaps 5% of the time) I get two order conformation emails (but payment is taken from the customers card only once).

There are more threads about the same issue, but I think this is the one that describes it best and lead to the solution: http://www.zen-cart.com/forum/showthread.php?t=70090

The fix is in post 30:
http://www.zen-cart.com/forum/showpost.php?p=532773&postcount=30

And post 31 fixes a typo in the same file (not related to the duplicate orders issue):
http://www.zen-cart.com/forum/showpost.php?p=532787&postcount=31

Note that this is not typical for paypal or any other payment module, and also that if you have duplicate orders all the time it's another issue.

I attached a zip to this post which includes a fixed version of /includes/modules/pages/checkout_confirmation/jscript_main.php , ready for Zen Cart 1.3.6-1.3.8 (and possibly other versions).

ZIP REMOVED, in favour of update posted here: http://www.zen-cart.com/forum/showthread.php?p=597034#post597034

I would like to confirm that this fix really works.

Installed it on a couple of shops over a month ago, one of which had intermittent duplicate orders daily, and there have been no duplicates since.

For those using Authorize.net: they will no longer issue test credit card numbers. They suggest you talk to your Merchant Services Provider. Mine is Total Merchant Services. I've sent them an email and will call them to get the numbers. Can someone tell me why these numbers are dangerous? If I can be convinced there is no reason to fear posting these numbers, I'll post them here so the next poor bastard won't have to go through hell to test the fix.

P.S. I should have said 'Thank You!' for this fix!

I don't understand anything about your Authorize.net comment, but I think it's NOT related to this fix/thread!

P.S. I should have said 'Thank You!' for this fix!:smile:
(although I wonder if the fix does what you expect it to do, after reading the rest of your reply...)

The default tpl_check_confirmation_default.php, jscript_main.php for it seems confused to me.

If you look at the resulting <form> code, you'll see there is no input type="submit" on the form. Instead, there's one non-hidden input of type="image". That kind of input has an event "onclick", not "onsubmit". The form would have an onsubmit event, and that's how the jscript was tied in - except that there's only a default implied submit.

Perhaps not all browsers behaved the same and that's why the jscript had the submit inside it?

 
<form name="checkout_confirmation" action="[URL]https://www.myshop.com/shop/index.php?main_page=checkout_process[/URL]" method="post" id="checkout_confirmation" onsubmit="submitonce();"><input type="hidden" name="SecurePayCOM_cc_owner" value="Daniel Cernese" /><input type="hidden" name="SecurePayCOM_cc_expires" value="1008" /><input type="hidden" name="SecurePayCOM_cc_type" value="Visa" /><input type="hidden" name="SecurePayCOM_cc_number" value="XXXXXXXXXXXXXXXX" /><input type="hidden" name="SecurePayCOM_cc_cvv" value="426" /><input type="hidden" name="zenid" value="879e38df3c25fd87d7f6325cd738407f" /><div class="buttonRow forward"><input type="image" src="includes/templates/template_default/buttons/english/button_confirm_order.gif" alt="Confirm Order" title=" Confirm Order " name="btn_submit" id="btn_submit" /></div>
</form>

Perhaps IE7 (and others) now don't kick off the onsubmit if the the event is really onclick? I'm not getting any multiple-click prevention, I haven't tweaked this except to remove the document .submit inside the javascript as suggested.. ..and the form still gets submitted (some how).

I'm still investigating. I need to read up a little more on forms, submit, and input types to understand why this is not working.

dhcernese:

If you look at the resulting <form> code, you'll see there is no input type="submit" on the form.Who says there is, or that it should be there?

dhcernese:

Instead, there's one non-hidden input of type="image".Probably there is, but what is the problem with that?

dhcernese:

That kind of input has an event "onclick", not "onsubmit".So?

dhcernese:

Perhaps not all browsers behaved the same and that's why the jscript had the submit inside it?I doubt that, but I actually was hoping a zen dev could explain why it's there.... I am quite sure it's a line added to debug the script, which was left there by mistake.

dhcernese:

I'm not getting any multiple-click preventionThat is strange. One thing that I am 100% sure of is that it prevents the IE7 duplicating clicks bug (user clicks once, but the form is submitted twice). I also haven't had any "normal" double click issues since, so I assume that part works too.

dhcernese:

I need to read up a little more on forms, submit, and input typesI can't deny that :P

If you say "I'm not getting any multiple-click prevention", do you mean you can still double click and generate duplicate orders that way after replacing the file? Or do you still get duplicate orders form customers? Or?

paulm:

If you say "I'm not getting any multiple-click prevention", do you mean you can still double click and generate duplicate orders that way after replacing the file? Or do you still get duplicate orders form customers? Or?I replaced the file, I can click ~5 times and get as many order and credit card transactions. I verified the file is replaced and correct simply by 'view source' in the browser on the confirmation page before clicking.> paulm:

I am quite sure it's a line added to debug the script, which was left there by mistake.I don't know how to do fancy quoting here. I think you are mistaken. I'll try to find time to continue investigating.

Performing the submit from inside the javascript is the preferred way to submit a form when doing extra processing (either validation or preventing extra click). So, the question is, why did it stop working. Removing the submit as you did is really just confusing the behavior. I'm using it removed for now, but I don't know if I'll ever figure this out before by real day job takes over :-)

In this case (how Zen Cart handles it) the form is submitted normally (without using js), that is why the after submit in the js script is not logical.

I have written several small scripts to test the behavior, one that works as desired (tmho) is this: http://www.beterelectro.nl/tests/submit-once/

I also wrote an alike script to test the duplicate submits in IE7, and they really do when using the original Zen code, but due to the way the the duplicate submissions are tested I won't post a link to it.

Perhaps IE7 (and others) now don't kick off the onsubmit if the the event is really onclickIt took some time (I am slow), but I think that I now understand what you are saying here.

I think the developers really meant onsubmit. The user clicks (which triggers the js onclick event) and that triggers the submit (which triggers the je onsubmit event). Some scripts use onclick to replace a submit button, but Zen Cart does not (which is a good thing! I think).

Zen Cart uses the onsubmit event to disable the submit button to prevent anyone to click that button after the form has been submitted.

paulm:

It took some time (I am slow), but I think that I now understand what you are saying here.

I think the developers really meant onsubmit. The user clicks (which triggers the js onclick event) and that triggers the submit (which triggers the je onsubmit event). Some scripts use onclick to replace a submit button, but Zen Cart does not (which is a good thing! I think).

Zen Cart uses the onsubmit event to disable the submit button to prevent anyone to click that button after the form has been submitted.Yes, I learned that. So why doesn't it disable my submit?

As an aside, I also read that the better way is to do an onsubmit="return submitonce();" and the submitonce does a disable;submit;return false

That way you control how/when the submit happens. That's why I thought the submit inside the javascript makes sense, but why it doesn't return false and use "return submitonce();" is beyond me. It might have to do with how the payment modules are processed.

paulm:

I have written several small scripts to test the behavior, one that works as desired (tmho) is this: http://www.beterelectro.nl/tests/submit-once/Hey, that works as expected! I noticed you took out the "<!--" and "//-->" convention, used for really old browsers that don't recognize the script tag. Could that be the difference? Just hunting.. However, you also used type="submit" and not type="image".. ..that's very different for some browsers.

paulm:

I have written several small scripts to test the behavior, one that works as desired (tmho) is this: http://www.beterelectro.nl/tests/submit-once/I copied your example, changed the type="submit" to type="image" and it no longer disables the submit, I can click many times within the 20 seconds! (I hope you don't mind me submitting to your test php)

dhcernese:

(I hope you don't mind me submitting to your test php)No problem at all.

dhcernese:

I copied your example, changed the type="submit" to type="image" and it no longer disables the submit,:shocking: that means you found another bug in the script I think.

I usually use CSS buttons when I setup a cart and then the type indeed is submit, not image. But a default Zen Cart install uses image buttons of course, and if the onsubmit is not triggered image buttons it obviously won't work....

The onSubmit works on image buttons, only the disabling does not work with image buttons for some reason (when using my sample code). :unsure:

I have no idea why, but for some reason this works with submit buttons, but NOT with image buttons:```
document.checkout_confirmation.btn_submit.disabled = true;

This however appears to work with both image and submit buttons:

var button = document.getElementById("btn_submit");
button.disabled = true;

New test page which should work for both image and submit buttons:
<http://www.beterelectro.nl/tests/submit-once/image.php>

I think I never spent so much time per line of code before :wacko:

paulm:

I have no idea why, but for some reason this works with submit buttons, but NOT with image buttons:```
document.checkout_confirmation.btn_submit.disabled = true;

>  
> This however appears to work with both image and submit buttons:
> ```
  var button = document.getElementById("btn_submit"); 
  button.disabled = true;

New test page which should work for both image and submit buttons:
http://www.beterelectro.nl/tests/submit-once/image.php

I think I never spent so much time per line of code before :wacko::clap:
:clap:
See, I'm not crazy. It really wasn't working as expected all along. I suspect some name/scope issue with "btn_submit".

Paul,

Have you now a definitive fix for this problem? I swear I'm bagging my head bloddy over this one.

I am using image buttons on the site (no, I didn't finish the css graphic button mod yet <sigh>).

Should I use file or db based sessions? It is a shared server, and I think there are frequent "lags" in performance. I don't know if this could be related to the problem.

-chaddro

All the duplicate orders really isn't good for business...

"sorry, your card was accidentally charged THREE times ... "

(

chadderuski:

"sorry, your card was accidentally charged THREE times ... ":shocking: I think cards should never be charged multiple times, unless the customer pays multiple times of course. That must be a design error in the software (but not a zen-cart error I would think).
)

Back on topic:

<snip></snip> (removing long unfinished explanation)

• do not use/instal CSS buttons for this, it's not needed

• do not use file based sessions. Not needed, and it will invoke other issues.

The fix that works on all buttons (image/ submit / css, and for all mentioned issues (there are at the least 3 with the original code)) has been discussed with dhcernese in this thread. I understand that it's confusing though, and hopefully I will find some time to pack it in a zip soon....