[Not a ZC bug] Counter History not updating

[buns1525]

Hi - I'm a little stumped. I believe I followed the instructions when upgrading from 1.3.9h to 1.5.1, but obviously something is not quite right. I upgraded by using the official upgrade procedure. The only addons / modules I have are basic payment (ceon_manual and paypal express checkout) and shipping (Store Pickup, USPS and UPS).

Everything from an orders perspective and customers perspective is working correctly. The issue that I'm seeing is that the counter and counter_history tables are not updating. There are no duplicates, it is just stuck at the date when I did the upgrade. I looked at the table structure of each, and they are pretty simple, and look to be correct. I even backed them up, dropped them, and re-created them using the SQL from the 138 to 139 upgrade scripts (I looked in the more recent scripts and didn't find anything in those).

Also, I have customer orders as well as New Customer information showing correctly on the admin page, but the counter and counter histories are not reflecting those.

The one strange data value that I can see is that the Hit Counter started on 05/11/2010

What other information can I provide that may help in solving this?

Thanks so much

Mike

[DrByte]

Check the integrity of the following files on your server:
/includes/counter.php
/includes/init_includes/init_sessions.php
/includes/init_includes/overrides/init_sessions.php (only if it exists)
/includes/spiders.txt
/includes/application_top.php

Are the files present?
Are the files complete? and not blank
In what ways have they been altered from the original Zen Cart code?

Also search all the files in your /includes/ folder and subfolders to see whether you've got custom code added anyplace to set $spider_flag = true (other than the init_sessions.php file mentioned above, which is the only place that variable should be set to true, and only on the one line).

[buns1525]

Thanks DrByte - all files were present and looked good (opened them up in Textpad), except for overrides/init_sessions.php, which wasn't there. There have been no customizations to those files, so I could copy over fresh copies of the files again if you think that may help.

When searching for the spider_flag, I got the following results:

includes\init_includes\init_sessions.php(76): $spider_flag = false;
includes\init_includes\init_sessions.php(82): $spider_flag = true;
includes\init_includes\init_sessions.php(88): if ($spider_flag == false) {
Found 3 occurrence(s) in 1 file(s)

Any other actions I should take? Should I copy the files you listed above from a fresh zen cart extract to ensure they are good?

Thanks

Mike

[DrByte]

Also, has your /includes/database_tables.php file been altered from original?

What is your DB_PREFIX set to in your configure.php files? Is it the same in both admin and non-admin?
In your database, do your two tables use that DB_PREFIX value in their names? Or do you have two sets of those tables?

[buns1525]

DrByte - The database_tables.php file has not been altered (date stamp of 7/24/2010).

Includes DB section of config:
// define our database connection
define('DB_TYPE', 'mysql');
define('DB_PREFIX', '');
define('DB_CHARSET', 'utf8');
define('DB_SERVER', 'localhost');
define('DB_SERVER_USERNAME', 'xyzXXXXadmin');
define('DB_SERVER_PASSWORD', 'xxxxxxxxxxxx');
define('DB_DATABASE', 'xxxxdatabasename');

admin/includes database section of config
// define our database connection
define('DB_TYPE', 'mysql');
define('DB_PREFIX', '');
define('DB_CHARSET', 'utf8');
define('DB_SERVER', 'localhost');
define('DB_SERVER_USERNAME', 'xyzXXXXadmin');
define('DB_SERVER_PASSWORD', 'xxxxxxxxxxxx');
define('DB_DATABASE', 'xxxxdatabasename');

There are no database prefix used at all.

Thanks

[DrByte]

I'm stumped too. Assuming all the code is truly original code, then there's no reason for the counter stuff to not be working.

You'll probably need to put in some debug code to track whether those segments of code that do the updates are firing, and then find out why the queries aren't being run. Perhaps start with whether the queries are even being submitted. Try running those queries directly via phpMyAdmin and see what happens.

The files I mentioned are the ones involved in the process ... mainly the counter.php file itself.

[buns1525]

DrByte - just wanted to keep you updated. I utilized WinMerge to find some differences in counter.php, initsystem.php and application.top. Since I know I didn't make any customizations to those files, I stopped the apache webserver, copied them over from a fresh set and the counter was back, up and running. Still, no idea what happened, if they were corrupted or what. But anyway, it is all set.

Thanks again for your responses. They ended up helping in the end.

Mike

[DrByte]

So ... if THOSE files have been altered, then you REALLY need to find out WHY they were different than what they should have been.

AND you need to find out ALL THE OTHER files that are also different. Do a COMPLETE comparison of ALL files. WinMerge will be your friend.