[Policy] Deprecate Statistics module in D10 and move to contrib in D11

Removing a thing from core requires signoff from all the committer roles, as well as an opportunity for the subsystem maintainer to provide feedback if there is one. (There is none here.)

The committer team recently reviewed our scoring exercise on all core modules. There is a reasonably strong consensus that Statistics is neither a foundational capability nor strategically valuable to the product roadmap, so it should be removed. I am marking RTBC, but leaving the tags on to give committers a chance to confirm that they agree.

Myself, @catch, @quietone, and @longwave all agree on moving Statistics to contrib.

From a framework manager point of view, I'm happy for it to be moved to contrib. There are much more sophisticated third-party options for measuring traffic that don't have an impact on the database.

Removing the FM tag as it sounds like there's consensus here.

As a Drupal core product manager agreed with the above. Statistics is not only used on few sites, it does not have a maintainer and does not have an ecosystem either of modules that would need it to be in core. Its simple approach to collecting and maintaining stats makes Drupal looks inferior to what it is. Removing the tag.

Automatically closed - issue fixed for 2 weeks with no activity.

@larowlan please can you elaborate what you mean by this?

There are much more sophisticated third-party options for measuring traffic that don't have an impact on the database.

Personally, I think it is a shame that his feature is being removed from core as it provides a metrics system solution without the use of third party cookies etc.

Not sure what the database overhead is here but I do not think the overhead can be that heavy? Perhaps you can elaborate on that as well?

Seconding 2dareis2do that this is a bad idea.

More so than it originally was, actually:

• this is a module that provides some stats without depending on a large and third-party service, which became more of an issue with the GDPR and the general trend of making it more onerous on site owners to keep external analytics and still being compliant
• it has had extremely little issues over time, so has barely any maintainer load
• the threshold to consider removal is 5% but stats in the associated issue show statistics to be around 8 or 9% depending on the data set, so even this internal rule appears not to be respected
• a better and easy choice would be to make it more useful by counting views on all content entities in default view mode
• for me in particular, I just spent some time in the last few days extending it to get statistics over time from it using a long-running agent (cf. discussion in #contribute)

I think it would make a lot more sense to put some love into such a basic feature than just kill it for no reason and making Drupal core less useful.

Anecdotically, after returning to using this module after a D7->D10 port where I removed GA for GDPR reasons, and added that "stats over time" tracking based on it, I suddenly discovered view counts that were much more useful and made more sense than I ever got from GA, which hides the forest for the trees.

I can even publish that "statistics over time" of that is of interest to anyone. It's just some Go code in an agent, that collects the Drupal node_counter into a target offline DB and includes querying that DB to build graphs over time with github.com/go-echarts/go-echarts/v2

If not having a maintainer is an issue, I can take it now that I no longer have XML-RPC to support, and can even provide a plan for it, with the added data and a variation on longitudinal stats as a new shiny.

Agreed with @fgm.

I'm one of the « less than 5% » who use this module on several websites. Third party solution are IMO ether blocked by ad blockers or too intrusive.

The stats module give me inputs about the most read contents on the website.

In the opposite, I'd love to see improvements, like compiled daily/weekly/monthly/yearly data, maybe a dashboard theses numbers...

It's not incompatible with move stats module to contrib, but keeping it is a good solution to provide user a, simple and basic for sure, but working stat module out of the box.

I agree with keeping Statistics in core, and even expanding it with some more basic features.

Also, the Statistics module doesn't even qualify as being under 5%: With 40516 installations it's installed in 9% of sites, from @effulgentsia's dataset from March 2022 in #3158669-20: By default deprecate non-experimental modules that are used by less 5% of sites before the next major version → .

Based on that fact, this issue should be closed, and a new issue for adding features to this great little module could be created.

Statistics module is unmaintainer as mentioned above.

Statistics
- ?

The last time there was a maintainer (officially) was 2019, although they were inactive before that. And before Tim took over, it was unmaintained for years before that too.

In the opposite, I'd love to see improvements, like compiled daily/weekly/monthly/yearly data, maybe a dashboard theses numbers...

Adding features like this is much easier to do in a contrib module than in core. Once project browser is in core, it will be much easier for people to find and add contributed modules.

it has had extremely little issues over time, so has barely any maintainer load

The number of issues against statistics overall doesn't necessarily indicate that there is no maintainer load. There have been 75 commits to the statistics folder in the past four years, which is 1.3% of commits to the 11.x branch in the same time period. Every time we need to update core for coding standards changes, PHP version compatibility, phpunit updates, other core API changes etc., some percentage of those changes affect statistics module but won't necessarily be recorded as issues with the module. Meanwhile there are 34 open issues, some of them have been open for years without any movement at all.

If not having a maintainer is an issue, I can take it now that I no longer have XML-RPC to support, and can even provide a plan for it, with the added data and a variation on longitudinal stats as a new shiny.

This is good, but why not do that in contrib? What's the most recent statistics core issue that you worked on?

Also, the Statistics module doesn't even qualify as being under 5%: With 40516 installations it's installed in 9% of sites, from @effulgentsia's dataset from March 2022 in #3158669-20: By default deprecate non-experimental modules that are used by less 5% of sites before the next major version.

Based on that fact, this issue should be closed, and a new issue for adding features to this great little module could be created.

That's not how the 5% issue is intended to work, and also that issue is still open, not official policy yet although it's informing some decisions because there is no coherent policy for module inclusion/exclusion still.

If we just added a module, we would not remove it just because it has less than 5% usage - because this takes time to build up.

However, there may well also be good reasons to remove modules with more than 5% usage. For example color module was enabled by default in the standard profile, but then not actually 'in use' on lots of sites - i.e. if people don't use the color feature on themes that support it, or install a different theme that doesn't support color at all, and never realise they could/should uninstall the color module.

You're right @catch, my "close this issue" comment took it a bit too far ... My main point was at correcting the erroneous sentence, and I got carried away:

This module is installed on less than 5% of sites ...

I hear your arguments and have been swayed. Maybe the Statistics module would thrive better in Contrib like you say, to allow speeding up the process, for example of adding new features. Easing the burden of maintenance is another strong argument, allowing the Drupal core maintainers to focus on improving other areas of future Drupal releases.

Aggregator module shows that moving to contrib unlocks improvements

dcam came on as a maintainer and resolved nearly all of the open bugs as well as adding a heap of improvements

The module was languishing in core. In contrib it is thriving

Added existing followup issue. One of those two might be a duplicate of the other one.

Added meta link too.

Adding related issue. Thanks @fgm!

Some ideas for possible enhancements.

https://independentwp.com/features/