Extension talk:HitCounters/Archive 2/Flow export

Please create Phabricator tasks if you run into bugs
I need bug reports in Phabricator so that they can be worked on. If you run into a problem with one of the following, please create a phabricator task and link to it here. -- ☠MarkAHershberger☢(talk)☣ 16:03, 30 July 2016 (UTC)

--> Archived talk

Installation in MW 1.23?

The infobox tells that this extension is compatible with MW 1.25 or higher. The installation chapter says insistent: "Use MediaWiki 1.25 and install this extension. Still in MediaWiki 1.25, run update.php.". Yet a few lines later in the installation chapter the instructions regarding the needed code in the LocalSettings.php file are suggesting that one can install this in MW 1.24 or in an earlier version. Why should one do this if exact MW 1.25 is needed?

Or, asked the other way around, if I do this:

  1. Installation of this extension in MW 1.23.17
  2. Running update.php after installation in MW 1.23.17
  3. Update to MW 1.31.1
  • Hit counters are still available and counting??? Wgkderdicke (talk) 07:42, 6 June 2019 (UTC)
The MW 1.24 stuff was indeed not needed and misleading.
This is how I have done it many times.
  1. Backup database
  2. Update software, in your case from 1.23.x to 1.31.x including extensions (DO NOT run update.php)
  3. Install HitCounters and invoke it in LocalSettings.php
  4. Now run update.php
  5. That's it.
I am not sure if HitCounters is installable for MW 1.24 and earlier. [[kgh]] (talk) 15:24, 6 June 2019 (UTC)
Shouldn't your way mentioned in the installation chapter also? Because at the moment the installation chapter tells me this:
  1. Coming from < MW 1.25, that, firstly, I have to install MW 1.25 (update software & run update.php)
  2. Then I have to install this extension here
  3. After that I have to run update.php under MW 1.25 with this extension installed
  4. And at the end I have to install MW 1.31, for example (update software & run update.php)
Your solution skips the complete MW 1.25 installation and it seems that with the installation of this extension in addition to the update to MW 1.31 with a update.php runthrough only once one gets two things at a single stroke. Wgkderdicke (talk) 20:21, 6 June 2019 (UTC)
Hmm, the more I think about this ... I believe I made a big mistake here. It is over two years ago I last did this. Yeah, do this:
  1. Backup database
  2. Update software, in your case from 1.23.x to 1.25.x including extensions (DO NOT run update.php)
  3. Install HitCounters and invoke it in LocalSettings.php
  4. Now run update.php
  5. Update software from 1.25.x to 1.31.x including extensions
  6. Run update.php
  7. That's it.
In the end the docu is correct and you understood correctly. [[kgh]] (talk) 21:21, 6 June 2019 (UTC)

API and HitCounter

Is it possible to read the total hits from the database by using the API-interface?


Kind regards from Basel, Switzerland

Thomas


195.141.167.186 (talk) 10:41, 22 July 2019 (UTC)

Not right now, but I saw Extension:PageViewInfo and thought it would be good to add support for that. ☠MarkAHershberger☢(talk)☣ 13:43, 22 July 2019 (UTC)
Would be nice. 195.141.167.186 (talk) 15:13, 22 July 2019 (UTC)
Can I vote this up? The format of the data is difficult for my customers to import into excel. TespSam (talk) 16:36, 16 April 2021 (UTC)

Special:PopularPages redirects to Special:Beliebteste_Seiten (German)

RESOLVED
This was reported with T236012 and fixed in the meantime.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Version 0.3

1. Despite a default MediaWiki language of "en", Special:PopularPages actually uses the page name Special:Beliebteste_Seiten.

This may be due to an error in HitCounters.i18n.alias.php using "en" not "de": $specialPageAliases['en'] = [ 'PopularPages' => [

'Beliebteste_Seiten' ], ]; Amousey (talk) 22:07, 3 October 2019 (UTC)

This was reported with T236012 and fixed in the meantime. [[kgh]] (talk) 13:47, 21 October 2019 (UTC)
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Installation in 1.26+

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Despite the scary warning, installing under 1.35a works fine, and at a glance I don't see any reason in the code why it wouldn't. Anyone knows what that's about? Tgr (talk) 21:31, 10 November 2019 (UTC)

The warning is about doing upgrades, and loosing the "old" visitor counts from the "page" table because upgrade.php of MediaWiki 1.26 and newer deletes them. Have a look at Extension talk:HitCounters/Archive for details. (You can also run the migration SQL from https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/HitCounters/+/master/sql/ manually before updating to 1.26 or newer.)
If you do a new installation and don't have any data to migrate, you can IMHO ignore the warning. Cboltz (talk) 23:34, 10 November 2019 (UTC)
That's the opposite of what the template says, though (Currently it is only possible to migrate wikis using MW 1.25 to use this extension. A fresh install in MW 1.26 and higher is not possible!). Tgr (talk) 23:49, 10 November 2019 (UTC)
Please re-read the template - the important part is the word "migrate", and all text in that box talks about migration and updating. The next sentence after what you quoted says (highlighting done by me)

