User tracking mod

@jaydamuss,

Please accept my apologies as I was able to identify an error with the install code once I was on someone else's system and they had the same issue occur. Certainly there were some other factors at play, but I was able to identify the one minor issue that caused the database not to get updated with the version number (causing the process to repeat) and as a result of that error occurring there was another "catch all" that had to get more code, so.. I have uploaded an updated version of User Tracking that incorporates the other changes that I was working on basically that the data displayed is collected in a series of tables prior to being displayed. The thought was that this would maybe make transition to ZC 1.6.0 "easier". Not yet sure about that, but it was a path down which I had started and wanted to finish.

Anyways, also completed the transition of links to $_POST buttons instead of "links" (underline style). Here is the list of changes applied to the update:

Updated 06/10/2017 Version 1.5.4 mc12345678:

1. Revised the installer to restore the expected operation. Bug had been introduced that prevented recognition of full installation.
2. Incorporated an additional check/correction to support reperformance of the installation if an error was introduced during installation,
   helping to move forward from the above problem.
3. Generalized the installer further to not depend on the file extension taking only 4 characters in length.
4. Added install file to recognize this version.
5. Updated the geodata to the 8 June 2017 version.
6. Cleaned up code a little by removing closing php statements.
7. Prevent the install auto_loader from activating from the catalog side.
8. Rename class constructors to be PHP 7.0 compliant.
9. Modified the display of the User Tracking information
   to use the generic admin table type class/object.
10. The idea is/was that it may make transition to ZC 1.6.0
    easier, though could also be undone as necessary.
11. Further completed the transition of GET links to POST buttons.
12. Incorporated the type conversion issue identified
    by davewest at: https://www.zen-cart.com/showthread.php?222290-Type-conversion-numeric-to-string-and-back&highlight=user+tracking+mktime
13. Generally adjusted the lines of the main page to use
    spaces instead of tabs, aligned code to support improved
    readability.
14. Incorporated associated language file modifications,
    even if the language is/was not translated yet.

And I finally got my local User Tracking git files pushed to my github so that in the future it would be easier to discuss the code and not have to download it to a local computer just to look at it.

So, for the installer, to quickly get that to be quiet and correct.
See the changes made/shown for the admin/includes/init_includes/init_user_tracking.php file found at this github path:
https://github.com/mc12345678/User_Tracking/compare/323ee37db35682c8f7a2a692baf5392181cba0ac...222b51d0d079d1b83d1f0c17d4ec9cc9bb045087

mc12345678:

@jaydamuss,

Please accept my apologies as I was able to identify an error with the install code once I was on someone else's system and they had the same issue occur. Certainly there were some other factors at play, but I was able to identify the one minor issue that caused the database not to get updated with the version number (causing the process to repeat) and as a result of that error occurring there was another "catch all" that had to get more code, so.. I have uploaded an updated version of User Tracking that incorporates the other changes that I was working on basically that the data displayed is collected in a series of tables prior to being displayed. The thought was that this would maybe make transition to ZC 1.6.0 "easier". Not yet sure about that, but it was a path down which I had started and wanted to finish.

Anyways, also completed the transition of links to $_POST buttons instead of "links" (underline style). Here is the list of changes applied to the update:

And I finally got my local User Tracking git files pushed to my github so that in the future it would be easier to discuss the code and not have to download it to a local computer just to look at it.

So, for the installer, to quickly get that to be quiet and correct.
See the changes made/shown for the admin/includes/init_includes/init_user_tracking.php file found at this github path:
https://github.com/mc12345678/User_Tracking/compare/323ee37db35682c8f7a2a692baf5392181cba0ac...222b51d0d079d1b83d1f0c17d4ec9cc9bb045087

i thank you soo much, the messages have gone and now works perfect :)
cheers

jaydamuss:

i thank you soo much, the messages have gone and now works perfect :)
cheers
No, yet again, thank you for reporting the issue. As said, hadn't occurred on my side, so wouldn't have known to do anything without the report. :)

As an aside, I'm going back through the installer as used on other plugins and making some notes as although there were a few things to improve, some of the rewrites to try to resolve this issue were unnecessary and just complicated things.

I am running 1.5.4 and installed the User-tracking-V.1.5.4. I made the file changes as suggested and installed all files as indicated. I get an error. I followed all troubleshooting tips including a complete uninstall and re-install and get the same errors:

