User tracking mod

[BlessIsaacola]

Can you please tell me if this update is suppose to fix the issue where User Shopping Cart (when viewing user tracking) is the same across multiple visitors? Thanks!

[gilby]

Can you please tell me if this update is suppose to fix the issue where User Shopping Cart (when viewing user tracking) is the same across multiple visitors? Thanks!

The problem here is the decoding of the various active shopping cart(s)
If you visit whosonline and click on a visitor with an active cart, then that cart is the one that is shown for all the user tracking visitors that haven't expired.

[mc12345678]

Thank you mc12345678 for this great update. I have been following this thread from the beginning because I also received the new install sql error. It now works perfectly.

I have one question: what is the report button for under Admin>Tools>User Tracking? Is it a refresh or should an actual report appear?

Thanks again for this great update!

The "Report" button acts as a refresh to pull up the history associated with the selected date. I had kind of forgotten that the name of the button doesn't exactly match what happens.

Basically if you know you want to look at the history of November 1, then you can "dial" that in and press report and the time machine will take you back to the first of November. :) or one could click repetitively the back one day button.

Will consider what to do with that aspect (recode it/add instruction).

[mc12345678]

Can you please tell me if this update is suppose to fix the issue where User Shopping Cart (when viewing user tracking) is the same across multiple visitors? Thanks!

While aware and familiar with the results of an item being in the cart causing visual chaos, I have not tackled that one yet. I realize that there is some incorrect logic that predates my changes to the plug-in, but if I remember correctly that area of the code is integrated with the area that does the logging of the visit, which is why I have put a bit of a precedence on squaring away the logging/capturing of data first. I once had a bot add something like 4 million dollars of items to it's cart and while looking at UT you could imagine my surprise that a single "user" wanted to buy that much from our little organization. Looked into it, and ah well just some computer adding stuff to the cart that it wasn't going to buy.

Anyways, as much as I would like to straighten the cart issue out, I need to stick with the plan to address capture of the data first which may lead to an easy fix on the cart issue.

[mc12345678]

Uncompressed, the flag gifs account for 178K. I don't recall where the flags were sourced.

The bigger issue is the GeoIP.dat that accounts for 914KB uncompressed. And that data is dated, from 2006.

The geoip data comes from Maxmind
http://geolite.maxmind.com/download/...ountry.mmdb.gz

Have to pay for the GeoIP data, but GeoLite2 data is free. But then need to employ a Maxmind API to access/utilize the proprietary GeoLite2 mmdb data.

I don't know how often Maxmind updates their GeoLite2 country databases, but I suspect the current GeoLite2 mmdb data (1.5MB uncompressed) is much more up to date than the 2006 data provided in current User Tracking mod.

I don't know if the mmdb can be read or is compatible with the API code built into the current UT mod. Or the older GeoIP.dat was converted to a different format supported by the UT mod.

But if it is doable I suggest placing the geoip data and flags in a separate archive and explain in readme where to fetch and where to install. Or two separate mods, one with and one sans the geoip data and flags.

Just suggestions.

Haven't dropped this idea...

Glad you provided the link to obtain additional ip data. Seeing some of the "visits" to my site and the fact that the country did not seem to line up with the provided flag, I did find that it is possible to download an updated GeoIP data file without going through a pay source. I am assuming and it is a big stretch, that UT is written to handle the free version of the GeoLite data file. I've tried to do some preliminary review of the GeoLite2 perspective; however, have not found what the difference/benefit between the two is. When able, I plan to try to incorporate the GeoIP data file and see if I have new/different results on my site then would provide direction/instruction on how others can obtain the updated file assuming it works.
The user readable version (CSV) certainly is large; however, it looks like the current compressed version (DAT) is actually smaller than the one that has been provided in this plug-in.

The source found reports to update every week, so yes the current DAT file is WAY out-of-date.

Will also continue to consider how better to provide the package and associated changes.

[gilby]

The source found reports to update every week, so yes the current DAT file is WAY out-of-date.

Will also continue to consider how better to provide the package and associated changes.

If you are updating the GeoIP.dat file, you have to also get the latest geoip.inc file to access it correctly.

[BlessIsaacola]

Thank you so much for the update. Completely understand your approach and appreciate all the work you're putting into this. I simply asked to make sure I didn't miss something.

While aware and familiar with the results of an item being in the cart causing visual chaos, I have not tackled that one yet. I realize that there is some incorrect logic that predates my changes to the plug-in, but if I remember correctly that area of the code is integrated with the area that does the logging of the visit, which is why I have put a bit of a precedence on squaring away the logging/capturing of data first. I once had a bot add something like 4 million dollars of items to it's cart and while looking at UT you could imagine my surprise that a single "user" wanted to buy that much from our little organization. Looked into it, and ah well just some computer adding stuff to the cart that it wasn't going to buy.

Anyways, as much as I would like to straighten the cart issue out, I need to stick with the plan to address capture of the data first which may lead to an easy fix on the cart issue.

[mc12345678]

Thank you so much for the update. Completely understand your approach and appreciate all the work you're putting into this. I simply asked to make sure I didn't miss something.

No hardship here. :) wanted to make sure any that read this now or in the future understood the thought process brhind it. Now too, it looks like an update to handle the new geoip data is needed. I hope it won't be. Difficult, but reading the api instructions makes it seem it won't be too bad. (Though sounds like will need to consider the size aspect as recentky suggested.

[BlessIsaacola]

Any idea what this error is?

[16-Nov-2013 08:44:35 America/New_York] PHP Fatal error: 1064:You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'OFFICE_IP_TO_HOST_ADDRESS')' at line 1 :: insert into user_tracking (customer_id, full_name, session_id, ip_address, time_entry, time_last_click, last_page_url, referer_url, page_desc, customers_host_address) values ('0', 'Guest', '', '157.55.32.84', '1384609475', '1384609475', '/index.php?main_page=product_reviews&cPath=388_408&products_id=13478', '/index.php?main_page=product_reviews&cPath=388_408&products_id=13478', 'Discovery and Exploration - Educational Insights You\', 'OFFICE_IP_TO_HOST_ADDRESS') in /includes/classes/db/mysql/query_factory.php on line 120

The ip address belongs to MSN searchbot. Thanks!

[mc12345678]

Any idea what this error is? The ip address belongs to MSN searchbot. Thanks!

Yeah, took a second tofigure out, but look at the last character of your page description field that is just before the host ip address. Looks like this: 'Discovery and Exploration - Educational Insights You\', well, the \ just before the single parenthesis is an escape code sequence, telling SQL to treat the ' as a character in the string rather than the end of a string. So the next ' becomes the end, the OFFICE_IP_TO_HOST_ADDRESS is becomes a misplaced statement and then finally the last ' is treated as the opening to a new string that is not properly finalized which causes the error you are seeing. I think that if you were to visit thatpage yourself, you would cause the same issue, it just happens that someone/something got there first.

Btw, that is an example also of what I was saying of identifying a malformed SQL statement, doing something about it, and letting the operator know it happened and hopefully in a way that would be unique to UT.

Basically the page description for that product should not end with a backwards slash. Not sure why it would, to begin with...