[...] an update to MediaWiki 1.26 or newer can permanently delete your hitcounter numbers! See task T120216.

So if you ignore this warning, you will loose the old visitor count from the page table - but in a fresh installation, you have 0 visits, and therefore don't loose anything.
That's at least how I interpret this warning, and also what I expect based on the experience with this extension. Besides this, the fact that it works for you in a fresh install also confirms this.
So: don't worry too much ;-) Cboltz (talk) 19:58, 14 November 2019 (UTC)
Updated the warning. Tgr (talk) 03:52, 15 November 2019 (UTC)
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Does it also count action=render and action=raw views?

When accessing a page through action=raw or action=render, is a view supposed to be counted?

According to my tests, they sometimes count as a view and sometimes do not. Is action=render and action=raw supposed to count or not?

I also tested with action=edit and action=history, which apparently count no views. Correct me if I'm wrong. 79.249.152.18 (talk) 15:19, 4 October 2020 (UTC)

If there is an inconsistency, that is a bug. Please file a bug with your findings. ☠MarkAHershberger☢(talk)☣ 16:05, 5 October 2020 (UTC)
Sorry for late response.
Like that other comment noted, yes, the apparent inconsistency might be caused by caching and/or delayed database updates.
I might run another test soon.
----
But, as already asked, is HitCounters supposed to also count views on pages accessed with the action=raw and action=render URL parameters, or only when viewed normally? 79.249.157.79 (talk) 21:26, 22 October 2020 (UTC)
I have done my own testing. Next to the default action=view, only action=render does count as view. action=raw does not.
I suggest other users to test it as well and share their results here. 79.249.159.65 (talk) 21:57, 24 October 2020 (UTC)
I can confirm this too, but whether revision views count as a view is not tested so far. Maybe I will do it later.
But I think it does count as well, regarding ?action=render counts. 84.147.35.92 (talk) 23:49, 28 October 2020 (UTC)
Tested that. It counts as well. 84.147.35.52 (talk) 04:45, 30 October 2020 (UTC)
I have tested it it as well. Same results.
The render action counts as view, but not raw, and also not info, edit and exporting. 198.24.162.179 (talk) 06:27, 26 October 2020 (UTC)
Hello, Mark.
I can't speak for the user above, but these perceived inconsistencies might be related to caching.
I came here because I had the same question as IP 79.249:
Which of the actions do supposedly count as view?
(This should be documented on the article.) 198.24.162.179 (talk) 10:12, 13 October 2020 (UTC)

Live Updates since 1.35.0 upgrade

I've noticed that the hit counters on my site are updating live, even over the 100 limit listed on the extension page, since upgrading to 1.35.0 last weekend. Is anyone else noticing this? 2601:646:8E01:1740:158A:E49A:ADD3:F161 (talk) 22:28, 11 October 2020 (UTC)

Pinging @GregRundlett since I know he uses this extension to see if he has any similar reports. ☠MarkAHershberger☢(talk)☣ 15:11, 12 October 2020 (UTC)

Template:NUMBEROFVIEWS for specific articles?

{{NUMBEROFVIEWS}} usually displays the total view count of the wiki.

Is there any way to have {{NUMBEROFVIEWS}} for specific articles?

I tried out {{NUMBEROFVIEWS|Example}} , but it did not work.

If there is no way, I suggest it as a new feature. 198.24.162.179 (talk) 17:43, 18 October 2020 (UTC)

I believe you would have to create a phabricator task for that. ☠MarkAHershberger☢(talk)☣ 19:02, 18 October 2020 (UTC)
As a magic word, I guess it would need to be something like {{NUMBEROFPAGEVIEWS:PageName}}, which would show the view count for the current page if none specified. 79.249.157.79 (talk) 21:13, 22 October 2020 (UTC)

Feature suggestion: Views since last change

As a MediaWiki administrator, I suggest an option to display the view count since the last change, to provide a rough idea of how many people have read the current revision of a page.

For example: “This page has been accessed 21948 times; 1827 times since the last edit.”

For that, it would only have to memorize the edit count upon saving the last edit, and subtract that from the current view count.

If that is considered out-of-scope, one could create a simple separate extension for this purpose. 46.114.106.133 (talk) 11:04, 5 November 2020 (UTC)

I don't think it is out of scope. Could you create a phabricator task with this request? ☠MarkAHershberger☢(talk)☣ 15:47, 5 November 2020 (UTC)

