User tracking mod

[a_berezin]

Add session id to all '<a href="...

[inovermyhead]

Hello all, have a problem here. We're running ZC 1.3.8 on our stores. A little while ago, the user tracking on the CreekTreeUSA shop quit working, it shows only a clean white page. The other shops appear to work fine, and there's no other symptoms on CreekTree, just no user tracking.

I looked at the database with phpMyAdmin, and the CreekTree user_tracking table has message that there's "No Index Defined". That table for the other shops have indexes time_entry, session_id, and time_entry2 defined.

For the time being, I've set "User tracking visitors" to false in the configuration. Does anyone have idea what's happened, and what needs to be done? Would appreciate any advice.

[inovermyhead]

Hello all, have a problem here. We're running ZC 1.3.8 on our stores.

Sorry, all, that should have been 1.3.7, not 1.3.8, and I might mention that the user tracking has been up and running fine on the store for over 6 months, it's been a very handy tool.

[inovermyhead]

Good Morning, all ...
To bring you up to date on this, yesterday I started thinking about simply adding those 3 indexes to the CreekTree database to see what happens, so I enabled user tracking again ... and found that it was working again! The database still shows no index for the table but I can't find any discrepancy in how it operates.
So I'm in a 'leave well enough alone situation' unless someone has any idea what could have caused the malfunction, and what could have happened to those 3 indexes. Would appreciate any thoughts, comments, observations, advise anyone can offer.

Thanks,

[MeltDown]

A few weeks ago my host upgraded to apache 2.x Php 5.x.x and Mysql 5.x.x. After this upgrade the User Tracker on both of my stores stopped functioning - The mod was still in place but it regestered zero activity. I was told to re-load the SQL and have done so but still nothing. I even re-loaded the add-on completely but no changes

I'm running 1.3.6 on both stores. Any ideas?

Thanks

[kbalona]

I had user tracking running for the past year on 1.3.6 & 1.3.7. Now I upgraded to 1.3.8 and it quit working. I uninstalled it, downloaded the latest version and re-installed it, still no joy. The interface shows up fine, it just doesn't track any visitors.

[MeltDown]

I had user tracking running for the past year on 1.3.6 & 1.3.7. Now I upgraded to 1.3.8 and it quit working. I uninstalled it, downloaded the latest version and re-installed it, still no joy. The interface shows up fine, it just doesn't track any visitors.

As I've posted, I'm having exactly the same problem on both of my stores, although I'm still running 1.3.6. Mine occured after my host upgraded to apache 2.x Php 5.x.x and Mysql 5.x.x. - Now it just doesn't track

[kbalona]

I got my installation going again. I had forgotten to add the tracking code to the end of tpl_footer.php

<?php if (ZEN_CONFIG_USER_TRACKING == 'true') { zen_update_user_tracking(); } ?>

[Laszlo]

For all those people who have problems with the time offsets in total time and and idle time, the problem is the code that generates the html there is poorly written.

It is towards the end of admin/user_tracking.php, search for "28800".

The person who wrote this code used 28800 seconds (8 hours) offset as that presumably suited their timezone. With a bit of experimenting you can figure out what value works for you (provided you site runs on servers in the same timezone only).

The real solution is to change this code to be timezone neutral (work in every timezone).

Something like:

date('H:i:s', mktime(...)) would work (instead of the current date() call) only that in the database we have seconds only, this needs to be converted to hours, minutes, seconds as mktime() takes three parameters (hours, minutes, seconds).

[dedj]

For all those people who have problems with the time offsets in total time and and idle time, the problem is the code that generates the html there is poorly written.

It is towards the end of admin/user_tracking.php, search for "28800".

The person who wrote this code used 28800 seconds (8 hours) offset as that presumably suited their timezone. With a bit of experimenting you can figure out what value works for you (provided you site runs on servers in the same timezone only).

The real solution is to change this code to be timezone neutral (work in every timezone).

Something like:

date('H:i:s', mktime(...)) would work (instead of the current date() call) only that in the database we have seconds only, this needs to be converted to hours, minutes, seconds as mktime() takes three parameters (hours, minutes, seconds).

nice you found the problem, I've been annoyed for some time about that.
could you please write down more detailed on what to change that string to?
I'm not following your solution exactly.
thanks
Dejan