I have several products where if you click the add to cart button, some customers are taken to a page that says the cart is empty (it failed to add). Has anyone else had this problem? If the customers restart their computers, they can usually get it to work. Is this a javascript/ajax problem or is something else going on? I have only been able to duplicate once on my end…in the same session I couldn’t view the different images of the product (I would click on the mini thumbnail and the larger image wouldn’t change). I restarted my computer and everything was fine then. Any ideas what it could be?
With IE8 I am getting these two errors on your home page…
I am able to add to cart, and the image on the products does change in the preview window. When adding to cart, and returning to home page, the error below does not appear, but after closing browser and reopening your site on a new session of IE, the error below is shown again.
Don’t know what they are, but thought you should know in case this is the source of the problem
------------------------------
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
Timestamp: Tue, 6 Oct 2009 18:38:18 UTC
Message: Object doesn’t support this property or method
Line: 2
Char: 3523
Code: 0
URI: [url]http://s7.addthis.com/js/250/addthis_widget.js?pub=xa-4a2fc2951ea85231[/url]
Message: ‘type’ is null or not an object
Line: 934
Char: 4
Code: 0
URI: [url]HugeDomains.com
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
Timestamp: Tue, 6 Oct 2009 18:38:42 UTC
Message: Object doesn’t support this property or method
Line: 2
Char: 3523
Code: 0
URI: [url]http://s7.addthis.com/js/250/addthis_widget.js?pub=xa-4a2fc2951ea85231[/url]
Message: ‘type’ is null or not an object
Line: 934
Char: 4
Code: 0
URI: [url]HugeDomains.com
Here is where the core.js error is (line 934 is the first line):
notification.append(
'' +'
'' +' +
'
' +
'' + message + '' +
'
'' + data[k].title + '
' +
'
);
I have not modified this, so any help would be greatly appreciated…Thank you for your help [COLOR=“Red”]timst[/COLOR]!
Anyone? The core.js error is in IE only and is not related to the addthis error.
adding to cart worked for me on FF 3.5.3, you might just need to clear the cookies and restart your browser…
Would that explain what is going on with the customer carts as well? And with just certain products…for example Vintage Mickey Diaper Cake. As I said before, I have not been able to duplicate the problem I had, but my customers have. I assume you saw nothing wrong with the core.js code? Thanks Sno.
[quote name=‘rattle5’]I have several products where if you click the add to cart button, some customers are taken to a page that says the cart is empty (it failed to add). Has anyone else had this problem? If the customers restart their computers, they can usually get it to work. Is this a javascript/ajax problem or is something else going on? I have only been able to duplicate once on my end…in the same session I couldn’t view the different images of the product (I would click on the mini thumbnail and the larger image wouldn’t change). I restarted my computer and everything was fine then. Any ideas what it could be?[/QUOTE]
I’m having similar problems. I just went live today (10/27/09), and I’ve had customers call to tell me that when they try to add an item to their cart, they’re redirected to the cart page and told that their cart is empty. I have no idea how to even begin addressing this.
[quote name=‘Herbaria’]I’m having similar problems. I just went live today (10/27/09), and I’ve had customers call to tell me that when they try to add an item to their cart, they’re redirected to the cart page and told that their cart is empty. I have no idea how to even begin addressing this.[/QUOTE]
I’ve just effected the /js directory permissions-change steps enumerated in the CS-Cart help desk knowledgebase:
[URL=“CS-Cart Documentation — CS-Cart 4.15.x documentation”]CS-Cart Documentation — CS-Cart 4.15.x documentation
Too early to tell if it’s helped, but I’ll update this post if it works.
[QUOTE]I’m having similar problems. I just went live today (10/27/09), and I’ve had customers call to tell me that when they try to add an item to their cart, they’re redirected to the cart page and told that their cart is empty.[/QUOTE]
Yeah, we have had 2-3 customers call over the last month with similar claims.
UPDATE: I just checked & our permissions were incorrect (set as 644) for the /js directory, so I just changed to 755 and will see if that solves the problem. In fact, I am going thru every folder/file on our site to re-verify all permissions settings are correct.
[quote name=‘Struck’]Yeah, we have had 2-3 customers call over the last month with similar claims.
UPDATE: I just checked & our permissions were incorrect (set as 644) for the /js directory, so I just changed to 755 and will see if that solves the problem. In fact, I am going thru every folder/file on our site to re-verify all permissions settings are correct.[/QUOTE]
Changing permissions on my /js directory did not seem to resolve the problem. I guess I’ll try checking the permissions throughout my whole site as well.
In the meantime, here are some more observations/thoughts:
It appears to me that there’s some problem with session management in my current configuration.
I can’t claim to fully understand the database schema, but I keep seeing the following session-related tables increasing in size regularly, without any decrease ever:
cscart_sessions
cscart_stored_sessions
cscart_user_session_products
In my limited understanding, I would expect cscart_sessions to create one new entry per unique customer visit, but it seems to generate records much more often than that.
Sometimes it seems like the cart thinks two different people are logged in to the same browser at the same time. For example:
- I add a product to my cart.
- I’m redirected to the shopping cart page, which tells me I have 0 items in my cart.
- I click on a different product detail page.
- The mini cart tells me I do have an item in my cart: the one I just added in step 1.
- When I visit the cart page, it once again tells me I have nothing in the cart.
Might this be an issue with secure-vs-non-secure pages? The product detail pages aren’t secure; the cart page is secure (though I’m not sure why; to me, only the checkout page should be secure). In the preceding example, it’s as if the non-secure part of the site recognizes that my cart has items in it, while the secure part of the site doesn’t see the same cart.
Of course, I could be totally off-track here, but that’s the best I’ve been able to do trouble-shooting wise thus far.
Any help would be much appreciated.
After closing my store and deleting the records from the cscart_sessions table, why after an hour would it have 60+ entries in it?
More specifically, what is the exact function of that table, and why does it have activity when the store is offline?
For those using Windows and IE.
[url]http://articles.techrepublic.com.com/5100-10878_11-5030791.html[/url]
Go to “Internet Options” and change the “Privacy” to Medium or lower security.
Let me know if you still have problems adding item to cart after changing privacy settings.
If adding to cart is fix, I’ll probably have a solution.
My AOL customers are all complaining that the shopping cart empties when they click on checkout. However, they are able to add items to the shopping cart.
This will always fail on IE8 on 64bit Vista and most likely will also faill on Windows 7 since there has been no fixes/changes to CS-CART code.
[quote name=‘hykit’]For those using Windows and IE.
[url]http://articles.techrepublic.com.com/5100-10878_11-5030791.html[/url]
Go to “Internet Options” and change the “Privacy” to Medium or lower security.
Let me know if you still have problems adding item to cart after changing privacy settings.
If adding to cart is fix, I’ll probably have a solution.
My AOL customers are all complaining that the shopping cart empties when they click on checkout. However, they are able to add items to the shopping cart.[/QUOTE]
hykit,
Thank you very much for your input. I’ve been able to reproduce the problem consistently on one particular machine via IE8, but I’ve verified that its privacy settings were already set to medium.
Any other thoughts, anyone?
Here’s an interesting suggestion from the CS-Cart folks directly:
[QUOTE]In order to fix this bug please try to replace the following part of code:
$data[‘ip’] = $ip[‘host’];
with this one:
if (!empty($ip[‘proxy’])) {
$data[‘ip’] = $ip[‘proxy’];
} else {
$data[‘ip’] = $ip[‘host’];
}
in the “core/class.session.php” file.[/QUOTE]
And here was my reply:
[Quote]I implemented the fix you suggested, and it does appear to have addressed one issue I was having: that the HTTPS shopping cart page was very slow to load, apparently not using the cache at all, even after the page had been visited once. That, at least, seems to be resolved now. The initial loading of the HTTPS shopping cart page is still slow, but subsequent visits to the page appear to be responsive, with no noticeable difference from the loading time of the HTTP pages in the site.
With that said, my problem remains: some of my customers are still unable to add items to their cart. What I’m considering investigating next is turning on/off JavaScript pagination, and experimenting with whether customers are brought to the cart page after adding an item. My current configuration is that they are redirected to the cart page after adding an item, but if that’s causing the problem, I’ll turn that off until we can get this resolved.
I know that, as has been mentioned in the forum, the “Redirect customer to the cart contents page if non-AJAX addition to a cart is used” setting in the admin area did not work at first, forcing someone to post a workaround (http://forum.cs-cart.com/showthread.php?t=11403). It appeared to me that the issue was addressed with your version 2.07 release, so I removed the code recommended in the forum. I think I’m going to try reinstating it to see if it helps.[/QUOTE]
I’m very eager to get this resolved. I’m happy to pay anyone who can provide assistance, as my store is essentially non-functional right now.
I have no problems with IE 8.0 on windows machine with medium and lower privacy settings.
The only problem I have is with AOL users and mentioned in another thread.
Customer is able to add items into shopping cart. However, when they check out, the shopping cart is empty.
My conclusion is that AOL uses go through a proxy and their IP address changes during the session.
My secure url starts with “secure.inkwow.com” while my nonsecure url starts with “www.inkwow.com” which could affect cookies. However, I verified the cookie and it’s set for “.inkwow.com” so it should work for both “www.” and “secure.”
Also, it goes through a redirect from nonsecure to secure url.
The most like culprit is the IP address change. cscart for whatever reason issues a new session and new cookies, so the shopping cart becomes empty as it is considered a new session.
[quote name=‘hykit’]I have no problems with IE 8.0 on windows machine with medium and lower privacy settings.
The only problem I have is with AOL users and mentioned in another thread.
Customer is able to add items into shopping cart. However, when they check out, the shopping cart is empty.
My conclusion is that AOL uses go through a proxy and their IP address changes during the session.
My secure url starts with “secure.inkwow.com” while my nonsecure url starts with “www.inkwow.com” which could affect cookies. However, I verified the cookie and it’s set for “.inkwow.com” so it should work for both “www.” and “secure.”
Also, it goes through a redirect from nonsecure to secure url.
The most like culprit is the IP address change. cscart for whatever reason issues a new session and new cookies, so the shopping cart becomes empty as it is considered a new session.[/QUOTE]
And for the others reading this thread, the other thread hykit is referring to is at [URL=“http://forum.cs-cart.com/showthread.php?p=62471#post62471”]http://forum.cs-cart.com/showthread.php?p=62471[/URL]
[quote name=‘hykit’]I have no problems with IE 8.0 on windows machine with medium and lower privacy settings.
The only problem I have is with AOL users and mentioned in another thread.
Customer is able to add items into shopping cart. However, when they check out, the shopping cart is empty.
My conclusion is that AOL uses go through a proxy and their IP address changes during the session.
My secure url starts with “secure.inkwow.com” while my nonsecure url starts with “www.inkwow.com” which could affect cookies. However, I verified the cookie and it’s set for “.inkwow.com” so it should work for both “www.” and “secure.”
Also, it goes through a redirect from nonsecure to secure url.
The most like culprit is the IP address change. cscart for whatever reason issues a new session and new cookies, so the shopping cart becomes empty as it is considered a new session.[/QUOTE]
For what it’s worth, I’ve tried turning off SSL at checkout, and I’m still encountering the same problem.
It’s as if there are two separate carts, and the cart/checkout page knows only about the empty one, even if the “true” cart is recognized on the other pagesand in the mini-cart.
“HTTPS shopping cart page was very slow to load”, this is quite true!
I hope cs-cart will take care of all the problems mentioned above.
[quote name=‘Herbaria’]hykit,
Thank you very much for your input. I’ve been able to reproduce the problem consistently on one particular machine via IE8, but I’ve verified that its privacy settings were already set to medium.
Any other thoughts, anyone?[/QUOTE]
Can you test out my website?
www.inkwow.com
Does it work out for all privacy settings?
I’m running cscart 2.0.8
If my website works and yours does not, then there is something wrong with your installation.
My installation has problems with AOL users.