update.php did nothing

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Installing into 1.35.0 did not update the database. php update.php did nothing and I get errors on our wiki saying the table cannot be found.
[X9rTt6Dou00@cr2kmZ5c4AAAAMA] /index.php?title=Main_Page Wikimedia\Rdbms\DBQueryError from line 1699 of /var/www/mediawikis/wiki-1.35.0/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Emikulic (talk) 03:54, 17 December 2020 (UTC)
Did you run /maintenance/update.php or /extensions/HitCounters/update.php? You'd run the first one. Ulf Dunkel (talk) 11:30, 23 March 2021 (UTC)
I guess, what /maintenance/update.php will run /extensions/HitCounters/update.php of all extensions.--WikiForMen (talk) 17:50, 24 March 2021 (UTC)
I have just done a new installation. If the checkbox "HitCounters" is ticked during the first installation, the DB table "hit_counter" is created immediately during the first installation. If the extension HitCounters is added after the initial installation, php update.php must be called up again on the command line and the DB table "hit_counter" is created subsequently. Both variants work. WikiForMen (talk) 20:31, 18 December 2020 (UTC)
I see two tables: hit_counter and hit_counter_extension, the latter being empty. Ulf Dunkel (talk) 07:51, 25 March 2021 (UTC)
I will have to try again. Will let you all know how it goes. Emikulic (talk) 19:36, 21 December 2020 (UTC)
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

How to get total articles views contributed by single user?

Suppose I have published 10 articles and each articles carries different number of views so i want to get total articles views count. What is the possibility? Even if i directly want to retrieve single user total hit counter what is php code? 2405:204:12AC:AF6B:54A1:60D6:4648:321 (talk) 15:49, 15 February 2021 (UTC)

The wiki concept of publishing articles doesn't see single authors. Each article should be maintainable by all authors. So I wonder if HitCounters is the desired tool here. What if you create a browser bookmarks folder and add a bookmark for each article you want to track? You can have the browser open them all at once and check the # of views for each article then. Ulf Dunkel (talk) 12:57, 25 March 2021 (UTC)

Can I edit the output string to assign a start date?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I run a wiki for several years now and have installed HitCounters as of today. Now my MainPage shows the line

"This page has been accessed 8 times."

How can I adjust these strings and add a date, like e.g.

"This page has been accessed 8 times since 2021-03-22."

I didn't find any such string in /extensions/HitCounters/i18n/ or elsewhere in its extension folder. Ulf Dunkel (talk) 10:55, 22 March 2021 (UTC)

You can edit in HitCounters/i18n/en.json
"hitcounters-viewcount": "This page has been accessed $1 times.",
and change it into
"hitcounters-viewcount": "This page has been accessed $1 times since 2021-03-22.",
--WikiForMen (talk) 20:10, 22 March 2021 (UTC)
I agree it should be "hitcounters-viewcount" rather than "viewcount" starting from MW 1.36+. I tried to create a patch. [[kgh]] (talk) 10:14, 25 March 2021 (UTC)
He is using MW 1.32.2. The key "hitcounters-viewcount" is missing in all i18n files of the HitCounters extension. --WikiForMen (talk) 00:57, 26 March 2021 (UTC)
The version of HitCounters is calling the "hitcounters-viewcount" key instead of "viewcount"? [[kgh]] (talk) 07:17, 26 March 2021 (UTC)
As a developer I use since years my own version of extension HitCounters, compatible with 1.25+ until 1.35+, there I passed "viewcount" from /languages/i18n/en.json into "hitcounters-viewcount" in /extensions/HitCounters/i18n/en.json as all HitCounters messages have the "hitcounters-keyname" structure. See here. I have no idea, why "viewcount" was left behind in the core.--WikiForMen (talk) 14:26, 26 March 2021 (UTC)
Thank you for this hint, but the mentioned string is not in my en.json file which I also re-checked from the current master. Mine reads as follows:
{
"@metadata": {
"authors": [
"Mark A. Hershberger"
]
},
"hitcounters-extensionname": "Hit Counters",
"hitcounters-desc": "Provides per page view statistics",
"hitcounters-page-label": "$1",
"hitcounters-nviews": "$1 views",
"popularpages": "Popular pages",
"popularpages-summary": "",
"hitcounters-pageinfo-views": "Number of views",
"hitcounters-statistics-header-views": "View statistics",
"hitcounters-statistics-views-total": "Views total",
"hitcounters-statistics-views-total-desc": "Views to non-existing pages and special pages are not included",
"hitcounters-statistics-views-peredit": "Views per edit",
"hitcounters-statistics-mostpopular": "Most viewed pages",
"abusefilter-edit-builder-vars-page-views": "Page views",
"abusefilter-edit-builder-vars-movedfrom-views": "Source page views",
"abusefilter-edit-builder-vars-movedto-views": "Target page views"
}
So I guess the string is stored somewhere else. Any further hints? Ulf Dunkel (talk) 08:39, 23 March 2021 (UTC)
If the mentioned string is not in the en.json file, so: insert it! ;-)
It is called in the file includesHitCounters.hooks.php on line 157
$skin->msg( 'viewcount' )
Note that the HitCounters extension was outsourced from the MediaWiki's core code and that you still have the string in question in the MediaWiki's file en.json. --WikiForMen (talk) 12:57, 23 March 2021 (UTC)
What I found now was this:
root@ubuntu:/var/www/vhosts/intactiwiki.org/w/pool# grep -r "has been accessed" *
languages/i18n/en-gb.json: "viewcount": "This page has been accessed $1 times.",
languages/i18n/en.json: "viewcount": "This page has been accessed $1 times.",
languages/i18n/mni.json: "viewcount": "This page has been accessed $1 times?",
tests/parser/preprocess/All_system_messages.expected:This page has been accessed $1 times.
tests/parser/preprocess/All_system_messages.txt:This page has been accessed $1 times.
No change in any of these files shows any effect on the actual page output. Ulf Dunkel (talk) 09:00, 23 March 2021 (UTC)
As I suspected, this string is still in those files, which are from an installation prior to REL 1.25. The creators of the extension apparently forgot to transfer these entries into the extension.
You can transfer them and alter them at your choice. But use "hitcounters-viewcount" instead of "viewcount" as key.--WikiForMen (talk) 13:00, 23 March 2021 (UTC)
I now have added two lines to my /extensions/HitCounters/i18n/en.json file:
"hitcounters-viewcount": "This page has been accessed $1 times since 2021-03-22.",
"viewcount": "This page has been accessed $1 times since 2021-03-22."
No change in my Wiki page footers afterwards. In fact, this file is being read, because when I had a typo in it, my Wiki reported a large amount of error lines until I fixed it. But neither "hitcounters-viewcount" nor "viewcount" seem to be used from this file. Ulf Dunkel (talk) 12:18, 24 March 2021 (UTC)
A. I changed it on my website and it works. See the footer here!
B. Consider caching issues!
  1. Empty the table "l10n_cache" table in your data base.
  2. Run the "runJobs.php" maintenance script.
