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
Topic on 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