Remove Statistics module from D8 core

I'm ambivalent about removing the core Statistics system. It isn't very performant or extensible, but there are several statistics tables in the core Drupal install, so if it were removed there would have to be some kind of migration path.

I don't think that Views can use Statistics very easily, though, which would be an argument for removing from core and urging people to switch to a contrib statistics system that had better integration.

+99999!

Seems like a no-brainer too. This module is totally unmaintained, is a performance hog and doesn't produce anything useful.

From Bojhan: "We have attempted to make this more useful, but it didn't even create useful statistics in 2007. The Dashboard wanted to use this but couldn't because its so useless."

I think this needs more discussion, doesn't feel as simple as profile/blog/trigger to me.

Generic site statistics are definitely better handled by tools like google analytics or awstats. Core should not try to compete with those, contrib has tonnes options of integration with both commercial services and open source stuff you can run yourself.

However, statistics also has a (very basic) view counter for nodes, which allows for things like most popular lists etc.

It's hard to pull that stuff out of analytics/awstats and back into Drupal, and it's a popular need - so I'd like to know what we're removing it from core in favour of.

I have seen projects that did view counting without using core statistics module, but they didn't use contrib modules either, instead did something custom.

If amazing solutions exist in contrib, then that's great, but links please.

I'm not saying we need to support it in core even if they don't, but let's be clear about exactly what features we're dropping. iirc top 404s and 403s are supported by statistics, but they could possibly be supported by dblog instead (i.e. have an aggregate view of watchdog messages ordered by count).

Gotta remove mentions of the Statistics modules elsewhere around Drupal core. Poor Dave Reid.

Also, node_comment_statistics are unique to the Comment module, correct?

What is the migration path? Can we support Statistics in contrib?

@Rob Loach: yes, {node_comment_statistics} has nothing to do with the statistics module.

Do not remove statistics because they are not accurate with Varnish. It'd be better for all of us to fix stats.

I lot of clients uses the node counter. It's a very popular feature.

@timmillwood

Boost module has built-in support for AJAX based page views counter using statistics module, so it should be probably easy to port/re-use.

@timmillwood: Webchick always tells that if only less than 20 % of users uses a feature, we remove it from core. Now you says that if 80% of users uses a feature, we remove it from core.

Or in simple terms, not used that much, remove it. Popular, remove it.

For your information, Views is supposed to come in core. Like CCK did.

I give up on waiting for these SimpleTests to run locally, lol.

@timmillwood: Please read discussion about lean core and specially the sub-thread about Statistics here:

#1255674: [meta] Make core maintainable

:-)

The popularity counts are really useful, but the core module is half baked and doesn't scale (had to use Radioactivity on a large D6 site, which actually works under load)
Remove it and let it be done properly in contrib.

See #21 is the sort of discussion we need.

http://drupal.org/project/radioactivity I have not used, but if that's providing this properly, then I would not object to retiring statistics module.

Please make sure everyone here is reading #1209532: Count node views via AJAX in the statistics module as well.

I'd have no problem with removing this from core. I don't use this for stats, relying instead on Google Analytics. For some people, having a 'local' stats system may be important, but I think we can get this (and better) functionality from contrib.

Just added a comment in #1209532: Count node views via AJAX in the statistics module. Statistics module provides a basic feature for websites, so it should be left in core. It is not difficult to maintain it, neither.

Cross linking: http://drupal.org/node/1209532#comment-4915216. It seems like some people in #1209532 have some interest to work on this....

I am willing to maintain/co-maintain Statistics if it stays in core or if it is moved to contrib.

Radioactivity module is way better and already maintained in contrib. It solves the same use case and many more. +1 to remove Statistics from core.

(Edit: Radioactivity supports AJAX Varnish/Boost loading...)

We need simplification of statistics, not it's removal.

Lets not have two issues about Statistics for D8.

Duplicate of: #1209532: Count node views via AJAX in the statistics module

Um, no. This is not a duplicate. That other issue is proposing improving statistics, this issue is proposing removal.

Statistics is a heap of junk and it does not belong in core. Plus, if it were contrib, it could grow and evolve over time. In core, it's locked down for years at a time.

Plain module removal is postponed for now.

Please do your comments on #1255674: [meta] Make core maintainable is you are still looking for plain removal.

This issue needs to not die in the abyss of postponed/closed/duplicate/whatever issues. It's important.

#1255674: [meta] Make core maintainable is a good discussion around what should/shouldn't be in core, but this is a real, actionable task.

There's a patch with only one failing test in #19, so this is definitely cnw.

Discussion is good, but it needn't hold this issue up. If everyone agrees that statistics != core material, then the patch needs to be finished and committed. If we later decide that some analytics thingy is important for core, we can write a new one (or resurrect parts of statistics - version control is great for that).

Regarding #34, it is fine and good to suggest that the existing statistics module is needed but should be rebuilt from the ground up. If the functionality is needed, recruit others to your view and build a dev replacement version. Then the community can review your prototype vis-a-vis the existing functionality. A consensus then can evolve on which direction to follow and if appropriate, the existing module can be eliminated.

What does not make sense is to rip out what we have now in favor of something to be built. Implicit in the removal of the existing is that the new will be better and will be completed to standards on a timely basis. What happens if either assumption does not occur?

Regarding your proposed new hook_statistics, you suggest that it would be called on each and every page load. To handle caching and anonymous users, my understanding is that you will need to call hook_boot() and/or hook_exit() for each page load. That eliminates aggressive caching and presumably requires at least booting to BOOTSTRAP_DATABASE on each page load for a default local solution.

Finally, you suggest that Views should be integrated for the display of the statistics. As a core module, are you suggesting that there now be a dependency on a module now in contrib? What happens if a site does not want to use Views? They cannot use Statistics either?

Hopefully, the above points help explain why a working prototype is needed before we should adopt #34. I welcome the ideas and suggested improvements. However, there also is a saying that the proof is in the pudding.

Right, there's a difference removing profile module when profile2 already exists in contrib, compared to removing statistics module when it does some things that currently aren't handled much by contrib or not 1-1.

Here's a suggestion of some immediately actionable things we could do to the existing statistics module.

1. Move 'top 404' and 'top 403' reports to a 'top log messages' filterable page in dblog module. This would do GROUP BY dblog.variables and let you see top PHP errors or whatever else too. I have wanted to add top PHP errors to dblog module for a while (currently I query the db directly). We could simultaneously drop that feature from statistics module. dblog already logs this stuff, so it's just a matter of creating one admin page.

2. Have a careful look through statistics module and see if there are any other features (i.e. that directly compete with google analytics) that could simply be removed - not necessarily to contrib, just altogether.

Once that's done, there will not be so much left to refactor, so it may be possible to start on ground up rewrite without having to take it out and put it in again - or at least we'll have a clearer idea what's in there.

catch: we can't really have the top 40x reports rely on dblog module, since that one is deactivated on most larger sites.

Although mongodb_watchdog recently readded top 40x support like dblog, other watchdog modules may not be in a position to do so. core syslog - at this point - doesn't help.

@fgm - most larger sites don't have statistics installed either. There are third party tools for syslog that allow for aggregation and review of those logs so if people are using syslog they can look at using those too. There's no UI for reviewing syslog messages in core at all but that doesn't stop us having the recent log entries table in dblog - I don't think there's a problem adding features to dblog that other logging back ends might not support, as long as we don't add requirements that are hard to apply.

@timmillwood, see #31 - improving != removing.

I think that #1255674: [meta] Make core maintainable is a place to have those kind of discussions at the moment.