C. You say, you have added two lines to my /extensions/HitCounters/i18n/en.json file! "en"!!!
But in your wikis is $wgLanguageCode = "de"! Also in the english speaking one!
You should one line to your /extensions/HitCounters/i18n/de.json file:
"hitcounters-viewcount": "Diese Seite wurde bisher {{PLURAL:$1|einmal|$1 mal}} abgerufen seit 22. März 2021.",
--WikiForMen (talk) 17:36, 24 March 2021 (UTC)
Thank you for your patience with me. Where can you see how the $wgLanguageCode for my wikis is set up? I run various language instances which share a CommonSettings.php file but have their own LocalSettings.php files. A grep search for $wgLanguageCode showed only $wgLanguageCode = "en" for my English wiki. Where do I have to check this?
I tried to empty the table "l10n_cache" for my English wiki but got an empty result in phpmyadmin. What am I doing wrong?
I also added the suggested German string to /extensions/HitCounters/i18n/de.json without any change.
Even after I copied the table structure into a new table i10n_cache_backup, deleted i10n_cache, renamed (the empty) i10n_cache_backup to i10n_cache and ran php runJobs.php, there's no change in my footer output. Weird.
Any help is really appreciated. Ulf Dunkel (talk) 07:37, 25 March 2021 (UTC)
Strange! I found also in mediawiki-1.35.1/languages/i18n/de.json this:
"viewcount": "Diese Seite wurde bisher {{PLURAL:$1|einmal|$1 mal}} abgerufen.",
I was sure, that this was removed from the core.
Normally you may set $wgLanguageCode = "de"; for subdomain de.intactiwiki.org and $wgLanguageCode = "es"; for subdomain es.intactiwiki.org, respectively in the corresponding localsettings.php file.
I see on your site in de.intactiwiki.org, en.intactiwiki.org, and es.intactiwiki.org the sidebar, the tabs, and the footer in German language. So I guess that in all your localsettings.php files the variable $wgLanguageCode is set to "de". OK, I see you are using Extension:UniversalLanguageSelector.
I have no glue, what you are doing wrong. :-( You are sure to have upload de.json and en.json into the right folder?
I changed /extensions/HitCounters/i18n/en.json to this:
"hitcounters-viewcount": "This page has been accessed {{PLURAL:$1|once|$1 times}} since 2021-01-01.",
upload it with FTP, and it worked immediately (and without emptying the table "l10n_cache") on "en.wikimannia.org" as you can see yourself. --WikiForMen (talk) 00:39, 26 March 2021 (UTC)
I finally figured out what was going on:
  • I run MediaWiki 1.32.2 and the relevant HitCounters extension 0.3 (7638419).
  • HitCounters 0.3 uses the global "viewcount" key which should be available from /wiki/languages/i18n/'<language>.json.
  • Adding the "viewcount" key or "hitcounters-viewcount" to /extensions/HitCounters/i18n/<language>.json didn't have any effect in Hitcounters 0.3.
  • Because I run multiple language instances of a wiki which share most files from a shared pool, I tried and edited the relevant strings in /wiki/languages/i18n/<language>.json. BUT - I had overseen that all localized wiki instances still had their own /languages/ folders.
  • So I removed them and added symbolic links to /wiki/pool/languages/ in order to have all wiki instances use one shared folder.
Now everything works fine for me. I guess I have to adjust things once more when I update MediaWiki to 1.35 or higher. I stored the enhanced files for me like this:
da.json: "viewcount": "Siden er vist $1 gange siden 22. marts 2021.",
de:json: "viewcount": "Diese Seite wurde seit dem 22.03.2021 bisher $1 mal abgerufen.",
en.json: "viewcount": "This page has been accessed $1 times since 22 March 2021.",
es.json: "viewcount": "Esta página ha recibido $1 visitas desde el 22 de marzo de 2021.",
fi.json: "viewcount": "Tämä sivu on näytetty $1 kertaa 22. maaliskuuta 2021 lähtien.",
fr.json: "viewcount": "Cette page n’a jamais été consultée depuis le 22 mars 2021.",
is.json: "viewcount": "Þessi síða hefur verið skoðuð $1 sinnum síðan 22. mars 2021.",
nl.json: "viewcount": "Deze pagina is $1 keer bekeken sinds 22 maart 2021.",
sv:json: "viewcount": "Den här sidan har visats $1 gånger sedan 22 mars 2021.",
sw.json: "viewcount": "Ukurasa huu umetembelewa mara $1 tangu Machi 22, 2021.",
tr.json: "viewcount": "Bu sayfaya 22 Mart 2021 tarihinden $1 defa erişilmiş.",
As I am not familiar with Arabic, Farsi, Hebrew and find editing rtl texts in Ubuntu's nano editor rather difficult, I left those three languages for my wiki instances untouched so far. Ulf Dunkel (talk) 11:13, 26 March 2021 (UTC)
"BUT - I had overseen that all localized wiki instances still had their own /languages/ folders."
I was afraid about something like this! ;-) --WikiForMen (talk) 13:42, 26 March 2021 (UTC)
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Noisy during mysqlcheck --auto-repair

