Odd Cart Issue on new server

[semide]

I have a cart at https://www.belmetric.com that we moved from another server. Cart has been running for years with no problems (hence old version...).

On new server it seems to be losing cart contents on larger orders. If you go along and add contents to the cart, somewhere around the 16th or so item in the cart it forgets some of the items - I've seen anywhere from one to five items missing. Which items seem to be random, sometimes the last, sometimes the first and last will remain in the cart and all the rest will disappear.

We've already tried disabling suhosin to no avail.

I would welcome any ideas.

[mc12345678]

I'll only be on a podium for a moment. I don't have a good solution other than to upgrade, and even then not sure if that would solve the issue (haven't seen the same report of lost product from others still using such old software). So just would like to say, the absence of problem over the years is not an indication that an upgrade isn't necessary... In fact there could have been things happening that were not given notification. Anyways, off the box for now. :)

May want to identify how much memory is set aside for zc (version button in admin) as well as the php version. Those things may help someone diagnose the issue.

[semide]

I'll only be on a podium for a moment. I don't have a good solution other than to upgrade, and even then not sure if that would solve the issue (haven't seen the same report of lost product from others still using such old software). So just would like to say, the absence of problem over the years is not an indication that an upgrade isn't necessary... In fact there could have been things happening that were not given notification. Anyways, off the box for now. :)

May want to identify how much memory is set aside for zc (version button in admin) as well as the php version. Those things may help someone diagnose the issue.

Duly noted. We are working on a new site, trying to keep the old one alive until we can launch.

Memory: 128M
PHP: 5.3.3

[DrByte]

On new server it seems to be losing cart contents on larger orders. If you go along and add contents to the cart, somewhere around the 16th or so item in the cart it forgets some of the items - I've seen anywhere from one to five items missing. Which items seem to be random, sometimes the last, sometimes the first and last will remain in the cart and all the rest will disappear.

I'm wondering if it's a limitation of capacity to store user session data. What's the STORE_SESSIONS setting set to in your admin and non-admin configure.php files?

Also, in v139 the store saves debug/error logs in the /cache/ folder (if the folder is writable). What sort of errors are being recorded in those myDebug-xxxxxx.log files, particularly when that symptom occurs?

[mc12345678]

I'm wondering if it's a limitation of capacity to store user session data. What's the STORE_SESSIONS setting set to in your admin and non-admin configure.php files?

Also, in v139 the store saves debug/error logs in the /cache/ folder (if the folder is writable). What sort of errors are being recorded in those myDebug-xxxxxx.log files, particularly when that symptom occurs?

If I may add to this, be patient when trying to access the cache folder if it happens to be filled with many files... It can sometimes take a while (or depending on how accessed) or never come up... Don't be fooled that "no files" on screen means none in the folder. (Cross reference the size of the folder, etc.)

[semide]

I'm wondering if it's a limitation of capacity to store user session data. What's the STORE_SESSIONS setting set to in your admin and non-admin configure.php files?

Also, in v139 the store saves debug/error logs in the /cache/ folder (if the folder is writable). What sort of errors are being recorded in those myDebug-xxxxxx.log files, particularly when that symptom occurs?

Thanks for replying DrByte.

Configure files both have STORE_SESSIONS set to 'db', and I verified session are being stored in the database (traced session cookie id to database id)

Cache folder has files up to time of move, all seemingly warning about creating default object from empty value. No files since move. Folder was 755, changed it to 777 and added items to cart until some disappeared, still no myDEBUG files.

[mc12345678]

Thanks for replying DrByte.

Configure files both have STORE_SESSIONS set to 'db', and I verified session are being stored in the database (traced session cookie id to database id)

Cache folder has files up to time of move, all seemingly warning about creating default object from empty value. No files since move. Folder was 755, changed it to 777 and added items to cart until some disappeared, still no myDEBUG files.

DIR_FS_CACHE points to a real and accurate directory? (Remember to consider any CONSTANT substitutions accurately).

Also, keep in mind might need to change directory back to 755. Need to try to force an error to be logged...

[mc12345678]

Could create a sql error:

Add a file to includes/functions/extra_functions

Call it something like error_cause.php

Inside paste the following with no spaces or other characters before the first <?php

<?php

if (isset($_GET['etest']) && zen_not_null($_GET['etest']) && $_GET['etest'] == 'me') { 
$sql = "select * from produc where products_id < 100;";

$sql_result = $db->Execute($sql);
}

That should generate an error on page load.when you have in your uri something like:

http: // your site .com/index.php?etest=me

It will otherwise leave your site intact (not bother other browsing customers) but you also want to eventually delete that file so nothing odd happens in the future.

[semide]

Hmmm. No DIR_FS_CACHE in either config file. Added it to both for good measure, and turned on Store Page Parse Time (set to same directory). Got page_parse_time.log, no myDEBUG entry after pushing cart to failure again.

[mc12345678]

Hmmm. No DIR_FS_CACHE in either config file. Added it to both for good measure, and turned on Store Page Parse Time (set to same directory). Got page_parse_time.log, no myDEBUG entry after pushing cart to failure again.

Okay, so proved that the directory is writeable. Hopefully still going to try the above error generation. Don't know where else an error log would be written, but might as well prove that it does occur when "determined" time to cause/capture an error.