Re: User tracking mod ZC 1.5.6
Quote:
Originally Posted by
markau
Will this plugin run on ZC 1.5.7?
It appears to be capturing data; however, as session data handling has changed through PHP versions, it appears that there needs to be a little modification to support display of the tracking "history" of a given session... I tried on ZC 1.5.7b with PHP 7.3 and there were a few myDEBUG logs generated at least on the admin side. One was because an array's key did not exist at that time of accessing. The other was because of the session handling issue in trying to show the individual status of user's and the "old" session handling.
During installation, didn't have any logs generated and only came across an issue when I tried to "View" the session history of any of the records. Means, that the plugin could be installed; however, some of the features are not yet fully available immediately until the session "unpacking" is corrected... Will setup a github issue (#4) and try to resolve shortly.
But then... I just accessed it again and it is working fine... *rolling eyes* thinking that *that* issue may be related to my server... Still I plan to look over it a little more anyways...
Re: User tracking mod ZC 1.5.6
Fyi and fwiw, while I didn't find a "convenient" way to rework the session decoding issue, I am incorporating the use of the WhosOnline class that was brought into ZC 1.5.7 such that if it exists it overrides the former process... What this means is that presuming that the old method worked for older ZC versions, the new code will still work there as well. BUT, if one forgets to include or chooses to exclude that class, then there are situations where the admin will get logged out when viewing the User Tracking page.
Swguy, I also have moved the delete "process" to a method within the observer class so that it may be called from outside of the main body of the User Tracking admin panel. I would like to consider making it part of the "routine" daily check such as with new, featured, sale like product. At least that way the load is low in "routine" site usage rather than on each page load on either the catalog or admin sides. Such an option though does make it a little more difficult to "control" who can make that possible, but its something that has been made more available.
Just uploaded version 1.5.10 for review:
Code:
Updated 01/02/2020 Version 1.5.10 mc12345678:
1. Addressed strict error reporting associated with admin_id as an array key.
2. Verified operational in ZC 1.5.7. up to PHP 7.3.
3. Revised the display of session data so that the date/time was not wrapped and allowed the URI to be displayed over a longer row.
4. Added javascript to bring the selected session to view.
5. Began using array variable to simplify consistent modification of page html.
6. Added ability to disable display of admin activity.
7. Refactored the observer class. Eliminated excess else statements.
8. Moved code to a variable assignment instead of processing within a function.
9. Made use of some of the unused internal variables.
10. Removed redundant checks against the value of some global variables.
11. Added database removal code to observer so can be used more robustly, even possibly automatically.
12. Simplified zen_check_bot function.
13. Updated the installer to remove variable $current_version, ensure operation,
14. provide compatibility for longer version identifiers,
Download location will be at/near: User Tracking - Zen Cart Plugins (zen-cart.com)
Re: User tracking mod ZC 1.5.6
Quote:
Originally Posted by
mc12345678
Fyi and fwiw, while I didn't find a "convenient" way to rework the session decoding issue, I am incorporating the use of the WhosOnline class that was brought into ZC 1.5.7 such that if it exists it overrides the former process... What this means is that presuming that the old method worked for older ZC versions, the new code will still work there as well. BUT, if one forgets to include or chooses to exclude that class, then there are situations where the admin will get logged out when viewing the User Tracking page.
Break with the old. Pick a ZC version for the new release to work with and abandon the old ones. Let the older releases of the plugin serve those using outdated ZC versions.
They're soon not going to be able to run older ZC versions anyway because PHP keeps moving forward (as does the rest of the ecommerce ecosystem). They can (and should anyway) upgrade their ZC version if they need to benefit from the newer plugin version.
This will cut down on the maintenance time required for supporting/upgrading plugins, since it won't be ultra-fragile by trying to support tooooo many old versions. The added benefit then is that you'll have time to support/update more plugins because the burden/load will be less.
Re: User tracking mod ZC 1.5.6
Even sitting here with four iPads I cannot use in our business any longer because they do not support the latest iOS, I agree with DrByte.
You can't and shouldn't have to be everything to everyone. 1.5.7 is a great choice for a new starting point.
Re: User tracking mod ZC 1.5.6
Quote:
Originally Posted by
dbltoe
Even sitting here with four iPads I cannot use in our business any longer because they do not support the latest iOS, I agree with DrByte.
You can't and shouldn't have to be everything to everyone. 1.5.7 is a great choice for a new starting point.
My issue with what needed to be done is that I had only wanted very specific information "introduced" through session swapping. That was what worked in older "versions" (PHP most likely the "culprit"). The new class offers the desired/needed information but also includes other data as well. It does that efficiently and without additional code so a great resource and no additional/independent coding and actually solved/addresses other concerns.
That said, there was a change in this version that I recommend others to incorporate. I'm surprised I hadn't thought about it or addressed it a long time ago, but while I was testing the changes and even providing some modifications to how the class internally worked I realized that the change was needed.
If anything, I really look forwards to when just PHP 7.x (or above) can be used, though even within that series of PHP there are some great changes that can only be implemented at/above certain PHP levels. I don't like to code with PHP versioning logic within the code (though that hasn't stopped me from doing it)
when something exists to support the span of permissable versions. Some of that coding too can't be done without significant duplication or unnecessary logic (test if php version, perform analysis and set a variable's value based on that logic, complete the test bracket and use the result of that variable in a "larger" piece of logic... Blah... too much though something similar is done in this release when evaluating the presence of the WhosOnline class.)
I am an overachiever and prefer to be able to provide something that works as "described", so yes I know that I strive to go above and beyond. I *do* plan to be working towards reduced past compatibility especially with the fall off of PHP 5.x support.
Re: User tracking mod ZC 1.5.6
Works like a charm on my 1.5.7.0. Thanks so much :smile:
User tracking mod ZC 1.5.7b / PHP 7.4 Warning: Use of undefined constant
ZC 1.5.7b
PHP 7.4.14
Code:
[30-Jan-2021 08:03:14 UTC] Request URI: ../index.php?main_page=product_info&products_id=1006, IP address: xxx.xxx.xxx.xxx
#1 user_tracking->zen_update_user_tracking() called at [../includes/classes/observers/class.user_tracking.php:30]
#2 user_tracking->update() called at [../includes/classes/class.base.php:118]
#3 base->notify() called at [../includes/templates/CUSTOM/common/tpl_main_page.php:267]
#4 require(../includes/templates/CUSTOM/common/tpl_main_page.php) called at [../index.php:94]
--> PHP Warning: Use of undefined constant NAVBAR_TITLE - assumed 'NAVBAR_TITLE' (this will throw an Error in a future version of PHP) in ../includes/classes/observers/class.user_tracking.php on line 99.
Looking at my User Tracking logs for the IPs that generate this warning it seems to happen with invalid urls. The user ends up on the "Sorry, the product was not found."
In this example it was caused by
Quote:
/index.php?main_page=product_info&products_id=1006
which should have been
Quote:
/index.php?main_page=product_info&products_id=1006
or
Quote:
/index.php?main_page=product_info&products_id=1006
.
In my case this is the incoming landing url so I can't do anything to fix this but would like to find a solution for the PHP warning if possible. This is line 99 from class.user_tracking.php
PHP Code:
$page_desc = defined('HEADING_TITLE') ? HEADING_TITLE : (IS_ADMIN_FLAG !== true ? NAVBAR_TITLE : "");
Re: User tracking mod ZC 1.5.7b / PHP 7.4 Warning: Use of undefined constant
Quote:
Originally Posted by
Brent
ZC 1.5.7b
PHP 7.4.14
Code:
[30-Jan-2021 08:03:14 UTC] Request URI: ../index.php?main_page=product_info&products_id=1006, IP address: xxx.xxx.xxx.xxx
#1 user_tracking->zen_update_user_tracking() called at [../includes/classes/observers/class.user_tracking.php:30]
#2 user_tracking->update() called at [../includes/classes/class.base.php:118]
#3 base->notify() called at [../includes/templates/CUSTOM/common/tpl_main_page.php:267]
#4 require(../includes/templates/CUSTOM/common/tpl_main_page.php) called at [../index.php:94]
--> PHP Warning: Use of undefined constant NAVBAR_TITLE - assumed 'NAVBAR_TITLE' (this will throw an Error in a future version of PHP) in ../includes/classes/observers/class.user_tracking.php on line 99.
Looking at my User Tracking logs for the IPs that generate this warning it seems to happen with invalid urls. The user ends up on the "Sorry, the product was not found."
In this example it was caused by which should have been or .
In my case this is the incoming landing url so I can't do anything to fix this but would like to find a solution for the PHP warning if possible. This is line 99 from class.user_tracking.php
PHP Code:
$page_desc = defined('HEADING_TITLE') ? HEADING_TITLE : (IS_ADMIN_FLAG !== true ? NAVBAR_TITLE : "");
So, I the "old days" it seemed like every page that could possibly be landed on on the catalog side had NAVBAR_TITLE defined and that basically none of the admin pages did... As such, it seemed "right" to use a rule that worked that way...
Guess not the case.
Would suggest changing
Code:
IS_ADMIN_FLAG !== true
In that line to:
Code:
defined('NAVBAR_TITLE')
Re: User tracking mod ZC 1.5.7b / PHP 7.4 Warning: Use of undefined constant
Thank you that solved the issue.
To test I removed my admin IP so it would be tracked. On deleting the record this then highlighted another warning.
PHP Code:
[31-Jan-2021 00:40:26 UTC] Request URI: /ADMIN/index.php?cmd=user_tracking, IP address: xxx.xxx.xxx.xxx
#1 require(../ADMIN/user_tracking.php) called at [../ADMIN/index.php:11]
--> PHP Warning: Use of undefined constant TEXT_HAS_BEEN_DELETED - assumed 'TEXT_HAS_BEEN_DELETED' (this will throw an Error in a future version of PHP) in ../ADMIN/user_tracking.php on line 267.
Line 267
PHP Code:
$deleted_session_text = $_POST['delsession'] . TEXT_HAS_BEEN_DELETED . ' has been deleted. <br />';
Despite excluding my admin address it is now still being tracked. When I delete I get
Quote:
77ca6d2efef563fca5f494ebf137698fTEXT_HAS_BEEN_DELETED has been deleted.
Also there doesn't seem to be a define for TEXT_HAS_BEEN_DELETED in the language file?
Re: User tracking mod ZC 1.5.7b / PHP 7.4 Warning: Use of undefined constant
Quote:
Originally Posted by
Brent
Thank you that solved the issue.
To test I removed my admin IP so it would be tracked. On deleting the record this then highlighted another warning.
PHP Code:
[31-Jan-2021 00:40:26 UTC] Request URI: /ADMIN/index.php?cmd=user_tracking, IP address: xxx.xxx.xxx.xxx
#1 require(../ADMIN/user_tracking.php) called at [../ADMIN/index.php:11]
--> PHP Warning: Use of undefined constant TEXT_HAS_BEEN_DELETED - assumed 'TEXT_HAS_BEEN_DELETED' (this will throw an Error in a future version of PHP) in ../ADMIN/user_tracking.php on line 267.
Line 267
PHP Code:
$deleted_session_text = $_POST['delsession'] . TEXT_HAS_BEEN_DELETED . ' has been deleted. <br />';
Despite excluding my admin address it is now still being tracked. When I delete I get
Also there doesn't seem to be a define for TEXT_HAS_BEEN_DELETED in the language file?
If I understand correctly there's basically one issue in the above: incomplete attempt to move hard-coded text to a language definition.
I know that my plan was to change the way that line was generated by using sprintf to plug in the content into the text. I had a couple of reasons to do that, one was to allow other css to be easily incorporated (although possibly in the language define) the other was so that the applicable deleted item could be placed in the language statement as appropriate for the language.
I'll prep a solution (commit) and post the link to it shortly.
