Jump to content

Item info missing from order


lyndsiesal
 Share

Recommended Posts

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 ??

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 4 weeks later...
  • 5 weeks later...

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 ??

1.jpg

2.jpg

Link to comment
Share on other sites

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 by keat
Link to comment
Share on other sites

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 by keat
Link to comment
Share on other sites

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 by keat
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ??

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by keat
Link to comment
Share on other sites

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 by keat
Link to comment
Share on other sites

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.

 

 

Link to comment
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.

Guest
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.

 Share

×
×
  • Create New...