User tracking mod

[Nitroedge]

Thanks again for taking the time to help me out!
I'm super new to Github and trying to understand how it works. I see that your link shows the alterations to the 2 files and I was wondering how I do I actually download the 2 files in their altered format?

[mc12345678]

Thanks again for taking the time to help me out!
I'm super new to Github and trying to understand how it works. I see that your link shows the alterations to the 2 files and I was wondering how I do I actually download the 2 files in their altered format?

From an Internet search on 'github download single file repo', I was presented with the following "instructions":

Go to the file you want to download.
Click it to view the contents within the GitHub UI.
In the top right, right click the Raw button.
Save as...

So from the link above you can click in the upper right of each file (though really it is only the second file that has a change that affects operation, the removal of the closing php section is more about preventing future issues than something functional.

Anyways, the information provided in the links above should have been enough to identify where in the file(s) to make the change(s). Hopefully the question was more about general usage. Suggest reading through the github instructions/help file(s).

[Nitroedge]

Thanks, worked perfectly and I can report the page is loading correctly now with all the new features and functionality.

I have been testing it and the only problem I have is I am getting the following error in the admin debug logs each time I view the report:

[16-Jul-2017 07:50:39 America/Detroit] PHP Warning: array_key_exists() expects parameter 2 to be array, null given in user_tracking.php on line 283

This error occurs whether I have show/hide spiders or show/hide filters on. It appears to occur each time the User Tracking report is loaded or refreshed.

[mc12345678]

Thanks, worked perfectly and I can report the page is loading correctly now with all the new features and functionality.

I have been testing it and the only problem I have is I am getting the following error in the admin debug logs each time I view the report:

[16-Jul-2017 07:50:39 America/Detroit] PHP Warning: array_key_exists() expects parameter 2 to be array, null given in user_tracking.php on line 283

This error occurs whether I have show/hide spiders or show/hide filters on. It appears to occur each time the User Tracking report is loaded or refreshed.

I see why/how it is generated. When first going through the records, if $user_tracking hasn't been declared as an array() (which I thought it had, but I see that it wasn't) then when testing if a key is in the non-declared array an error like that could be expected. This is done by inserting a line before the while (!$whos_online->EOF related line that has:

$user_tracking = array();

Alternatively that if statement:

     if ($user_filter_search == 'HideOnly' && array_key_exists('filterwordfound', $user_tracking[$whos_online->fields['session_id']])) {

Could be made false earlier by inserting

&& !empty($user_tracking)

in the if statement after 'HideOnly'. Logic analysis will stop as soon as a false condition is encountered as evaluated from left to right following an order of precedence.

I'm thinking the first solution of establishing the variable as an array is the better solution (1 assignment to put the variable in a known and needed state of being an array and it does not increase processing for each loop by basically evaluating if $user_tracking is an array on each loop), but I need to look at the code that is after the while loop to see if the code that follows would behave incorrectly in the condition that there were no records to review/retrieve.

And yup, just after the closing curly parenthesis of the while loop the check is if $user_tracking is an array. this same check is used later in the code as well. So more does need to be changed than just adding the one line to prevent generating that warning which I guess I'm surprised has been supressed in the environment tested. Here at the is_array($user_tracking) == true would want to instead use the !empty($user_tracking) check instead when using the previous $user_tracking = array(); statement.

Alright patch coming up... :)

[mc12345678]

Patch posted at github to eliminate the warning message on the admin side:
https://github.com/mc12345678/User_T...14374bb14b621a

Now to see if it can be inserted into the code that was uploaded/updated earlier this week or if I need to generate yet another newer version. :)

Wouldn't want someone to come along, not read this forum, download the fileset, it generate a mydebug log for each time the report is accessed and then to say hey, this plugin is crap because it generated an warning..... (Sorry, been somewhat tracking the behavior of plugin usage/dismissal. I REALLY thank YOU for pointing out the issues that you have identified. As I say, without knowing that there is a problem and how to recreate it, there is nothing (known) to fix.)

I must say that I don't like the idea that have to tell users of ZC 1.5.1 (and likely 1.5.0) that they really need to upgrade because there was really an error that was introduced/in existence back in those versions that prevented proper use of the code... Ie. It seems a waste to have to provide either/both the table_block.php and/or box.php classes in such a way that they are functional when at this time, nothing additional is really being done. Yeah, overall the presentation of the data would be better/easier if a unique "box" style were provided in the plugin because I've been trying to get creative at not displaying the "header" of the box, but here and there a "top" is still present. If I "took control" of the box class for UT (by providing a separate box class), then when I don't want a header it would be easier by just not providing a header and only providing content and I'd be able to control some of the internal formatting a little better. Just hadn't had the "need" to do that for myself when all I want is to see the data that is provided. :)

