Odd Cart Issue on new server

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. :dontgetit

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.

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.

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

semide:

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?

DrByte:

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

DrByte:

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.

semide:

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

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.

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.

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.

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.

Actually, error was echoed to browser, and no myDEBUG file created.

semide:

Actually, error was echoed to browser, and no myDEBUG file created.

Content of the browser error? Just that an error occurred please refresh or go back? Or was it much more detailed?

1146 Table 'belmetri2009_2010d.produc' doesn't exist
in:
[select * from produc where products_id < 100;]

semide:

1146 Table 'belmetri2009_2010d.produc' doesn't exist
in:
[select * from produc where products_id < 100;]

Did an internet search, while this doesn't address all potential issues/solutions, it might help. Looks like either in php.ini display_errors is on or perhaps it is somewhere in the ZC files (possible to override, but isn't suggested)... But this offers a few things to consider:
http://askubuntu.com/questions/578404/php-ini-display-errors-off-but-errors-still-outputted-to-browser and at least some discussion about where else to possibly look... Sorry for not trying to find an equivalent FAQ on this site... Went the "easy" route. :)

Any place in ZC Files it is more likely to be? Server info says Error Reporting is off, so I am not sure where to start.

semide:

Any place in ZC Files it is more likely to be? Server info says Error Reporting is off, so I am not sure where to start.

Would check includes/application_top.php:

In ZC 1.5.3 there is a section like this:

/**
 * set the level of error reporting
 *
 * Note STRICT_ERROR_REPORTING should never be set to true on a production site. <br />
 * It is mainly there to show php warnings during testing/bug fixing phases.<br />
 */
if (defined('STRICT_ERROR_REPORTING') && STRICT_ERROR_REPORTING == true) {
  @ini_set('display_errors', TRUE);
  error_reporting(version_compare(PHP_VERSION, 5.3, '>=') ? E_ALL & ~E_DEPRECATED & ~E_NOTICE : version_compare(PHP_VERSION, 5.4, '>=') ? E_ALL & ~E_DEPRECATED & ~E_NOTICE & ~E_STRICT : E_ALL & ~E_NOTICE);
} else {
  error_reporting(0);
}

Not sure what it is/was for 1.3.9h at the moment. Could find it if need it (I've got a copy somewhere), but I'm working on something else at the moment.

semide:

Actually, error was echoed to browser, and no myDEBUG file created.
That suggests that you're missing the /include/extra_configures/enable_error_logging.php file.

Quick update: myDEBUG were missing due to a permissions issue. Now although they are generating, there is nothing in them near the times the cart issues happen.

semide:

Quick update: myDEBUG were missing due to a permissions issue. Now although they are generating, there is nothing in them near the times the cart issues happen.

Permissions of what? And what is the most recent debug file? Would want to go ahead and address those and maybe somethng will come to light?

semide:

Quick update: myDEBUG were missing due to a permissions issue. Now although they are generating, there is nothing in them near the times the cart issues happen.

Also, how far off in time are the logs compared to the event?