Jump to content

Cart auto empty


Christopher Short

Recommended Posts

Possibly using Safari for all who complained at about the same time?

It is possible (but I really do not know for sure) that Safari may have updated at about that time -- while the customer still had a session still active.

CubeCart compares the browser's "User Agent string" on every page request. If it is different, then CubeCart believes something or someone is causing some trouble.

So, as a security measure, CubeCart destroys that session so that it cannot be hijacked. When destroying the session, the browser is instructed to delete the cookie, and everything being tracked (shopping cart, logged-in status, etc) is forgotten.

My Firefox tells me when an update is available, requests my permission to update, and informs me when it did update. This is on a desktop.

Safari may behave differently, and perhaps when on a mobile device, updates happen completely unnoticed.

If this is what happened, you should see that CubeCart logged this even in admin, Error Log, System Error Log tab.

Link to comment
Share on other sites

23 hours ago, bsmither said:

Safari may behave differently, and perhaps when on a mobile device, updates happen completely unnoticed.

It isnt just updates that will change the User Agent String, if the IP address also changes, then it will cause the same issue. Dynamic IP addresses can change quite frequently when using certain ISPs and when on mobile devices, especially when moving (car or train for example) as you move between different towers.  This will also be logged in the PHP error_log file so if you know the date / time when the customers complained about this happening, you can compare this to the logs and see if this is the cause

Link to comment
Share on other sites

Theres a bug in PHP, well technically not a bug, it's a design feature, but it's enough to cause an issue.

If a customer leaves his browser untouched or closes his browser etc, around 20-30 minutes later PHP peforms a clean up, and deletes inactive sessions.

As AL suggested, this can be worked around by changing the setting 'session.gc_maxlifetime' in PHP.ini.

 

However, what makes this difficult is that setting is a server wide setting, so unless you run your own server, you may not be able to change this.

I doubt that a shared server host would change this setting just to please you, unless this can be done on an account basis, which i'll make enquiries.

 

It seems that Plesk V11+ has a domain specific php.ini which over-rides the server wide setting, this can be configured through the Plesk control panel (if you are hosted on Plesk of course)

Link to comment
Share on other sites

42 minutes ago, keat said:

However, what makes this difficult is that setting is a server wide setting, so unless you run your own server, you may not be able to change this.

I doubt that a shared server host would change this setting just to please you, unless this can be done on an account basis, which i'll make enquiries

That is not the case, this can and should be set on a per account basis BUT you should also change the location where your session files are stored so they are not in the default location and are therefore affected by the serverwide garbage collection

Link to comment
Share on other sites

There is no guarantee that all users on all hosting can set these and you need to ensure you set them correctly or the website might not work at all !

session.gc_maxlifetime = {your value} - this value is in seconds and 2 to 4 days is usually more than enough
session.save_path = "/home/{USER}/tmp" - directory must exist and should ALWAYS be above the public_html directory
Link to comment
Share on other sites

That depends:

Windows servers would have the configuration file in the folder where the PHP executables are located, unless it is not. If Windows has a system environment variable for PHP, the configuration file might be where the environment variable says it is.

Linux servers would have the configuration file where all other configuration files are kept, and that could be different for each Linux distibution.

PHP will tell you where it is: in CubeCart's admin, PHP Info, the first table will have "Configuration File Path".

PHP also allows for user-supplied php.ini files in the directory where PHP is to execute scripts - such as CubeCart. INI directives can also be set at various other places, but there are limits (https://www.php.net/manual/en/configuration.php).

 

Link to comment
Share on other sites

3 minutes ago, Christopher Short said:

Except several customers have complained about loosing a basket they were working on for several days

That is not what I have been saying !  You should 100% change the settings as I outlined earlier and do it through cPanel which then updates the correct files such as teh local php.ini or user.ini etc  Speak to your hosting company if you are unsure

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...