[mc12345678]

Realized that still needed to do the test of !empty in the if statement at least when hide only was selected... so, the new single change/patch that addresses all of the locations for this is at: https://github.com/mc12345678/User_T...a4c809b7449861, the previously provided link will still "work" but it will not resolve the warning that was observed. Overall, the code is better because of the change, but the only thing that was needed to prevent that message was the !empty($user_tracking) that I was trying not to include if I didn't have to. :)

The master branch is also up-to-date with these changes.

Patch posted at github to eliminate the warning message on the admin side:
https://github.com/mc12345678/User_T...14374bb14b621a


Now to see if it can be inserted into the code that was uploaded/updated earlier this week or if I need to generate yet another newer version. :)

Wouldn't want someone to come along, not read this forum, download the fileset, it generate a mydebug log for each time the report is accessed and then to say hey, this plugin is crap because it generated an warning..... (Sorry, been somewhat tracking the behavior of plugin usage/dismissal. I REALLY thank YOU for pointing out the issues that you have identified. As I say, without knowing that there is a problem and how to recreate it, there is nothing (known) to fix.)

I must say that I don't like the idea that have to tell users of ZC 1.5.1 (and likely 1.5.0) that they really need to upgrade because there was really an error that was introduced/in existence back in those versions that prevented proper use of the code... Ie. It seems a waste to have to provide either/both the table_block.php and/or box.php classes in such a way that they are functional when at this time, nothing additional is really being done. Yeah, overall the presentation of the data would be better/easier if a unique "box" style were provided in the plugin because I've been trying to get creative at not displaying the "header" of the box, but here and there a "top" is still present. If I "took control" of the box class for UT (by providing a separate box class), then when I don't want a header it would be easier by just not providing a header and only providing content and I'd be able to control some of the internal formatting a little better. Just hadn't had the "need" to do that for myself when all I want is to see the data that is provided. :)

[Nitroedge]

Fantastic and glad I could help. The reason I still run v1.51 is because my template is so heavily modified it would be a real task (and risk to having the store down for awhile) to merge all the files and update to v1.55. I will try out your new file and report back, thanks!

[Nitroedge]

Uploaded the new file and works with the default options loaded. No debug log file is generated.

But if you change the default Filter option (List All) and select (Hide Filtered), you should see it will refresh the data but then create a similar debug error on line 285.

"[16-Jul-2017 18:43:19 America/Detroit] PHP Warning: array_key_exists() expects parameter 2 to be array, null given in user_tracking.php on line 285

The problem seems to be isolated to the above scenario.
No errors are reported if you choose (Show Filtered), or change the (Min Clicks) option, or (Show/Hide Spiders) options. No errors are also reported if you choose different dates as well. :)

[mc12345678]

You, unlike me at the time of testing, must have had at least one visit recorded.

*sigh* I knew I should have focused more on the true solution and not just what seemed to work.

Explanation: when the setting is to filter out the undesirables, then the first criteria of the if statement is satisfied as true. When the loop has been executed at least once, the second criteria is true (!empty), but, on that second "trip" the applicable session may not have been the same as before and therefore there may not be a record (non-empty sub-array) and therefore the code attempts to check for a key against a basically non-assigned array which is what throws that warning.

So need yet another && !empty($user_tracking[$whos_online->fields['session_id']]) inserted after the first !empty($user_tracking)

Bugger. :/ at least DrByte has also offered some optimization improvements that would make the resubmission of the latest more worth while. :)

[mc12345678]

Will be issuing version 1.5.8 to ZC in the next couple of days, at least. This version can be found on github at the version 1.5.8 branch:

Version 1.5.8:
* - Add an additional check to prevent an admin mydebug log being when the selection is made to display filtered entries to hide entries that accessed an item on the list of filtered URIs.
* - Incorporate optimizations provided by DrByte to improve the quality of the program
* - Joined admin/includes/functions/extra_functions/user_tracking.php into the function code for the catalog side which meant that was able to incorporate into the catalog observer. Functions can be reached through the use of $user_tracking_observe->zen_update_user_tracking() instead of just zen_update_user_tracking().
* - Installer is expected to remove admin/includes/classes/class.user_tracking.php and
admin/includes/functions/extra_functions/user_tracking.php if either or both are present because these files are no longer needed or used.
* - Incorporated ip data collection code into the program to support compatibility between ZC versions where for example the admin side doesn't have the same ip collection code.
* - Cleaned up the look of the code to be consistent within an individual file.

This modification nearly updates/modifies all files while removing some of them as well.