hello the hit counter in the article footer increments with each page refresh. I'm not sure if this is a bug or a missing feature. Are others experiencing the same issue ? thanks a lot
Extension talk:HitCounters/Archive 2
I'm not sure if the MediaWiki structure can distinguish a ‘refresh’ from a regular view.
shouldn't we use cookies for that ?
Radio Yerevan: In principle, yes, but ...
In Germany/EU we have the problem/feature that every setting of a cookie must be actively confirmed by the visitor, which makes the use of cookies appear questionable.
Greens and Woke are making the internet increasingly unusable...
The thing is that not all visitors ‘refresh’ and many don't even care about the number of hits. It is therefore doubtful that all visitors should be bothered via cookie write confirmations.
Aren't session cookies considered "strictly necessary cookies" and therefore not requiring user consent ? so we could use $_SESSION['HitCounters'] = []; with all the visited articles, and increment the counter only if the article is not in the array. An option to exclude bots by checking $_SERVER['HTTP_USER_AGENT'] may also be added.
1. [In Europe] ALL cookies are requiring user consent. Also so called "strictly necessary cookies".
2. It is at least arguable that such a cookie is to be considered as a "strictly necessary cookie".
Is it really wrong to count it as a new hit? After all, it is a separate view?
Maybe you could look at the pragma header. I think some browsers send pragma: no-cache on refresh, but im not sure if that is all browsers.
It leads to a difficult and lengthy discussion (with an open outcome) as to what counts as a valid ‘hit’. Does this include editing the content? Does it include proofreading by Wikipedia contributors? What about bots, admins etc.?!??
from this page https://gdpr.eu/cookies/ I see that it is indeed arguable that such cookies are considered "strictly necessary cookies", indeed they could be considered "Statistics cookies". However, for not being used to identify natural persons, the user consent should still not be required as far as I understand. (this in relation to the GDPR, I don't know if other regulations are in force) Regarding the observation about "hits", indeed an hit could also include a page refresh, so the extension is not necessarily buggy. However I think it should be able to distinguish between hits (or "impressions") and visits. Because indeed authors of articles may access the same article dozens of times during a session while they edit it, these shouldn't be considered multiple visits, otherwise you find yourself in the situation (for non high-traffic websites) where a significant part of the hits belong to the editors of the article (and bots) thus invalidating the count.
Technically speaking, a refresh is also a ‘hit’. The question to be answered is what purpose the extension should serve. If you want to measure the reach, it is not the same whether ten readers visit a page or whether there were ten refreshes or ten corrections.
For proofreaders, the fork provided by us has created the option in the personal settings to exclude themselves from the hit counts.
This means that even those who frequently use refreshes can exclude themselves from the count.
hello @WikiForMen yes, regarding hits = page refresh you are right, I was confirming it. I will check your fork and I will try to propose a patch with the distinction of visits from hits. All the best
Is it true that the "View statistics" are being generated by the HitCounters extension?
If you e.g. watch https://en.intactiwiki.org/wiki/Special:Statistics you see this section prior to the "Most viewed pages" section which indeed reflects the hits counted by HitCounters since 2021-03-22. If so, then no other global hits counter tool might be necessary to track the total hits of a mediawiki installation, right?
I just ask this because I didn't find any information about the side-effects of HitCounters to the SpecialPages:Statistics.
You have 1.262 articles (see here) and you can fix wrong statistic value (1.132) with Extension:RefreshSiteStatsTable.--WikiForMen (talk) 12:44, 6 April 2021 (UTC)
I have installed the RefreshSiteStatsTable extension now and ran it. But it makes me wonder that before I ran it, e.g. my French wiki had 8 articles, and afterwards it only counts 7. Does your script exclude the Main page? See <https://fr.intactiwiki.org/index.php/Accueil> as an example.
Please take a look at the code, which is very simple:
$anzahl_counted_good = (int)$this->mDBr->selectField( 'page', 'COUNT(*)', [ 'page_namespace' => NS_MAIN, 'page_is_redirect' => 0 ], __METHOD__ );
It is a simple DB query how many entries are in the table page that have the namespace NS_MAIN and are NOT a redirect. And then updates the field ss_good_articles in the table site_stats is updated.
The main page is treated like all the others. In my wiki for example the main page is not counted, because there the main page is not in the namespace NS_MAIN, but in the namespace project.
The extension does in the browser what the maintenance script
php maintenance/initSiteStats.php --update
does on the command line of the server.
The result should be the same according to Adam Riese. ;-) --WikiForMen (talk) 11:16, 8 April 2021 (UTC)
I wonder that the extension RefreshSiteStatsTable should have run, when it used class DBConnect a class from the extension CountingMarker, which you hardly had installed... --WikiForMen (talk) 16:42, 8 April 2021 (UTC)
The HitCounters extension is, of course, quite primitive tool. It does not distinguish visits from reds and other. Therefore, other tools can provide finer and completely different results. Nevertheless, I appreciate HitCounters, because I have all visits since the beginning of counting for all articles and so I can recognize by relative changes/shifts, which articles currently experience special interest.--WikiForMen (talk) 12:28, 6 April 2021 (UTC)
Is there any way to track views per page by time period? For example show the five most popular pages (with views from the day) from each day of the past month. If not, could it be added? This seems useful to track pages that were created more recently, as currently they'll be near the bottom of the PopularPages list.
Hello everyone, I'm looking to upgrade a wiki from version 1.24 to the current MW version. Currently, it's using the "TopTenPages" extension for tracking view counts. I've noticed that "TopTenPages" has eventually become dependent on "HitCounts". However, the "HitCounts" extension is not currently installed. Is it possible to migrate from "TopTenPages" to "HitCounts" and then follow the instructions to preserve the view counts for the updated wiki?
Hopefully you have followed these instructions while upgrading:
If not, you will have eliminate your hitcounter values. ;-)
For upgrading a wiki from version 1.24 you have to install HitCounters version compatible with REL1_25, i.e.:
So you should upgrade first to version 1.25, install HitCounters REL1_25-v0.5.0, update your database ("maintenance/update.php"). This will save your hitcounter values into a new hitcounter table. After that you may upgrade to a current MW version.
Thanks for these very clear instructions!
You may have a backup of your database.
1. You may start with the backup of your database, following the steps above mentioned.
2. You may use a parallel installation with DB name "25_yourdatabasename" and Domain 25.yourdomain.org and following the above mentionend steps. Then you may copy manually both database tables "hit_counter" and "hit_counter_extension" from DB "25_yourdatabasename" into "yourdatabasename".
Is it possible to make Special:PopularPages transcludable? If yes, how?
In the older Extension:TopTenPages extension it was possible to do something like:
<TopTenPages offset=0 >30</TopTenPages> || {{Special:ContributionScores/25/100}}
but this attempt didn't work {{Special:PopularPages}}, it shows the URL only
1. In HCUpdater.php the stuff around 'rename_table.sql' should be removed, because it is only needed in MediaWiki in Version 1.25.
2. In HitCounters.hooks.php the "$contLang->formatNum()" does not set the punctuation correctly in the internationalisation of the comma number:
$totalViews = HitCounters::views() ?? 0;
$extraStats = [
'hitcounters-statistics-header-views' => [
'hitcounters-statistics-views-total' => $totalViews,
'hitcounters-statistics-views-peredit' => $contLang->formatNum(
$totalViews
? sprintf( '%.2f', $totalViews / SiteStats::edits() )
: 0
) ],
'hitcounters-statistics-mostpopular' => self::getMostViewedPages( $statsPage )
];
Moreover, it does not prevent the division by zero.
This should do the job accurately:
$totalEdits = SiteStats::edits() ?? 0;
$totalViews = HitCounters::views() ?? 0;
$extraStats['hitcounters-statistics-header-views']
['hitcounters-statistics-views-total'] = $totalViews;
$extraStats['hitcounters-statistics-header-views']
['hitcounters-statistics-views-peredit'] =
( $totalEdits > 0 )
? sprintf( '%.2f', $totalViews / $totalEdits )
: 0;
) ],
'hitcounters-statistics-mostpopular' => self::getMostViewedPages( $statsPage )
];
3. In SpecialPopularPages.php, what exactly is "getPrefixedText()" doing here?
$link = $this->getLinkRenderer()->makeKnownLink(
$title,
$this->getContentLanguage()->convert( $title->getPrefixedText() )
);
I guess, this is doing the job as well:
$link = $this->getLinkRenderer()->makeKnownLink( $title )
);
--WikiForMen (talk) 18:55, 4 October 2023 (UTC)
This is probably more likely to be seen on Phabricator. If you have a specific patch in mind, submit it to Gerrit.
I did install this extension however the Special:PopularPages is limited to 10000 entries (navigating using offset= in the URL).
It's not cached and i.e. Special:ShortPages on the same wiki is capable of displaying items from 10001 and more (the wiki have about 80000 articles).
Is there a way to make it so it loads more than 10000 entries? I did check the code and it seems there are no visible limit in this extension and the special page itself is marked as not expensive (so MiserMode shouldn't have effect on it).
I found this in "abstract class QueryPage":
/**
* Get max number of results we can return in miser mode.
*
* Most QueryPage subclasses use inefficient paging, so limit the max amount we return
*
* @stable to override
* @since 1.27
* @return int
*/
protected function getMaxResults() {
// Max of 10000, unless we store more than 10000 in query cache.
return max( $this->getConfig()->get( 'QueryCacheLimit' ), 10000 );
}
Try to add this into "class SpecialPopularPages":
protected function getMaxResults() {
$your_limit = 20000;
return max( $this->getConfig()->get( 'QueryCacheLimit' ), $your_limit );
}
--WikiForMen (talk) 19:09, 4 October 2023 (UTC)
MediaWiki 1.39.1 PHP 7.4.3-4ubuntu2.19 (apache2handler) MySQL 8.0.34-0ubuntu0.20.04.1 ICU 66.1
HitCounters-REL1_39-e759c39.tar.gz
did the composer install and ran the update script. I get
[35f31966c348bbdee9c42ea7] /Special:PopularPages Error: Class 'MWNamespace' not found Backtrace: from /var/www/html/wiki/underfoot/extensions/HitCounters/includes/HitCounters.body.php(134) #0 /var/www/html/wiki/underfoot/extensions/HitCounters/includes/SpecialPopularPages.php(52): HitCounters\HitCounters::getQueryInfo()
and
Fatal error: Declaration of MWCallbackStream::write($string) must be compatible with Psr\Http\Message\StreamInterface::write(string $string): int in /var/www/html/wiki/underfoot/includes/http/MWCallbackStream.php on line 46
I see https://www.mediawiki.org/wiki/Manual:MWNamespace.php/en says
This feature was removed from MediaWiki core in version 1.39 (phab:rMWea1c106ea9a3) (after being deprecated in 1.34). Please see NamespaceInfo.php for an alternative way to use this feature.
[Bug: T291389] should be fixed since Oct 10, 2021. See: https://github.com/wikimedia/mediawiki-extensions-HitCounters/commit/d0f37b82b53368fc2bb50c2ff3ce29ba0b3b4cbc
I got help at https://phabricator.wikimedia.org/T347678, and while I got the counters working the use of composer triggered dependency problems elsewhere in my test wiki
We downloaded the 1.35 version of the Extension for our MediaWiki 1.35 version and installed, successfully ran update.php, and see the hit_counter and hit_counter_extension tables in our database.
No matter how many times I visit pages on our wiki, no record gets created in either table though.
I see warnings in log about "use of undefined constant DB_PRIMARY" in ViewCountUpdate.php (that it seems to resolve fine), which tells me that the scripts are being called. I tried changing the script to get a log statement to print which failed, and the script's existing wfDebugLog statements dont appear in logs either.
I used mysql commands to insert a record artificially into hit_counter table with a page_id and view count, and visiting that page will display "page has been accessed 5 times" at bottom, as well as appearing now on Popular Pages. But will still not increment on its own (even when other users, signed in or not, visit pages).
Suggested solutions on similar posts below did not help either. Anyone have any ideas what we could try at this point?
Change "( DB_MASTER )" into "( DB_PRIMARY )" in the PHP code or check out https://github.com/WikiMANNia/Mediawiki-Extension-HitCounters/releases/tag/REL1_35-v0.4.0 --WikiForMen (talk) 22:59, 31 May 2023 (UTC)
Hi there. First time installing this extension. I put the folder in the extensions directory. I added the include to localsettings. I went to /mw-config to update the database and it's on the "installation complete" screen. So i went ahead and restarted the whole installation. Completed. But when I load a page full of code not unlike what people have documented here previously. It seems like this would be simple enough but I don't know what else to do.
I'm guessing the database was not updated and looking at it, I'm not seeing a hitcounters table either, so yeah. How can I force the database to add the HitCounters tables? Do I need to have the include turned ON in localsettings when running the upgrade? (I had to turn it off because the wiki was inaccessible to my users)...
UPDATE! yes! in fact, you DO need to have the loadextension in localsettings turned on when running the database update/restart installation. It now works!
Thanks for noting that you have to Restart the update script, not mentioned anywhere else.