I've noticed that the number of reported installs is usually (not always) somewhat larger than the number of downloads. I figured maybe this is because of multi-site installations in which one download runs on several sites. On the other had, there have to be cases where a module is downloaded and not implemented in production, which perhaps would account for cases where there are more downloads than installs.

But I just noticed that "CKEditor Link" has over 50,000 reported installs and only 658 downloads. That doesn't make any sense. Does anyone know what's going on there?

These statistics are relevant to the decision of which modules and themes to use in a system. (Edit: They are relevant for me because I can't afford to be in a situation where my sites go down because a Drupal revision breaks a module and the module maintainers don't get it fixed pronto. This is much less likely to happen with an installed base of 50,000 than 500.)

  • statistics shouldn't be the deciding factor on modules, the applicability of that particular module to your needs should be - even similar modules differ in many respects, meaning one is likely to be more useful than another, regardless of how many people have used it – Geoff May 2 '15 at 22:16
  • @Geoff, NewSites said "statistics are relevant" to a module/theme decision. This is true. It shouldn't be the only factor, but it should be a factor. – Shawn Conn May 3 '15 at 6:31
  • well, in my opinion that's poor thinking by a narrow minded author. If a module is specific, and only applies in very limited situations, it will have low statistics, naturally - but that doesn't mean it's a poor module or not useful, only that it is more specialised than something like Rules or Views – Geoff May 3 '15 at 6:38
  • @Geoff - See the edit of my question to explain the relevance in my situation. – NewSites May 3 '15 at 10:25
  • that's faulty logic, but this discussion doesn't belong here anyways... – Geoff May 3 '15 at 13:15

EDIT: The problem is with a bug in the statistic module. Some information about sampling methods follows.

The number installs comes from the Project module used on drupal.org. On the project usage page, it links off to documentation about usage statistics which states:

As always with statistics of this sort, they don't tell the whole story. For example, the results shown for "Drupal" are a poor estimate of the number of Drupal sites on the internet. This is because only sites running the Update Status module report data back to drupal.org.

Downloads are likely to have heavier bias, compared to installations, due to a number of factors limiting installation reporting (e.g. modules never installed, modules uninstalled, sites without Update Status running, etc.)

  • I'm wondering... Why you said core's statistics module is inaccurate. I don't use it any of my sites, but I'm pretty sure it uses a silent Ajax call after the page load to increment the counter. A cache won't have effect on this (front end cache, Memcache or Opcode caches). – AyeshK May 4 '15 at 21:38
  • I made a clarifying edit regarding 2 different sampling methods. Maybe core statistics is better in D7? In various D6 sites, I've had it report wildly different results (compared to other data statistics) when Boost caching was enabled. – Shawn Conn May 5 '15 at 1:29
  • While accepted, this answer is wrong. This has only been happening since mid-april 2015 - and its cause is a bug. – Free Radical May 5 '15 at 1:41
  • The statement: "the sampling is heavier in favor of install reporting vs. download reporting" is still wrong. (It is actually the other way around. When it is working, the download counter counts every single download, while the install counter only counts sites that is running "Update Status".). – Free Radical May 5 '15 at 2:46
  • Missed that block of text on removal. Fixed the conclusion based on that info. Thx. – Shawn Conn May 5 '15 at 3:08

This is simply due to a bug with the statistics module - see Project Download count Decreased - that has affected Drupal.org infrastructure since the middle of April 2015.

Prior to that bug surfacing, I did not observe a single project where the number of downloads were less than the number of installs.

Just now CKeditor Link is reported to have 487 downloads. That is 171 less than the 658 reported by the OP in the question (asked two days ago).

Until this bug is fixed, the download statistics should just be regarded as a random number.

As reported by Pierre.Vriens, another bug sometimes affect the installed statistic on the Drupal.org. This affected many projects a couple of days ago, but seems to have been fixed for most of them today.


Something seems really wrong these days with these statistics, and this for any of the modules I've been checking lately. As a (random) sample, consider the Charts module: similar issue. But there is more: look at the "Usage Statistics" page of the Charts module (or just any module): the typical numbers there get updated somewhere on Sundays. While these updates are happening (on Sundays), the date (line) is already added, but with a counter 0. However this week (since last Sunday), it has always been 0.

Anyway, about your last phrase: be careful in "only" using these stats. Instead you may want to consider many more (like 23?) criteria to help you make decissions. As I documented in (what I call) maintenance scorecards. In this case they relate to charting modules (that's where my interest in Drupal mostly is). But you can apply them for any set of modules of course.

Note: I'd be interested in other criteria to be considered to evaluate modules. Feel free to "edit" that community page (or add comments to it) for any such criteria to be added to it.


I am also facing the same issue, The Reported installs count is not updating for https://www.drupal.org/project/domain_googlenews_sitemap. Can anyone please help in finding a solution to this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.