JS snippet causes issue in One Page Checkout
Printed From: ProductCart E-Commerce Solutions
Category: ProductCart
Forum Name: Using ProductCart
Forum Description: Running your store with ProductCart
URL: https://forum.productcart.com/forum_posts.asp?TID=3611
Printed Date: 01-March-2025 at 3:27pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: JS snippet causes issue in One Page Checkout
Posted By: Guests
Subject: JS snippet causes issue in One Page Checkout
Date Posted: 10-April-2010 at 12:42am
I'm leaving this for the record in hopes that if, more like when, someone else runs into this, they'll be able to find this post.
I just wasted most of my day today trying to debug an issue with One Page Checkout no longer letting customers using IE 7 or IE 8 get past billing information in the OPC process. Couldn't get an error message of any sort to give us a clue.
Now, we had made several customizations to it, so that was suspect. Spent a good deal of time first trying to confirm under what conditions the process would fail, and determined it was IE 7 or 8 on either PC or Mac. Then spent a good deal of time code comparing "out of the box" PC 4.03ba with this site and moved all of our customizations out one by one. Still had the problem. Finally moved on to header and footer files, and finally found that a JavaScript snippet added for the client to enable them to track customers from their live support interface was the culprit.
The live support service is called Citricle LiveSupport, the snippet is their "Listener Code". This JS clashed with the AJAX in the OPC such that the billing info could not be saved and the customer was stuck at this point in the process.
Thing is, it's not uncommon for many various JS modules to use certain common names for things and therefore conflict with each other.
We ended up conditionally including in footer.asp the "listener code" only on pages other then onepagecheckout.asp.
There's a good chance that this sort of thing will come up for someone else using other 3rd party JavaScript on their site. So, my advice would be to first suspect any 3rd party JS you've added recently and one by one eliminate them from the equation and test again after removing each one.
Ain't IT fun?
|
Replies:
Posted By: Matt
Date Posted: 10-April-2010 at 1:15am
Hi Sean, thank you for sharing. Sorry to hear about that. I have been there myself at one time or another.
One Page Checkout uses jQuery for AJAX (as you already know). What I wanted to mention is that jQuery has a "no-conflict" mode. If you run into a conflict that you cannot work around, then jQuery no-conflict mode may help. That is, it allows you to change the "$" shortcut, which was likely the conflict.
|
Posted By: Guests
Date Posted: 10-April-2010 at 1:32am
Hi Matt,
Thanks for renaming the thread. I wasn't quite sure what to name it so that folks could find this in the future.
I'll be sure to use the "no-conflict" mode in JQuery if I run into a bind like this again, but I'm sure most PC users and designers would have no idea how to do that, so this might be an easier way for them to try to debug such an issue.
Indeed, the "$" has been a butt biter on more than one occasion ;-)
Thing is with these 3rd party JS calls, it's not so easy to see what JS they have on their end.
I should also share how to conditionally include such stuff except for on the OPC:
<%
If InStr(Request.ServerVariables("SCRIPT_NAME"),"onepagecheckout.asp") < 1 Then
%>
<!-- My 3rd Party JavaScript Snippet Goes Here -->
<%
End If
%>
|
|
Posted By: RobertZ
Date Posted: 12-April-2010 at 1:18am
Personally, the Internet Police should issue a law stating no person should be allowed to use IE, under any version or circumstance.
This should free up about 2000 hours on each webdevelopment.
On our site we have 1 header/footer for everything except IE, where we have 1 for V6, one for V7 and 1 for V8. I'm just waiting for IE9 to come out that handles everything different to V8 and every other browser in the world.
|
|