keat

Sessions.gc_maxlifetime is garbage cleanup. If a session has been left open and untouched for 1440 seconds (24 minutes) it's deemed by PHP to be garbage and is then deleted. However, 24 minutes is not hard and fast as the deletion is done by another process which runs as a schedule. In my case 24 minutes, turns out to be about 40. Cubecart appears to be telling PHP to use 604800 (7 days), but for whatever reason, PHP is ignoring this and using the master setting of 24 minutes. This also has me wondering if other local settings are being ignored. I have a thread running on the Cpanel forum, which may or may not turn in to a support ticket. https://forums.cpanel.net/threads/session-gc_maxlifetime.606031/

Something makes me think if sessions.class.php isn't handling this then maybe .htaccess won't either, but it might be worth investigating. More info https://stackoverflow.com/questions/10704370/php-session-timeout-htaccess-file

If it is related to gc maxlifetime, then the setting is called session.gc_maxlifetime, which is a setting in the PHP config on the server, you may not have access to this, as it has to be performed at OS level. Maybe your hosting provider might be willing to change this on your hosting plan. If you look in cart PHP info, you should find 2 settings. One will be 604800 (7 days) the other 1440 (24 minutes) It seems for what ever reason, the master setting of 24 minutes is taking precidence over the local setting of 7 days. Maybe this is also occuring with other local vs master settings, and quite possibly something which has come about with a PHP update. Something we discovered last week. I'm not sure of the long term fix, Al would have a better understanding of this. It seems that it may be possble to set this in .htaccess https://stackoverflow.com/questions/6253498/declaring-session-max-life-time-in-htaccess However, I did mine at OS level, so never tried with .htaccess

We've used SecPay, which became PayPoint and now Pay360. Since Crapita took over, the support has gone real down hill, to the point that i've had enough of being given the run around and now cosidering switching to Worldpay. Does anyne use Worldpay, and how do you find them.

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.

did you try connecting via https

Sorry, I ought to have updated. I spotted those links last week and swapped the files for the minified ones. Page insights isn't all that accurate though. I can have a green card on one run and a yellow one the next, now fluctuating anywhere between about 88 (green) and 80 (amber) Seositecheckup.com gives me a decent score of 95 though.

OK, this looks like its on your own site. I think you need https at least for this. As per HarrisOrganic says If you go to manage extenstions, find card capture, and then allowed zones, you'll need to add the zones which are allowed to post card details. Personally, I'd avoid this plugin and use something like PayPal, as you're probably contravening all PCI DSS rules hosting the card gateway yourself. Experience a security breach and a whole can of worms could open up for you. Just my opinion.

where is he inputting his card details, directly on your site or via a host.

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.

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.

In the database, have a look at the category index table. If you imported your parts, they may well not be linked to a category.

Did you check that the file sources/maintenance/indexbackup.inc.php does exist.

PayPal was acting up last week, maybe it is again today. Transactions were taking up to two hours to show up in the PayPal web page. If you can, then switch to the old classic view, as I found the transactions would display in there, but not in the new look.

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.

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

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

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.

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.

Have a look at this, it might help. Ahh, I see you already did.

I took a look in Cpanel, and I'm running MYSQL5.5 which i've now updated to 5.6. can I update to MariaDB 10.0

According to my Apache/PHP config and looking at PHP info on one of my sites, it appears that I have MYSQLI installed. Info from CubeCart: mysqlnd 5.0.12-dev - 20150407 - $Id: xxxxxxxxxxxx $ The site is working with PHP7.0 but not with 7.1, however, having said that, I know that one of Ian's mods uses IonCube, so maybe I can't go down this route just yet anyway.

Mine makes less sense even still. Webmastertools is telling me that it can see a link to www.cabletiesonline.co.uk/login.html via www.crimpterminals.co.uk/login.html Yet if I open up the page source, I see no reference, so how come Google does ? Last spotted by Google 8 days ago. similar story with other links. I suspect this is something which is common to all pages, like the subscribe button ?

In my quest for performance i updated one of my test sites to PHP7.1. I take it CC doesn't work with 7.1 ? Fatal error: Uncaught Error: Call to undefined function mysql_connect() in /home/mydomain/public_html/classes/db/mysql.class.php:36 Stack trace: #0 /home/mydomain/public_html/classes/db/mysql.class.php(63): Database->__construct(Array) #1 /home/mydomain/public_html/controllers/controller.index.inc.php(20): Database::getInstance(Array) #2 /home/mydomain/public_html/index.php(20): include('/home/crimpterm...') #3 {main} thrown in /home/mydomain/public_html/classes/db/mysql.class.php on line 36

The exact reason that we use a dedicated gateway. A data breach could run in to 10's of thousands.