Jump to content
Sign in to follow this  

Customer baskets emptying upon product status or availability change.

Recommended Posts

Issue:  Customer baskets emptying upon product status or availability change.

Attempted Fixes

  • Attempted all the fixes I been able to find in other posts including upping the max_input_vars and mem. 
  • Disabled all mods, no luck.
  • Added Noodleman's Abandoned Cart plugin in the hopes it would at least catch these.  No luck.

Related Topics: Basket Randomly Emptying & saved_cart BLOB Recover

Yes this is a revisit to half of that thread but now I think I have a culprit.  I also elected to create a new thread to keep it focused to problem and resolution because sorting through a dynamic thread with a lot of posts to possibly find a fix to an issue is frustrating.  Its why I like to end a thread you all helped me in with a post that has a step by step of how I implemented that help.  

Details: Customers are having their baskets empty. Some are happening within minutes and others are over days/weeks.  It was random until I stumbled onto the following.

Possible Cause:  The only way I been able to reproduce this issue is to have items in a test basket then on the admin side uncheck a product(s) in the basket from either/both "Available for purchase" & "Status"  Essentially, making them unavailable.

Result:  When the customer updates their instance by logging in or going to another page or to their basket it must run through the cart find the items now unavailable and remove them.  However, it is then removing everything else in the basket as well.

Key Details:

We are using the default skin for cubecart with some custom tweaks done by several people before me.  I have tested this problem against an "out of the box" instill of cubecart on a test server without issue.


Help Needed:

My belief at this point is that one of the tweaks accidentally deleted a close statement for how cubecart removes out of stock products from an existing cart.    

I just need a general idea of what file(s) (or table but I doubt its happening back there) are implicated in the remove items from cart when unavailable.  The triggering statement (whatever code word is used) to let the system know to scan cart and remove x) would be awesome at helping nail down what and where. 


Edited by reneerd

Share this post

Link to post
Share on other sites

While investigating this, I came across something different. I will be posting my experience in the Github.

But I will continue to try to find the most likely place where you should start looking. I am fairly confident you will want to examine any customizations in the /classes/cart.class.php file.

Share this post

Link to post
Share on other sites


Thank you as always for the reply and apologies for the delay (other fires, weddings and all manner of "others").  


Update:  Oddly enough, I compared our cart.class.php to a stock install version and there was 0 variation.   

Something is suppressing the notice that happens when something is removed from your cart by the system but do not know if there is any crossover between that and this issue.

I can say that the complaints about this issue have dropped to none being reported which makes me wonder if one of the previous changes needed to cycle out cookies client side or something for the fix to implement.  This drop off has taken some of the pressure off me from those above my pay grade but I am not one to assume the best and there is a chance the customers either been getting very lucky or have simply given up.

I am going to run some tests and update now that I am back in the saddle.

I would be very interested to see what you came across there bs, do you have a github link to it? If its not handy, dont worry Ill dig it up when time allows.

Anyway, thanks again! 

Share this post

Link to post
Share on other sites

The saga continues... update.  Hopefully these help others out if they end up with the same issue 


Hello again, here is where things stand on this issue.

Current Theory: There are multiple triggers for the issue.  I have been able to reproduce the problem with some of these and those I have been able to weed out.  However, other known-unknowns are still present as triggers.  I cannot nail down the root problem for the basket drops despite having several of the triggers mapped.

Latest Fix:  I have set inactivity logout for 19 minutes.  The lowest time frame any customer with the issue has been able to give me is 20 minutes.  Chances are the time is more like 30-60 min but to verify if this solution is working around the problem I set it to a safe time frame.  So far, so good.  People are being logged out and on logout there cart is saved and available up login.

This points me at someone occurring while the customer is logged in that is the main elusive trigger for the problem.  I will update if I find more.



Share this post

Link to post
Share on other sites

Could this be related to sessions.gc_maxlifetime, which we identified about 18 months ago.

I've been suffering this issue for a few years, I found that modifying this setting in PHP helped.

I modified my PHP setting at server level so the maximim session life time is now 1 week rather than the default 30 minutes.

However, if you don't have your own server then you'll not be able to do this.

We still get the odd one, where only some items have gone 'null' but no where near as many.



Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Create New...