Talk:Requests for comment/Removing hit counters from MediaWiki core

People like stats, I don't think it should be removed. I have however, been wanting for some time to add the needed hooks so one can use a different counter implementation. Platonides (talk) 19:46, 27 November 2013 (UTC)
 * I use them on wiki regularly. --Nemo 09:35, 27 November 2013 (UTC)
 * For what? --MZMcBride (talk) 19:00, 2 December 2013 (UTC)
 * To know how many hits a page has. --Nemo 19:34, 2 December 2013 (UTC)
 * I'm frankly disgusted by the outcome of this proposal. No wonder MediaWiki is fatally declining in the web. --Nemo 18:02, 22 October 2014 (UTC)
 * Platonides: I agree that people like stats. However, these stats are inaccurate and have no granularity. Wikis wanting actual stats install Extension:Google Analytics or similar. I'm not sure why core needs its own hit counters when the cost is so much higher than the benefit. We know that all Wikimedia wikis do not and cannot use built-in hit counters. Which wikis are effectively using them?
 * My organisation's wiki was effectively using them, for hit-by-hit monitoring of visitor activity across sets of related pages. We only get a few thousand visitors per month, and for us, the stats appeared to be 100% accurate and very useful. We also use GoogleAnalytics, but the two sets of stats present differently, and have different uses. GA is great for showing trends and current activity to the back-office, but the onboard stats show long-term popularity, page by page, to visitors and editors as they browse. ErkDemon (talk) 18:28, 6 June 2015 (UTC)
 * ErkDemon: How was your organization able to measure the number of hits per day or per month or per year? Did you do your own record-keeping? --MZMcBride (talk) 00:14, 26 June 2015 (UTC)
 * Regarding hooks and such, I believe most engineers in this field have decided that using client-side JavaScript is the best way to gather analytics. ResourceLoader and site-wide JavaScript pages (such as MediaWiki:Common.js) already cover most of what you'd need, right? --MZMcBride (talk) 19:00, 2 December 2013 (UTC)

The stats are good for smaller wikis that don't have any other stats solution. They have to be in place from the time of installation if they're going to be accurate. They can be switched off later if the system administrator doesn't want them.

In what way are they too inflexible? Don't config settings like Manual:$wgHitcounterUpdateFreq give us some flexibility? I am curious, though — how much of a performance hit do wikis take when they use hitcounters? Leucosticte (talk) 07:06, 28 November 2013 (UTC)
 * The current implementation is a single integer field in the page table. There's no granularity: there's no additional information stored about unique v. non-unique visitors, browser user agents, geolocation data, etc.
 * As for performance, if hit counters are enabled (as they are by default) and there's no front-end caching, you're writing to the database on every page view. For small sites, this is negligible for performance. For larger sites, it can be a major performance bottleneck. No large wiki would ever keep this setting enabled, which is why guides such as User:Aaron Schulz/How to make MediaWiki fast and Five minutes of MediaWiki performance tuning recommend disabling counters. Even on sites that keep counters enabled, I fail to see the value if the stats are simply wrong. --MZMcBride (talk) 19:00, 2 December 2013 (UTC)
 * Wikia has globally turned off all this code as well due to performance reasons. It doesn't scale for wikis with any kind of traffic (thousands of hits per day is probably okay, but not millions).  site_stats has a similar lack of time granularity and we disabled ss_total_views because its also a useless metric which causes performance problems but most of the other fields there are reasonable.  I can see the argument for having a simple stats mechanism, but I personally feel like that should be an extension, not a part of core.  Owyn (talk) 22:04, 2 December 2013 (UTC)
 * Okay ... but if the feature's being downgraded from a core feature to an extension, you write the replacement extension before removing the core feature. Otherwise you're making the situation worse. Just because the guys running high-traffic sites can't use the onboard stats and aren't interested in them, it doesn't mean that the feature should be taken away from everyone else. ErkDemon (talk) 18:28, 6 June 2015 (UTC)


 * Some #wikimedia-dev discussion


 * I'm sure there are people who find this basic counter enough for their needs. There is no need to erase this from existence, core should provide proper hooks anyway, and then we can move this to an extension. Krinkle (talk) 01:13, 8 February 2014 (UTC)
 * There should be more than enough hook points to handle this. Off the top of my head you could grab one of the viewing-related hooks to do the hitcounter++ increment. If an extension wants to implement rudimentary hitcounting then they're more than welcome to. ^demon[omg plz] 19:07, 18 August 2014 (UTC)

Hit statistics requirements
I have been playing with Piwik for a while for traffic analysis and other statistics. As google analytics, though, Piwik is way more than a hit counter. And, the more powerful an analytics system is, the more does one want to know :) So, one issue I came across several times is the question, what information do I need in order to get good statistics. Only once we do know the requirements, we can talk about whether we need a hook or any other mechanism to get this info to the analytics software. Here's some suggestions: All of these are readily available client side. In my own example, I also had the need to track only pages that contained a certain tag. A standard way of hooking in this information might be a good idea! --Mglaser (talk) 14:28, 31 December 2013 (UTC)
 * Article title
 * Namespace
 * Category
 * User (?)
 * Indeed, Piwik is no replacement of the hit counter; it's something totally different. Hit counters are all most users need (as demonstrated by the popularity of http://stats.grok.se ). --Nemo 07:38, 9 August 2014 (UTC)

Alternatives?
I can't see why the page_counter was deleted when there was no viable alternatives for small wikis to display hit counters. We're talking about wikis that only get a handful of visits each month, so that the counter (which I assume was derived from blogosphere hit counter) is vital to the website to gauge a page's popularity (is it popular? make more of them; is it never get visited? do something about it). Instead of removing it, why not fixing it, for example, add two kinds of counter: lifetime, and monthly (reset to 0 every month), and still many other better ideas than just dump it with no alternatives (Extension:Google Analytics was marked unstable, by the way). Bennylin (talk) 10:06, 29 May 2015 (UTC)
 * Well, it seems that nowadays, if a feature isn't useful to the Big Users and commercial wiki farms like Wales' wikia.com, it now gets not just disabled by default but deleted from the software. Sure, those guys pay the bills, but actually deleting functions that those guys happen not to use seems to be going a little bit too far. Surely there was an intermediate option between the feature being "on-by-default" until disabled, and the "nuclear option" of deleting the code altogether? ErkDemon (talk) 18:28, 6 June 2015 (UTC)