PmWiki | Cookbook / TotalCounter-Archive

TotalCounter Archive

Old, archived discussions about TotalCounter

Great recipe! I wonder if it's possible to have a referrer statistic per page in order to find out which page is accessed by which other page within the wiki? (I admit that this might not fit the original design philosophy of "counting totals" :-) --Henning December 28, 2005, at 05:32 AM

Well, it is certainly possible, but this would mean to have a statistics page for every wiki's page and it would start to be quite cumbersome. This looks more like the job for a log analyzer which is really not what TotalCounter is supposed to be... I just wrote it to have some basic stats when the hosting service doesn't provide the logs.

Blues December 29, 2005, at 04:49 AM

Thanks for the answer! Though I do indeed have some (not very smooth) way of accessing the logs, an integrated tool that keeps tracks of everything without postprocessing overhead would of course hold considerable attraction. However, I don't think that it would be a good idea to turn an elegant tool into a complex kludge for that purpose! :-/ --Henning December 30, 2005, at 04:30 AM

It's a matter of points of view... As you understand, making the logging at the time of the page view adds an overhead every time a page is viewed (and anyway the logging is already done by the webserver, so is double work) while a log analyzer has an overhead just when the logs are processed, not interfearing with normal page views.

Blues January 03, 2006, at 03:40 AM

I admit that I had thought of the administrator's overhead and not of the system's, but of course you have a very good point there! --Henning January 03, 2006, at 05:27 AM

~~In order for users to work UserAuth should be installed. AuthUser doesn't work.~~ ~~Additionally, you may have to set:~~

~~$TotalCounterBlacklist[Pages]=array("");~~

~~$TotalCounterBlacklist[Users]=array("");~~

~~$TotalCounterBlacklist[Referers]=array("");~~

~~in config.php to remove some foreach errors that will appear on all pages.~~ ~~Finally, the ?totalcounter page will display some errors until a webbot searches your site.~~ (totalcounter 1.0) TheWag 2 January 2006 at 9:45 AM

Thanks for reporting the problems, a new version is available (1.1) which now works with both UserAuth and AuthUser and fixes the bug that appears when no web bot is present yet. About the blacklist I couldn't reproduce the problem... any more info?

Blues January 03, 2006, at 03:40 AM

Thanks for the quick response. I'm running pmwiki(2.1 beta 17) php(4.4.0r4) on a gentoo linux system. Some of that is probably useless. With those threee code lines commented out I get the following three errors:

~~Warning: Invalid argument supplied for foreach() in cookbook/totalcounter.php on line 224~~

~~Warning: Invalid argument supplied for foreach() in cookbook/totalcounter.php on line 237~~

~~Warning: Invalid argument supplied for foreach() in cookbook/totalcounter.php on line 251~~

~~I did upgrade to the new version on TotalCounter(1.1) and the error is still persistant.~~ TheWag 4 January 2005 at 20:39.

Maybe this will help. I've also encountered the same errors you're describing but after declaring those 3 aforementioned variables before the inlcude statement, the errors disappeared. Here's how my config file looks:

$TotalCounterBlacklist[Pages]=array("");
$TotalCounterBlacklist[Users]=array("");
$TotalCounterBlacklist[Referers]=array("");
include_once('cookbook/totalcounter.php');

soxiam

I uploaded a new version (1.1b) that hopefully will correct the problem, along with some other things. I have to admit that I had to go blindly since on my computer it works fine (PHP 4.3.11). Thanks for your patience.

Blues January 05, 2006, at 08:32 AM

All items afore mentioned problems I encountered are fixed in 1.1b. Thanks for the quick updates Blues. Also like the fix of Group/Page and Group.Page problem. How crazy would it be to get the option to change the display preference on that (slash or dot?)? TheWag 6 January 2006 at 10:35

The markups for TotalCount and PageCount didn't work in 2.1beta20. Jean DEMARTINI posted a fix on the pmwiki mailinglist:

Markup('','<','/\\{\\$PageCount\\}/e',$PageCount);

Markup('','<','/\\{\\$TotalCount\\}/e',$TotalCount);

Peter Brink 17 January 2006 at 12:59

Thanks for the info, I uploaded a new version (1.1c) fixing this problem.

Blues January 17, 2006, at 07:52 AM

Locations are only recognized correctly, if the TLD is in lower case. We get a lot of hits that are resolved as .DE (instead of .de) which are then classified as "unknwon". Perhaps an i-Modifier should be added to the host-matching regex.

tthelen January 28, 2006

I will correct this problem and release a new version soon. Thanks for pointing it out.

Blues January 30, 2006, at 02:57 AM

New version (1.3) corrects this problem.

Blues January 30, 2006, at 04:23 AM