We run mysqlcheck --auto-repair before backing up our wiki database. The hit counter is kind of noisy:

[236338]: my_wiki.wikilounge_hitcounter                      To be repaired, cause follows:
[236338]: Server issued note     : The storage engine for the table doesn't table doesn't support check

Its no big deal the hit counter storage does not support report. There's nothing to report in this instance.

Dark and silent cockpits are a good thing. Its from aviation, where pilots want lights off and no buzzers. Lights on and noises means something is going wrong and needs attention.

Perhaps it would be better to stay silent rather than raising an alarm.

Noloader (talk) 01:15, 2 April 2021 (UTC)

"View statistics" in SpecialPages:Statistics

RESOLVED
The topic was finalised.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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. Ulf Dunkel (talk) 11:11, 6 April 2021 (UTC)
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. Ulf Dunkel (talk) 09:27, 8 April 2021 (UTC)
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)
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

by page hitcounter

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This might be a bit off the topics, we'd like to add a page/block on the home page showing all hit counters in the mediawiki, ideal format like this:

pages | hit counts (descending)

xxxx | 999

yyyy | 777

...

..


does this extensions work this way or other ext available in the market. thanks .


media wiki version 1.34.2

php: 7.x Lamjon (talk) 06:57, 9 April 2021 (UTC)

This is part of the extension:
"HitCounters displays … the most viewed pages on a special page called Special:PopularPages." - See description!
For an example see here.--WikiForMen (talk) 09:47, 9 April 2021 (UTC)
thanks Lamjon (talk) 06:28, 22 April 2021 (UTC)
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

hit_counter not update

After installed HitCounters, & run php update.php,

2 tables hit_counter & hit_counter_extension added to db,

but hit_counter does not update, it was empty for half days,


& SpecialPage:popularpages is empty. Any ideas? Lamjon (talk) 06:38, 22 April 2021 (UTC)

  1. May be the counting table is not updated because some kind of page cache is engaged. Please ask your webmaster.
  2. May be, you are runnig an older mediawiki version? The actual and offical HitCounters extension has no backward compatibility. In that case look on this fork. WikiForMen (talk) 17:08, 22 April 2021 (UTC)

Digital format for Views per edit in View statistics not displayed correctly for non-English languages

Tracked with T280906

The digital format for "Views per edit" in "View statistics" not displayed correctly for non-English languages, e.g. in German "Aufrufe pro Bearbeitung" shows "21.28", should be "21,28". [[kgh]] (talk) 07:30, 22 April 2021 (UTC)

Deprecated: Use of SkinTemplateOutputPageBeforeExec hook ... was deprecated in MediaWiki 1.35

Hi Everyone,

We recently updated to Mediawiki 1.36. I'm testing some of our installed skins under it.

Most skins are causing this warning to be printed on the top of each page. But it looks like this may be a HitCounter issue:

