We get quite a few calls from customers who have problems placing online orders. Basically, either the product doesn't appear in the shopping cart on the order page, or the shopping cart applets are greyed out. Interestingly, the ushopcart.class file set to the "count" parameter (actually on the product page) seems to work.
Best we can tell, most of the customers having problems are using IE4, with a few using IE5. Netscape seems to work fine. We have IE5 and Netscape installed here, and can't seem to recreate the problem. We are using UShop 2.0.
Thanks for any feedback you can offer. The URL of the site is http://www.safepets.net.
I'm having the same problems processing orders with IE.
It looks like you are seeing a new problem that has to do with the way IE is caching applets. Apparently the newer versions of IE get confused when some applets are loaded from a public URL and other are loaded from a secure URL. So contrary to what is on our "Making Transactions Secure" page.... The key is to use the full URL of your PUBLIC server for the CODEBASE of your applets on your order.template page.
That is, if you currently are using a secure URL for the CODEBASE on your order.template page, such as:
Try changing it to load the applets from the public URL instead, such as:
This should solve the problem.
NOTE that transactions will still be secure providing you use the secure (https) URL when referring to the scriptpath in your Order applets and your Order Reader applet.
Microburst Technologies, Inc
I use the full path to the applet from the https order page. MSIE still tells me that some of the items loading on that page are not secure and do I want to continue loading the page. I can't quite figure out what's wrong. Should I put all the .class files in the cgi-bin to stop this? Right now I have all the .class files together on the public server directory. (no, I didn't create a subdirectory named classes--my store is very small) my uShopOrderButtonCGI.class gives the full path to the the class file in the codebase parameter. and then the order page gives the full path back out to the uShopOrderDeluxeCGI.class in its codebase parameter too. I'm using MSIE 5.00.2919.6307.
To get rid of the "some items may not be secure" message, there are two things to check:
1) First, make sure that all of the images that you are using on your secure order page are loaded from your secure server (beginning with https). If not, then that may be causing the problem.
2) If on your secure order page, only the uShop class files are being loaded from your public server - then you may want to look into Option 2 and 3 below - which allow you to use the secure URL as the codebase of the applets on your secure server. See below.
If you are using IE5 and are having problems with the applets on the secure order page loading, then there two things to do based on how you access your secure server. That is, do you access your secure server via your own secure certificate? Or do you access your server by using your web hosting providers secure certificate? See options below:
OPTION 1: If you access your secure server via your own secure certificate, then this means that you can access your site by just putting a "https" in front of the URL....just like you can our our site:
or Secure via
Apparently IE handles caching of applets of such similar URLs weird. To correct the problem, just be sure to use the PUBLIC URL (beginning with http) as your codebase setting on the applets on your secure order page. See the "January 19th" note on the following URL for more information about this:
OPTION 2: If instead of having your own secure certificate, you use your web hosting provider's secure certificate to access your site - such as:
Your Public URL
Your Secure URL (using your provider's certificate)
- then you can just use the SECURE URL as the codebase of the applets on your secure order page and that should correct the IE loading problem.
OPTION 3: Or if you do not understand the above two options, you can always fall back on this option which will work regardless of how you access your secure server. That is, only put the order applet on the secure order page - do not also put the shopping cart applet on the order page. You can then use either the public or the secure URL as the codebase of the order applet on your secure page. Either would work. -- As for why the shopping cart applet causes problems when that is also on the secure order page, who knows? It appears to be a problem with how IE handles applets that were already cached (that is, the shopping cart applet will have already been cached from your regular store pages). This is why the above options (OPTIONS 1 and 2 will also work) - since they also get around the caching problem.