We encountered problems when using totalcounter for a wiki farm and some fields use a different $DefaultGroup than the farm's default. Since totalcounter.php sets $pagename if it's not set, you must alter your farmconfig to ensure that totalcounter.php is included after the field's config. Example from our farmconfig.php:
$EnableLocalConfig=0; # turn off auto-loading field config after farmconfig
## include field config here if (file_exists('local/config.php')) include_once('local/config.php'); elseif (file_exists('config.php'))include_once('config.php');
# now do farm config that overrides local settings or has to be performed after local config include_once("$FarmD/cookbook/totalcounter.php");

tthelen January 26, 2006

Thanks for reporting this, I added a note above in the Notes section and in the Configuration section.

Blues January 26, 2006, at 06:22 AM

Although it seems to work perfectly on my local home copy, as soon as I set it on my provider (free.fr) system I cannot access my pmwiki farm anymore (any page). My home system runs under windows while the other runs under Linux. Is there some specific file access rights issue?

Philippe January 23, 2006

What means you can't access the pages anymore? Does it display any error? Or they are just blank? The recipe uses only one file in the wiki.d directory: the file is .total.counter. Since the directory already has write permissions there shouldn't be problems... give a look anyway, and please let me know.

Blues January 23, 2006, at 03:12 AM

No error, only time-out. I've made some tests without the farm and without any recipes except this one. The first time I call the page it's OK (as for the farm). Any next call remains without any answer. When I've deleted the file .total.counter and the folder .total.counter.lock, I can play again once. The access rights for .total.counter are 644 and for .total.counter.lock 755. Unfortunately I'm not allowed to change the access rights (for security reason on the server).

Philippe January 23, 2006, at 08:30 PM

The first call successfully creates the lock file but cannot delete it because of file permissions, so the next calls find it still locked and don't continue... It looks like in your system the files are created with wrong permissions, I'll see how to correct it.

Blues January 24, 2006, at 03:04 AM

I think I found the problem, please download the new version (1.2) and let me know if it works OK.

Blues January 24, 2006, at 03:38 AM

I've deleted the total.counter files with ftp and uploaded the version 1.2. The symptom remains the same. I've tried to remove the code associated with the lock folder ($lock) in totalcounter.php. With this, I can call the pages and the counter counts ! But I can imagine the effects of removing the lock...

Philippe January 23, 2006, at 08:30 PM

With the new version (1.2) how are the permissions in the created files? It should be 777 for the lock directory and 666 for the .total.counter file.

Blues January 25, 2006, at 02:36 AM

As I've said a little higher the permissions are 755 for the lock directory and 644 for the file. It's what my ftp tool tells me... Maybe be it's a limitation of the web server (chmod is forbidden under php for example). Don't hesitate to request me some test. I will do my best.

Philippe January 25, 2006, at 11:16 PM

Yes I've read that but the new version should create the files with correct permissions. If it is still wrong I will try with another approach...

Blues January 26, 2006, at 03:00 AM

Let's try this new version: now it should use the same permissions that PmWiki uses for its own pages.

Blues January 26, 2006, at 03:07 AM

Sorry, I hadn't catch your question, but the permissions are still the same even with the last version. And the problem is still there... Free.fr runs in safe_mode. If I've understood correctly that means he checks if the script has the same UID than the file being used...

Philippe January 27, 2006, at 09:16 PM

I've just checked on free.fr ... rmdir PHP function is forbidden. So, no way. Sorry for inconvenience.

Philippe January 28, 2006, at 09:05 AM

If all you need is a lock flag, use a file instead of a directory, using :
unlink($lock) instead of rmdir($lock),
and touch($lock) instead of mkdir($lock)
I tried on Free.fr, it works for me (changes made on v1.2b)

Emmanuel January 28, 2006, at 10:11PM (UTC)

Emmanuel is correct, with a file lock it will work. The reason that the script uses a directory instead than a file is that the function mkdir() is atomic (meaning that it is executed in one step and can't be interrupted), while theoretically the file creation could be interrupted and two different scripts could acquire the lock. Now, seeing the problems, I guess we can accept the risk and change it to create a file for lock. I will release a new version soon.

Blues January 30, 2006, at 02:57 AM

New version (1.3) should now work correctly.

Blues January 30, 2006, at 04:23 AM

You forgot to change rmdir in your lock loop (line 91). And could you please tell me where to find official information about atomic operations in php (in my mind, touch and unlink are atomic operations...), I couldn't find anything. Thanks.

Emmanuel January 30, 2006, at 10:30AM (UTC)

Yes you are correct, I re-uploaded it, sorry. For the discussion about the atomicity of the lock functions give a look at http://www.php.net/manual/en/function.flock.php

Blues January 30, 2006, at 09:10 AM

Thanks a lot. Seems to work perfectly now.

Philippe February 03, 2006, at 09:39 PM