havenswift-hosting Posted April 28, 2017 Share Posted April 28, 2017 It doesn't affect the store operation, but does make the store slower. When an admin is logged in and doing things the cache is continually cleared and users on the front end continually keep populating it ! Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted April 28, 2017 Share Posted April 28, 2017 Thanks for the explanation - but it does make it sound like this NULL product issue probably is not cache related. Quote Link to comment Share on other sites More sharing options...
keat Posted May 4, 2017 Share Posted May 4, 2017 We've just this instant had another one. I've quicky got on the phone to the customer. He says that he added a number of items to his cart, went through the checkout process, where it skipped the gateway page and gave him an order confirmation message. Although, again around this time I was editing an admin side file and perfromed a cache clear. Could clearing the SQL cache cause this ?? Quote Link to comment Share on other sites More sharing options...
keat Posted May 5, 2017 Share Posted May 5, 2017 Looking in my Apache error log, it seems that this same IP created another ModSec error a few hours prior to placing the order. Order placed at 11:35am, Apache error 09:01am Maybe be related, maybe not ?? [Thu May 04 09:01:06.277133 2017] [:error] [pid 30199:tid 139777913366272] [client xxx.xxx.xxx.xx] ModSecurity: collections_remove_stale: Failed deleting collection (name "ip", key "yy.yy.yy.yyy_7187b4ec27d9744f5e6019375213b890b4850295"): Internal error (specific information not available) [hostname "www.domain.co.uk"] [uri "/js/styles/styles.php"] [unique_id "WQrfwQDlhalTyh6GJnPnAQAAAUU"] [Thu May 04 09:01:06.277227 2017] [:error] [pid 30199:tid 139777881896704] [client xxx.xxx.xxx.xx] ModSecurity: collections_remove_stale: Failed deleting collection (name "ip", key "yy.yy.yy.yyy_7187b4ec27d9744f5e6019375213b890b4850295"): Internal error (specific information not available) [hostname "www.domain.co.uk"] [uri "/images/cache/pictures/al41.70.jpg"] [unique_id "WQrfwQDlhalTyh6GJnPnAgAAAUg"] xxx.xxx.xxx.xxx being the customers IP yy.yy.yy.yyy a different number which looked like an IP Quote Link to comment Share on other sites More sharing options...
keat Posted June 1, 2017 Share Posted June 1, 2017 Another one today. 1 x - (£0.00) £0.00 Subtotal:£0.00 Total Discount :£0.00 Shipping:£0.00 Total Tax:£0.00 Total:£0.00 Millions in stock. Quote Link to comment Share on other sites More sharing options...
keat Posted June 5, 2017 Share Posted June 5, 2017 Got another one today. This is now starting to become annoying. Quote Link to comment Share on other sites More sharing options...
lyndsiesal Posted July 4, 2017 Author Share Posted July 4, 2017 Still getting them here, too. Any updates? Quote Link to comment Share on other sites More sharing options...
keat Posted July 5, 2017 Share Posted July 5, 2017 Unless we can recreate it, then i think it's unlikely that we will see a resolution. Quote Link to comment Share on other sites More sharing options...
keat Posted July 11, 2017 Share Posted July 11, 2017 I'm pretty much convinced that this is related to something which is happening on the end users browser, as we've just had one on one of our quieter sites. See attached screen grabs. Note how the original order items are 2, 1, 2, 1 And on the blank, the order is 1, 2, 1, 2 Does this shed any light on the issue ?? Quote Link to comment Share on other sites More sharing options...
bsmither Posted July 11, 2017 Share Posted July 11, 2017 Just to clarify - these two screen grabs are what pages, specifically? Quote Link to comment Share on other sites More sharing options...
lyndsiesal Posted July 11, 2017 Author Share Posted July 11, 2017 Another one for me today. Quote Link to comment Share on other sites More sharing options...
keat Posted July 12, 2017 Share Posted July 12, 2017 (edited) Hi Brian My two screen grabs were the order summary from withing the admin side of the cart. Here it is from another view. Edited July 12, 2017 by keat Quote Link to comment Share on other sites More sharing options...
keat Posted July 12, 2017 Share Posted July 12, 2017 (edited) The customer was using firefox, says that his battery went flat, just at the point where he'd chosen POF and clicked continue. I think it's unlikely to be related to his battery going flat, and possibly his browser crashing ?? Interestingly, the ones I've reported on another thread also mention firefox, although one also mentions chrome. Edited July 12, 2017 by keat Quote Link to comment Share on other sites More sharing options...
keat Posted July 12, 2017 Share Posted July 12, 2017 (edited) The one which happened last night has a cart time stamp of 170712-001919-1986 I've included the raw access logs for this customers IP address. Considering the cart was posted at 00:19:19, there's quite a lot of activity going on for a few minutes after ? @Al Brookbanks could you take a look and see if it reveals anything at all ?? missing cart.xls Edited July 12, 2017 by keat Quote Link to comment Share on other sites More sharing options...
bsmither Posted July 12, 2017 Share Posted July 12, 2017 We would ask that you give us a CSV as opposed to an Excel spreadsheet. Quote Link to comment Share on other sites More sharing options...
keat Posted July 13, 2017 Share Posted July 13, 2017 converted to csv csv.csv Quote Link to comment Share on other sites More sharing options...
keat Posted July 14, 2017 Share Posted July 14, 2017 (edited) I've had a very irate customer call today that a basket with over 250 items which he's been building up over a period of two weeks has all gone to zero. Of course, building a basket for two weeks isn't good practice, but how do I explain this to him, when he does this with his other service providers. Whilst on this occasion, we didn't see the order at our end, I can't help thinking that it's related. from the gist of the conversation, I guess his basket zero'd out at his end and he spotted it before committing the order. @Al Brookbanks, could you or your team take a look at my CSV from 2 days ago please, we have to get to the bottom of this. Edited July 14, 2017 by keat Quote Link to comment Share on other sites More sharing options...
keat Posted July 14, 2017 Share Posted July 14, 2017 I've identified this customer and then searched the saved cart table for anything with his customer ID. I find 1 blob file with just a single item, iv'e no idea if this is a recent saved cart or an old one, but certainly no where near the amount of items he's saying that he'd placed. Quote Link to comment Share on other sites More sharing options...
keat Posted July 14, 2017 Share Posted July 14, 2017 Going back to my CSV file, not how this customer is using firefix and then possible an Ipad. I looked inside Cubecart_access_logs and found the transaction, I assume this is the correct one, as I can see the next customer shortly afterwards which tallies with the orders for that day. Cubecart_access_logs denotes IEX as the user agent.. I assume Internet Explorer. Could this have anything to do with it ?? Quote Link to comment Share on other sites More sharing options...
keat Posted July 17, 2017 Share Posted July 17, 2017 And now another one. The customer is using Firefox. He seems to think that he placed items in his basket, clicked the continue button, and was taken to an orde complete page. He says that no gateway was selected, as if it skipped the gateway stage all together. 170717.csv Quote Link to comment Share on other sites More sharing options...
keat Posted July 17, 2017 Share Posted July 17, 2017 (edited) I've sucessfully recreated this three times this afternoon. Using Firefox and Mican Skin (we've seen this on our foundation skin site also) Add items to your basket without logging in, when the basket has about 4 or 5 items, proceed through the checkout process, choosing a shipping method (if applicable). When prompted to create an account or log in, log in with your test account. Without proceeding any further, leave the browser open. Do not continue, just let the browser sit idle. After a period of time (iv'e left 40 minutes), come back click the continue button. Cart is logged with null items. I'm now attempting to recreate using Chrome browser. Edited July 17, 2017 by keat Quote Link to comment Share on other sites More sharing options...
keat Posted July 19, 2017 Share Posted July 19, 2017 Al has also managed to recreate this on at least two of my web sites, so hopefully, we'll find a resolution. Both web sites are on different servers I might add. Quote Link to comment Share on other sites More sharing options...
keat Posted July 20, 2017 Share Posted July 20, 2017 (edited) I've now recreated this issue on a stock 6.1.8 site. Mican Skin, Print Order Form and All in one Shipping, everything else is stock. Edited July 24, 2017 by keat Quote Link to comment Share on other sites More sharing options...
keat Posted July 24, 2017 Share Posted July 24, 2017 (edited) It's looking like this is related to PHP server setting session.gc_maxlifetime Both Al and myself have performed numerous test orders on a spare domain and can recreate or fix the issue with a PHP config change. It's also looking like it's related to a CSRF error seen by others. sessions.class.php should be handling this, hopefully, Al will figure out why it's not, or maybe why my server is ignoring it, as not everyone will have access to the PHP config. Edited July 24, 2017 by keat Quote Link to comment Share on other sites More sharing options...
keat Posted July 27, 2017 Share Posted July 27, 2017 Further update, which is now pointing more towards a PHP issue, (I'm not sure if this is just Cpanel.) It appears that local garbage collection settings via PHP ini_set are ignored and the script runs listening to the master value only. The "/usr/local/cpanel/scripts/clean_user_php_sessions" script will only recognize the global "session.gc_maxlifetime" PHP configuration value configured for each version of PHP. If a custom value for "session.gc_maxlifetime" is preferred for an individual account, then the workaround is to also configure a custom "session.save_path" value for the account. This will allow PHP to handle the session cleanup, as opposed to the "/usr/local/cpanel/scripts/clean_user_php_sessions" script. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.