Deprecated: Use of SkinTemplateOutputPageBeforeExec hook (used in HitCounters\Hooks::onSkinTemplateOutputPageBeforeExec) was deprecated in MediaWiki 1.35. [Called from MediaWiki\HookContainer\HookContainer::run in /var/www/html/w/includes/HookContainer/HookContainer.php at line 137] in /var/www/html/w/includes/debug/MWDebug.php on line 376

I have no idea why we are running debug code on a production server. I guess that's a separate issue for the Mediawiki folks.

My apologies if this is not a HitCounter issue.

Our mediawiki information can be found here. Noloader (talk) 02:46, 30 May 2021 (UTC)

You may take this: v0.3.2.3 --WikiForMen (talk) 04:39, 31 May 2021 (UTC)
WikiForMen,
I'm still not seeing the changes on the GitHub mirror. da6e220 is an older commit:
Updating extension HitCounters
Entering /var/www/html/w/extensions/HitCounters
REL1_36 branch found
HEAD is now at da6e220 build: Updating browserslist to 4.16.6
Would you happen to know when your changes are going to land in the GitHub mirror?
Thanks again. Noloader (talk) 09:16, 2 June 2021 (UTC)
Thanks WikiForMen.
We use the REL1_36 branch from the HitCounter GitHub. Is the change available in REL1_36?
Thanks in advance. Noloader (talk) 06:37, 31 May 2021 (UTC)
It is REL1_35+! ;-) --WikiForMen (talk) 06:42, 31 May 2021 (UTC)
Thanks WikiForMen,
It looks like there's a Phabricator issue tracking skins and extensions using deprecated interfaces. See https://phabricator.wikimedia.org/T282897.
Thanks again. Noloader (talk) 01:55, 1 June 2021 (UTC)

Main_Page Error: Call to undefined function HitCounters\wfMemcKey()

Hi Everyone,

We run Mediawiki on a Ubuntu 20.04 server. We just upgraded from Mediawiki 1.36 to 1.36.1. Composer updated vendor stuff, and maintenance/update.php completed successfully. HitCounters is using the REL1_36 branch and up to date.

After restarting the Apache webserver we are seeing the following.

Internal error

[YNS8Yk0uwEj5gvQDE6jINAAAABk] /wiki/Main_Page Error: Call to undefined function HitCounters\wfMemcKey()

Backtrace:

from /var/www/html/w/extensions/HitCounters/includes/HitCounters.body.php(37)
#0 /var/www/html/w/extensions/HitCounters/includes/HitCounters.hooks.php(153): HitCounters\HitCounters::getCount()
#1 /var/www/html/w/includes/HookContainer/HookContainer.php(338): HitCounters\Hooks::onSkinTemplateOutputPageBeforeExec()
#2 /var/www/html/w/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook()
#3 /var/www/html/w/includes/HookContainer/HookRunner.php(3612): MediaWiki\HookContainer\HookContainer->run()
#4 /var/www/html/w/includes/skins/SkinTemplate.php(403): MediaWiki\HookContainer\HookRunner->onSkinTemplateOutputPageBeforeExec()
#5 /var/www/html/w/includes/skins/SkinTemplate.php(129): SkinTemplate->prepareQuickTemplate()
#6 /var/www/html/w/includes/skins/SkinTemplate.php(146): SkinTemplate->generateHTML()
#7 /var/www/html/w/includes/OutputPage.php(2634): SkinTemplate->outputPage()
#8 /var/www/html/w/includes/MediaWiki.php(927): OutputPage->output()
#9 /var/www/html/w/includes/MediaWiki.php(940): MediaWiki::{closure}()
#10 /var/www/html/w/includes/MediaWiki.php(546): MediaWiki->main()
#11 /var/www/html/w/index.php(53): MediaWiki->run()
#12 /var/www/html/w/index.php(46): wfIndexMain()
#13 {main}


Noloader (talk) 17:17, 24 June 2021 (UTC)