[13-Jun-2017 12:53:01 America/New_York] PHP Warning: file_get_contents(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0 in /hermes/bosnaweb07a/b261/ipg.garsquaredcom/obiecue/includes/functions/plugin_support.php on line 38
[13-Jun-2017 12:53:01 America/New_York] PHP Warning: file_get_contents(http://www.zen-cart.com/downloads.php?do=versioncheck&id=1744%29: failed to open stream: no suitable wrapper could be found in /hermes/bosnaweb07a/b261/ipg.garsquaredcom/obiecue/includes/functions/plugin_support.php on line 38
[13-Jun-2017 12:53:01 America/New_York] PHP Warning: in_array() expects parameter 2 to be array, null given in /hermes/bosnaweb07a/b261/ipg.garsquaredcom/obiecue/includes/functions/plugin_support.php on line 42

Any suggestions?

Tony

Yeah, that's because of the version checking that is in the install file (admin/includes/init_includes/init_user_tracking.php) and how it is implemented on ZC 1.5.4, though it is interesting that it is happening with the plugin and not with the routine operation of the admin (unless something is being done to bypass the main screen where the issue is likely to appear)... Anyways, you could/should be able to do any of the following, though the first action probably will have to relate to a file modification.

Could remove the admin/includes/auto_loaders/config.user_tracking_install.php file, and then could modify ad
min/includes/init_includes/init_user_tracking.php

Towards the end of the file, modify:

// Version Checking 
if ($zencart_com_plugin_id != 0 && SHOW_VERSION_UPDATE_IN_HEADER && (!defined($module_constant . '_PLUGIN_CHECK') || constant($module_constant . '_PLUGIN_CHECK'))) {
    $new_version_details = plugin_version_check_for_updates($zencart_com_plugin_id, $current_version);
    if ($_GET['gID'] == $configuration_group_id && $new_version_details != FALSE) {
        $messageStack->add("Version ".$new_version_details['latest_plugin_version']." of " . $new_version_details['title'] . ' is available at <a href="' . $new_version_details['link'] . '" target="_blank">[Details]</a>', 'caution');
    }
}

to either add the below red text:

// Version Checking 
if (false && $zencart_com_plugin_id != 0 && SHOW_VERSION_UPDATE_IN_HEADER && (!defined($module_constant . '_PLUGIN_CHECK') || constant($module_constant . '_PLUGIN_CHECK'))) {
    $new_version_details = plugin_version_check_for_updates($zencart_com_plugin_id, $current_version);
    if ($_GET['gID'] == $configuration_group_id && $new_version_details != FALSE) {
        $messageStack->add("Version ".$new_version_details['latest_plugin_version']." of " . $new_version_details['title'] . ' is available at <a href="' . $new_version_details['link'] . '" target="_blank">[Details]</a>', 'caution');
    }
}

Or remove that entire block of code.

Ideally, the includes/functions/plugin_support.php file would get updated to the recently available copy from ZC 1.5.5: https://github.com/zencart/zencart/blob/v155/includes/functions/plugin_support.php (or perhaps that from 1.6.0 might be further improved?)

Technically though if SHOW_VERSION_UPDATE_IN_HEADER is set to false, then this shouldn't have been an issue... I'll also look at changing the criteria for performing the check, but ideally, there shouldn't be an issue with the check being attempted... Right? :)

I made these changes:
edited the init_user_tracking.php as suggested. Removed the config.user_tracking_install.php file and dropped in the plugin_support.php file from git hub. Those errors are gone.
Now I get this error:

PHP Parse error: syntax error, unexpected '<' in /hermes/bosnaweb07a/b261/ipg.garsquaredcom/obiecue/BBQadmin/user_tracking.php on line 390

I removed the line since it was commented out and the plugin is working.

Thanks,
Tony

mc12345678:

Yeah, that's because of the version checking that is in the install file (admin/includes/init_includes/init_user_tracking.php) and how it is implemented on ZC 1.5.4, though it is interesting that it is happening with the plugin and not with the routine operation of the admin (unless something is being done to bypass the main screen where the issue is likely to appear)... Anyways, you could/should be able to do any of the following, though the first action probably will have to relate to a file modification.

Could remove the admin/includes/auto_loaders/config.user_tracking_install.php file, and then could modify ad
min/includes/init_includes/init_user_tracking.php

Towards the end of the file, modify:

// Version Checking
if ($zencart_com_plugin_id != 0 && SHOW_VERSION_UPDATE_IN_HEADER && (!defined($module_constant . '_PLUGIN_CHECK') || constant($module_constant . '_PLUGIN_CHECK'))) {
$new_version_details = plugin_version_check_for_updates($zencart_com_plugin_id, $current_version);
if ($_GET['gID'] == $configuration_group_id && $new_version_details != FALSE) {
$messageStack->add("Version ".$new_version_details['latest_plugin_version']." of " . $new_version_details['title'] . ' is available at <a href="' . $new_version_details['link'] . '" target="_blank">[Details]</a>', 'caution');
}
}

> 
> to either add the below red text:
> ```
// Version Checking 
if (false && $zencart_com_plugin_id != 0 && SHOW_VERSION_UPDATE_IN_HEADER && (!defined($module_constant . '_PLUGIN_CHECK') || constant($module_constant . '_PLUGIN_CHECK'))) {
    $new_version_details = plugin_version_check_for_updates($zencart_com_plugin_id, $current_version);
    if ($_GET['gID'] == $configuration_group_id && $new_version_details != FALSE) {
        $messageStack->add("Version ".$new_version_details['latest_plugin_version']." of " . $new_version_details['title'] . ' is available at <a href="' . $new_version_details['link'] . '" target="_blank">[Details]</a>', 'caution');
    }
}

Or remove that entire block of code.

Ideally, the includes/functions/plugin_support.php file would get updated to the recently available copy from ZC 1.5.5: https://github.com/zencart/zencart/blob/v155/includes/functions/plugin_support.php (or perhaps that from 1.6.0 might be further improved?)

Technically though if SHOW_VERSION_UPDATE_IN_HEADER is set to false, then this shouldn't have been an issue... I'll also look at changing the criteria for performing the check, but ideally, there shouldn't be an issue with the check being attempted... Right? :)

tonyreynolds:

I made these changes:
edited the init_user_tracking.php as suggested. Removed the config.user_tracking_install.php file and dropped in the plugin_support.php file from git hub. Those errors are gone.
Now I get this error:

PHP Parse error: syntax error, unexpected '<' in /hermes/bosnaweb07a/b261/ipg.garsquaredcom/obiecue/BBQadmin/user_tracking.php on line 390

I removed the line since it was commented out and the plugin is working.

Thanks,
Tony

Comments to these changes:

tonyreynolds:

I made these changes:
edited the init_user_tracking.php as suggested. Removed the config.user_tracking_install.php file and dropped in the plugin_support.php file from git hub. Those errors are gone.

Dropping in the plugin_support.php file from github should have resolved the issue without editing init_user_tracking.php or removing the config.user_tracking_install.php file. (in fact now that those two portions have been performed, you will not receive in admin notification of an updated copy of user tracking being available from the ZC forum.)

tonyreynolds:

PHP Parse error: syntax error, unexpected '<' in YOUR_SECRET_ADMIN/user_tracking.php on line 390

I removed the line since it was commented out and the plugin is working.

This is/was an error introduced in both "trimming" down the code that was on the live test version and "trying" to leave behind a possible "screen" (page source) indicator of where in the process the table was being presented. I have identified it as an issue on github and will be editing the file to address it. There are two ways that it could be addressed, I haven't evaluated yet which option is the way desired to go. It is/was intended to be an html comment (part of how the modification was being performed which was to build a table around the data that was being displayed to validate that relatively speaking the output was equivalent for the two methods). So it could either be deleted as was done above, or it could be "displayed" by encompassing in php related identifiers such as:

?><!--        <table border="0" width="100%" cellspacing="0" cellpadding="0"> --><?php

LASTLY, and probably most important for this store, suggest revising the admin directory name... :/ It should not be posted as a matter of norm and remain known only to those that have a need to access it. :lookaroun

Thank you for identifying the issues and way you resolved the problem(s).

By the way, the fix to admin/user_tracking.php file has been posted to github at the following commit: https://github.com/mc12345678/User_Tracking/commit/881ff399398bd94a47bd29626e5b43e95d1e5656#diff-4464b9ecc1485ae77374511700d32b45

This will be incorporated into the next version. Please identify any other issues (possibly with solution) to be incorporated.

Thanks all!

Good point and thanks. Changes made to the admin directory.....

Tony

LASTLY, and probably most important for this store, suggest revising the admin directory name... :/ It should not be posted as a matter of norm and remain known only to those that have a need to access it. :lookaroun

Thank you for identifying the issues and way you resolved the problem(s).[/QUOTE]

mc12345678:

Comments to these changes:

Dropping in the plugin_support.php file from github should have resolved the issue without editing init_user_tracking.php or removing the config.user_tracking_install.php file. (in fact now that those two portions have been performed, you will not receive in admin notification of an updated copy of user tracking being available from the ZC forum.)

This is/was an error introduced in both "trimming" down the code that was on the live test version and "trying" to leave behind a possible "screen" (page source) indicator of where in the process the table was being presented. I have identified it as an issue on github and will be editing the file to address it. There are two ways that it could be addressed, I haven't evaluated yet which option is the way desired to go. It is/was intended to be an html comment (part of how the modification was being performed which was to build a table around the data that was being displayed to validate that relatively speaking the output was equivalent for the two methods). So it could either be deleted as was done above, or it could be "displayed" by encompassing in php related identifiers such as:

?><!-- <table border="0" width="100%" cellspacing="0" cellpadding="0"> --><?php

> 
> LASTLY, and probably most important for this store, suggest revising the admin directory name... :/ It should not be posted as a matter of norm and remain known only to those that have a need to access it. :lookaroun
> 
> 
> Thank you for identifying the issues and way you resolved the problem(s).

I undid all the edits to the original state, updated the user_tracking.php and kept the plugin_support.php file. Everything works properly. Thanks again.
TR

Hello, I just installed the latest version and when I click on Tools -> User Tracking I get a 500 error. Config -> User Tracking Config works.

I'm running ZenCart v1.5.5. I'm not sure if I've ever installed this before but I do remember years ago using Super Tracker..

My update history:
Database Patch Level: 1.5.5

v1.5.5 [2016-04-22 03:00:51] (Version Update 1.5.4->1.5.5)
v1.5.4 [2016-04-22 03:00:51] (Version Update 1.5.3->1.5.4)
v1.5.3 [2016-04-22 03:00:50] (Version Update 1.5.2->1.5.3)
v1.5.2 [2016-04-22 03:00:50] (Version Update 1.5.1->1.5.2)
v1.5.1 [2013-12-05 05:48:47] (Version Update 1.5.0->1.5.1)
v1.5.0 [2013-12-05 05:48:47] (Version Update 1.3.9->1.5.0)
v1.3.9h [2011-08-14 11:41:12] (Version Update 1.3.8->1.3.9h)
v1.3.8 [2009-03-21 19:09:40] (Fresh Installation)
v1.3.8 [2009-03-21 19:09:40] (Fresh Installation)

Thanks

Christoff:

Hello, I just installed the latest version and when I click on Tools -> User Tracking I get a 500 error. Config -> User Tracking Config works.

I'm running ZenCart v1.5.5. I'm not sure if I've ever installed this before but I do remember years ago using Super Tracker..

My update history:
Database Patch Level: 1.5.5

v1.5.5 [2016-04-22 03:00:51] (Version Update 1.5.4->1.5.5)
v1.5.4 [2016-04-22 03:00:51] (Version Update 1.5.3->1.5.4)
v1.5.3 [2016-04-22 03:00:50] (Version Update 1.5.2->1.5.3)
v1.5.2 [2016-04-22 03:00:50] (Version Update 1.5.1->1.5.2)
v1.5.1 [2013-12-05 05:48:47] (Version Update 1.5.0->1.5.1)
v1.5.0 [2013-12-05 05:48:47] (Version Update 1.3.9->1.5.0)
v1.3.9h [2011-08-14 11:41:12] (Version Update 1.3.8->1.3.9h)
v1.3.8 [2009-03-21 19:09:40] (Fresh Installation)
v1.3.8 [2009-03-21 19:09:40] (Fresh Installation)

Thanks
A few things as not discussed, have you applied the patch of post 748 and what is the error log that is/was generated? (see your logs directory and this FAQ: http://www.zen-cart.com/content.php?124-blank-page)

mc12345678:

A few things as not discussed, have you applied the patch of post 748 and what is the error log that is/was generated? (see your logs directory and this FAQ: http://www.zen-cart.com/content.php?124-blank-page)

Applying that patch fixed it!

This was the error in the log file:
[16-Jun-2017 10:46:45 UTC] PHP Fatal error: Class 'user_tracking_admin' not found in /home/**********/public_html/includes/autoload_func.php on line 79

No error now.

Thanks for your assistance! :)

Christoff:

Applying that patch fixed it!

This was the error in the log file:
[16-Jun-2017 10:46:45 UTC] PHP Fatal error: Class 'user_tracking_admin' not found in /home/**********/public_html/includes/autoload_func.php on line 79

No error now.

Thanks for your assistance! :)

Glad that it worked and thank you for posting back. As soon as I can, I'd like to make the downloadable plugin one that doesn't require any additional fixes to support out-of-the box operation.

The error message though related to the issue appears to identify that at the time at least one file had not been loaded to the server. It strikes me somewhat odd the difference between that error message and the one that led to the solution of the previous post.

Is there anyway to hide or not show all the robot hacker visits that try to access files like "wplogin.php" as I can see so many user sessions where this is accessed:

search_in_description=1&keyword=wp%20login%20php&inc_subcat=0&main_page=advanced_search

I'm running Zen Cart obviously and not Wordpress but these hacker attempts distract from the "real" customers I am analyzing data from :)

Anybody have any tips?

Thanks!

Brandon

Nitroedge:

Is there anyway to hide or not show all the robot hacker visits that try to access files like "wplogin.php" as I can see so many user sessions where this is accessed:

search_in_description=1&keyword=wp%20login%20php&inc_subcat=0&main_page=advanced_search

I'm running Zen Cart obviously and not Wordpress but these hacker attempts distract from the "real" customers I am analyzing data from :)

Anybody have any tips?

Thanks!

Brandon
There are a number of ways that come to mind to not display either the record of that attempt or the entire visit of that "individual" pretty much depending on what type of review is being performed and what is desired to be seen as a result.

Ie. Do you want the record to still be logged and then somehow managed when viewing records or some level of not ever logging the record?

Thanks for the speedy reply!

I'd love to just hide them and never log them nor see them, that would be great. Just filtering them out so I can concentrate on analyzing real customers.

Nitroedge:

Thanks for the speedy reply!

I'd love to just hide them and never log them nor see them, that would be great. Just filtering them out so I can concentrate on analyzing real customers.

You say "them". Are you referring to the single line of text or the "person" that entered that line of data?

Just to try to explain a little. To prevent any log entry of a row of data means that there must be some "pre-known" list of things to not log. That could be a word list that has been generated based on previous review, or some other factor. To not log a "user", requires pretty much the same thing (pre-made list) and then possibly some action to be taken if they "trip" across one of the no-no items.

If only a single record/page visit is skipped for each "keyword" then there are likely to be time gaps between one page visit and another when looking at the recorded data. (would likely want to flag the "user" as having tried to access one of the no-no items.)

Then on the output side, if the record had been logged, such keywords could be used as a filter to prevent different types of reporting: make the "user" a spider/bot, hide the single page visit from the totals, hide the user from page views, etc...

Also, are you reviewing the data while it is on screen or through some sort of export of the table? The answer to that can change the approach significantly.

I'm reviewing the data from the User Tracking data on my screen.

I understand what you mean by "them", the "them" is any user that tries to access:

&search_in_description=1&keyword=wp%20login%20php

The above seems to be the one consistent piece of code in each hack attempt.

Data from log from 4 users (after the user's "?zenid string):

&search_in_description=1&keyword=wp%20login%20php&inc_subcat=0&main_page=advanced_search
&search_in_description=1&keyword=wp%20login%20php&inc_subcat=0&main_page=advanced_search
&search_in_description=1&keyword=wp%20login%20php%20action%20register&inc_subcat=0&main_page=advanced_search
&search_in_description=1&keyword=wp%20login%20php%20action%20register&inc_subcat=0&main_page=advanced_search

For a short period of time I did do an IP Block on their addresses in my cPanel, but there are so many of them and from different countries I stopped doing that.
I'm curious if other people get these types of activity in their User Tracking logs?

Thanks!