Seems you have to update your HitCounters extension! ;-) --WikiForMen (talk) 04:46, 25 June 2021 (UTC)
Thanks @WikiForMen. I re-enabled HitCounters today and it worked as expected.
I'm not sure what went sideways after the upgrade.
Sorry about the extra noise.
Noloader (talk) 17:04, 25 June 2021 (UTC)
The function wfMemcKey() is not longer defined in Mediawiki 1.36. That's all. :-) Good luck! --WikiForMen (talk) 19:21, 25 June 2021 (UTC)
Do you happen to know what the replacement is. I have the same issue with Semantic Glossary (master branch) and 1.36.
TIA
[YN8cHpdWKUJoWuUH6sbaowAAAIs] /Equipment:Laser_Pistol Error: Call to undefined function SG\Cache\wfMemcKey()
Backtrace:
from /home/mediawiki/wiki/extensions/SemanticGlossary/src/Cache/GlossaryCache.php(56) #0 /home/mediawiki/wiki/extensions/SemanticGlossary/src/Cache/ElementsCacheBuilder.php(78): SG\Cache\GlossaryCache->getKeyForSubject()
#1 /home/mediawiki/wiki/extensions/SemanticGlossary/src/LingoBackendAdapter.php(59): SG\Cache\ElementsCacheBuilder->getElements()
#2 /home/mediawiki/wiki/extensions/Lingo/src/LingoParser.php(186): SG\LingoBackendAdapter->next()
#3 /home/mediawiki/wiki/extensions/Lingo/src/LingoParser.php(159): Lingo\LingoParser->buildLingo()
#4 /home/mediawiki/wiki/extensions/Lingo/src/LingoParser.php(217): Lingo\LingoParser->getLingoTree()
#5 /home/mediawiki/wiki/extensions/Lingo/src/LingoParser.php(83): Lingo\LingoParser->realParse()
#6 /home/mediawiki/wiki/extensions/Lingo/src/Lingo.php(53): Lingo\LingoParser->parse()
And I love it when I find comments like this in the relevant code :-)
  public function getKeyForSubject( DIWikiPage $subject ) {
     // FIXME Remove wfMemcKey dep.
     return wfMemcKey( 'ext', 'semanticglossary', $subject->getSerialization() );
  }
  /**
   * @since 1.1
   *
   * @return string
   */
  public function getKeyForLingo() {
     // FIXME Remove wfMemcKey dep.
     // This key should come from something like LingoCache::getKey()
     return wfMemcKey( 'ext', 'lingo', 'lingotree' );
  } Bluedreamer1 (talk) 14:05, 2 July 2021 (UTC)
Hi @bluedreamer1,
You might find https://www.mediawiki.org/wiki/Extension:Semantic_Glossary a better place to ask about the extension.
Noloader (talk) 04:48, 3 July 2021 (UTC)
Thanks. I realized this wasn't the general help after I posted, but I more interested in the if there is a one-for-one replacement of wfMemcKey() then I can just fix the code.I guess I could just checkout HitCounters codebase and look at what they. Bluedreamer1 (talk) 13:21, 3 July 2021 (UTC)

Updating Database Not Working

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)... Cozbaldwin (talk) 18:49, 5 February 2022 (UTC)

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! Cozbaldwin (talk) 19:54, 5 February 2022 (UTC)
Thanks for noting that you have to Restart the update script, not mentioned anywhere else. Wikidev23 (talk) 11:50, 6 May 2023 (UTC)

Approved Revs

I have noticed there is not hit count on approved rev pages using the extension approvedrev.


Is there something I can do to display these hits? 2601:446:4400:700:8984:8CF7:5EE8:1F32 (talk) 16:22, 6 March 2022 (UTC)

I was mistaken. The pages are being counted. 2601:446:4400:700:8984:8CF7:5EE8:1F32 (talk) 16:26, 6 March 2022 (UTC)

Ignore bots and crawlers ?

Hello, I've adapted the extension for our project, to ignore bots and crawlers. If this is something that makes sense for the rest of the world, do not hesitate to bring it back to the main branch. It's not based on an option but that's easily doable. https://github.com/neayi/mediawiki-extensions-HitCounters/commit/4978b3673e0a6808f79fc15daaca79bac62b9def BertrandGorge (talk) 09:40, 10 March 2022 (UTC)

Possible Bug

Hitcounter not appending number to the page title. This is what it looks like in the Popular pages list

  1. Main Page‏‎ (⧼hitcounters-pop-page-line⧽)
  2. Page 2 (⧼hitcounters-pop-page-line⧽)
  3. Gachangi (talk) 10:42, 6 April 2022 (UTC)

Caching

This sounds like an excellent extension. Can it coexist without problems with the various types of caching native to MediaWiki and with external caching on the server, for instance Varnish? Henryfunk (talk) 14:54, 22 May 2022 (UTC)

Not Registering Hits Or Showing Page Hit Counts on page

I have MediaWiki version 1.35 installed. I attempted to install HitCounters version 0.3.4. I have followed all the configuration steps I can see in the extension description page, however, for some reason in my environment it does not seem to be working. After doing the update.php I do see that the tables exist in the mariadb database, and the Special:Version table does indicate the extension is installed. I queried both of the database tables and they exist but neither has data. Have visited multiple pages several times but nothing is shown on the pages, the database, or the statistics pages. Wondering if something else is preventing the hits from being registered. I have LDAP authentication stack working and you must be a logged in user to create/edit pages. Hoping someone might have ideas. Thanks for any assistance. Nwroble (talk) 17:28, 16 June 2022 (UTC)

Can you try accessing a page with couple different browsers? After I did that a few times I am now seeing "This page has been accessed 4 times." at bottom of page. 173.30.219.19 (talk) 23:20, 20 June 2022 (UTC)

This MediaWiki-based wiki has been running for some years without issues. I added the HitCounters extension when that was removed from the main software install; again, no issues until recently.

A few days ago I updated the site to version 1.38.1. HitCounters extension is 0.3.4.

in Special Pages -> Popular Pages, all pages show the same (large) hit count as the site's Main Page.

The hit count at the bottom of each page is still correct, and increments when the page is refreshed.

I assume the bug was not there with the previous MediaWiki version 1.37.1, I think I would have noticed. PaulTimperley (talk) 18:16, 22 June 2022 (UTC)

I suspect this has someting to do with the join_conds on getQueryInfo 103.140.78.202 (talk) 10:13, 25 June 2022 (UTC)
I have the same issue. Anyone know of a way to fix this? Saucy (talk) 01:31, 27 July 2022 (UTC)
I have the same issue (mw1.38.1), so I looked at the log file and found the following output:
SELECT p.page_namespace AS `namespace`,p.page_title AS `title`,h.page_counter AS `value`,p.page_len AS `length`  FROM `page` `p`,`hit_counter` `h`    WHERE p.page_is_redirect = 0 AND p.page_namespace IN (0,12,4,3000)   ORDER BY value DESC LIMIT 51
I don't see a JOIN clause for hit_counter and page, is this the expected behavior? Mochome (talk) 02:04, 7 August 2022 (UTC)
I have the same issue for 1.38 217.71.1.56 (talk) 09:26, 20 August 2022 (UTC)
I tried changing includes/HitCounters.body.php line 133 (public static function getQueryInfo) 'page' to 'p' then it seems to work.
132                         'join_conds' => [
133 #                               'page' => [
133                                 'p' => [
134                                         'INNER JOIN',
135                                         'p.page_id = h.page_id'
136                                 ]
137                         ]
Mochome (talk) 10:43, 23 August 2022 (UTC)
Thanks, Mchome. It works for me as well! 5.103.46.6 (talk) 06:09, 4 September 2022 (UTC)
Thanks Mochome, this was also the fix for me! 212.84.154.148 (talk) 10:38, 31 August 2022 (UTC)

Installation with Composer requires Git?

Hi there,

I was trying to install the extension with Composer as suggested and Composer says the following:

In GitDownloader.php line 77:

  git was not found in your PATH, skipping source download Eric L8s (talk) 22:58, 12 February 2023 (UTC)

Special:PopularPages limit

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). John Koughto (talk) 05:57, 11 May 2023 (UTC)

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)

Hit Counts not registering

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? 2600:4041:2028:4500:C0CE:60FC:5078:D26B (talk) 00:52, 31 May 2023 (UTC)

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)

Error: Class 'MWNamespace' not found

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.

Vicarage (talk) 08:24, 29 September 2023 (UTC)

[Bug: T291389] should be fixed since Oct 10, 2021. See:
https://github.com/wikimedia/mediawiki-extensions-HitCounters/commit/d0f37b82b53368fc2bb50c2ff3ce29ba0b3b4cbc WikiForMen (talk) 17:19, 30 September 2023 (UTC)
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 Vicarage (talk) 22:02, 1 October 2023 (UTC)

Code Review

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. * Pppery * it has begun 23:23, 4 October 2023 (UTC)

Upgrade from TopTenPages (1.24)

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? 5.10.10.117 (talk) 17:52, 22 April 2024 (UTC)

Hopefully you have followed these instructions while upgrading:
https://www.mediawiki.org/w/index.php?oldid=6146163#Migration
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.:
https://github.com/WikiMANNia/Mediawiki-Extension-HitCounters/releases/tag/REL1_25-v0.5.0
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. WikiForMen (talk) 19:50, 22 April 2024 (UTC)
Thanks for these very clear instructions! 134.34.7.73 (talk) 07:44, 23 April 2024 (UTC)
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". WikiForMen (talk) 12:49, 23 April 2024 (UTC)

Make special page transcludable

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 S0ring (talk) 11:37, 23 April 2024 (UTC)

Tracking by time period

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. Dimpizzy (talk) 18:26, 20 May 2024 (UTC)

counter increments at each page refresh

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 Thomas-topway-it (talk) 14:01, 1 October 2024 (UTC)

I'm not sure if the MediaWiki structure can distinguish a ‘refresh’ from a regular view. WikiForMen (talk) 15:38, 1 October 2024 (UTC)
shouldn't we use cookies for that ? Thomas-topway-it (talk) 16:23, 1 October 2024 (UTC)
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. WikiForMen (talk) 17:20, 1 October 2024 (UTC)
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. Thomas-topway-it (talk) 19:07, 1 October 2024 (UTC)
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". WikiForMen (talk) 23:36, 1 October 2024 (UTC)
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. Bawolff (talk) 22:40, 1 October 2024 (UTC)
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.?!?? WikiForMen (talk) 23:38, 1 October 2024 (UTC)
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. Thomas-topway-it (talk) 06:58, 2 October 2024 (UTC)
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. WikiForMen (talk) 20:06, 2 October 2024 (UTC)
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 Thomas-topway-it (talk) 19:47, 3 October 2024 (UTC)
Category:Talk pages with syntax highlighting errors