Top Drupal 7 and Drupal 8 core sub-modules

Usage of experimental modules in Drupal 8:

1. BigPipe: 5070
2. Inline Form Errors: 3104
3. Place Blocks: 2384
4. Settings Tray/Outside In: 1676
5. DateTime Range: 3994
6. Content Moderation: 2465

Migrate: not something you should have on a production site…

So, BigPipe was by far the most popular experimental module. Sounds like we indeed get sufficient validation to do #2797169: Mark BigPipe as stable/non-experimental :)

Also, great to see that almost no sites disabled Dynamic Page Cache! 135475 using it, 138764 using Page Cache (so 97.6% of sites using Page Cache also use Dynamic Page Cache).

Note that only 72735 of the total of 153104 measured sites use Standard — or 47.5%. Minimal is on 1464 — or 0.9%. That means over 50% is using a contrib/custom install profile!

Also, in https://www.drupaleasy.com/podcast/2017/03/drupaleasy-podcast-192-8-reas... it was theorized that Quick Edit may be disabled on lots of sites, like Overlay was disabled on lots of D7 sites. Well, Quick Edit is installed on 103824 sites, or 68%. That's higher than the percentage for the Standard install profile, so lots of custom install profiles also install it.

Contrast this with Overlay in D7: 472308 out of 932752, or 51%.

Finally, as one of the people leading the API-first initiative: rest is used on 18878 or 12.33% of D8 sites. serialization is on 21724 or 14.18% and hal on 11541 or 7.54%.

That suggests:

• that about 1 in 10 D8 sites are partially or fully decoupled
• that HAL+JSON — despite being the default — is not at all a popular format (which confirms my real-world conversations and suspicions)
• that quite a few sites are using the Serialization module without the REST module, which means they must be using contrib modules like https://www.drupal.org/project/jsonapi to use it (although that module only has ~900 sites using it at this time, so that doesn't explain the big discrepancy)

Finally, basic_auth is used on 7962 or 5.2% of D8 sites. That means 7962/18878=42% of sites using REST use Basic Auth for authentication REST requests. The remainder must be using cookie/anonymous authentication, or contrib auth modules like https://www.drupal.org/project/simple_oauth (~200 sites) or https://www.drupal.org/project/usage/jwt (~200 sites). Likely most of them are using cookie authentication, which strongly suggests they're progressively decoupled… (which would then be ~5% of D8 sites).

Also, there's one very very very odd thing about these numbers:

system	153104
file	153103
user	153103
update	153094
page_cache	138764

(Note that system and user are the only required modules.)

Those are the five highest usage numbers:

1. somehow there is one site that has only the system module?
2. somehow there are 9 sites that have only the system, user and file modules?
3. somehow the next most popular module after system/file/user/update is … page_cache? That's a difference of 14430 sites with the total number of sites. So that's 14430 sites without even the node or block modules?
4. In fact… node is waaaaay down: it has 118608 sites using it. That's 34496 sites (or 22.5%) not using the cornerstone of Drupal?

Either Drupal is being used in ways I did not expect, or some data is getting lost? (Through URL/log truncating perhaps?)

I am also wondering if the low experimental numbers is due to us not really pushing it at all.

@mixologic Might be able to share some information on the validity, although 34k doesn't really feel like a margin of error :)

@WimLeers I have a few sites not using node - Drupal 8 forms a great basis for applications - fieldable entities, REST et al! Also means that at least some of the 1 in 10 may not really be decoupled but actually API only systems...

#8: @tstoeckler said something similar on Twitter. That's very interesting, thanks for sharing!

@Wim Leers: I would not get hung up on minor differences in numbers of system module vs. required modules, this is the result of a random query on a possibly moving database :)

@Bojhan: re the experimental modules, I think release managers would say the numbers are too high for them ;) they should not be used on production sites

Yeah, dont look for exact precision in these numbers. All kinds of things affect them that is hard to account for, especially since what we're deriving these from is the apache logs from the update status calling back to d.o. to ask for updates. This includes all kinds of CI systems etc. In fact, I would hazard a guess that the 14430 'sites' calling back to d.o. asking for a particular module all happen to be drupalci tests that exercise the updates module tests.

What context exactly is this data trying to inform? Some modules are installed by default on most sites, but that doesn't indicate usage or interest. rdf, shortcut, color, comment, contact. Stark is also easily turned on and then forgotten about. I don't think a lot of people go through the effort of uninstalling a theme.

Telephone, and responsive image are interesting, because those aren't installed by default. (I don't know why telephone isn't installed by default. It is the only field type that isn't.) Those and the multilingual stuff seem to be the highest ranked of the optional components.

In fact, I would hazard a guess that the 14430 'sites' calling back to d.o. asking for a particular module all happen to be drupalci tests that exercise the updates module tests.

Are you saying that Drupal core's test runner can inflate our usage statistics?! :O In other words: the more core patches are tested, the higher this inflation?

This is really interesting.

I would like to know about those four D7 sites not using the system module.

As per @webchick tweet, would also like a similar report for D8 contrib projects https://twitter.com/webchick/status/826915132622069760 ?

Thanks to all you for your inputs, based on which I created an Infographic - Please review https://magic.piktochart.com/output/21724980-drupal8coresubmoduleusage

18:06:25 <WimLeers> Mixologic: So, I wanted to get further clarification on https://www.drupal.org/node/2867597#comment-12029012. I asked https://www.drupal.org/node/2867597#comment-12029149. I think we really need an answer to that. How reliable are those numbers then? And how reliable are the numbers at https://www.drupal.org/project/usage/drupal?
18:06:27 <drupalbot> https://www.drupal.org/node/2867597 => Top Drupal 7 and Drupal 8 core sub-modules #2867597: Top Drupal 7 and Drupal 8 core sub-modules => 16 comments, 5 IRC mentions
18:06:27 <drupalbot> https://www.drupal.org/node/2867597 => Top Drupal 7 and Drupal 8 core sub-modules #2867597: Top Drupal 7 and Drupal 8 core sub-modules => 16 comments, 6 IRC mentions
18:07:54 <Mixologic> WimLeers the numbers are only a representation of the sites that actually phone home using the updates module. Many production sites turn that off, and many sites may be phoning home from CI systems, dev systems etc. Ergo, the *trendlines* have value. The concrete numbers, not so much, unless comparing large orders of magnitude.
18:08:29 <Mixologic> WimLeers Im working on gathering up that data into a real database so we can do things like "ignore sitekey's that we have only ever seen one time"

I think we best ignore the numbers in this issue for now.

So I think we can be sure our core automated tests are not reporting back since that would be sad if we would have such an external dependency in our automated tests. But that does not rule out CI systems other than drupal.org to report back to drupal.org, that is true. It would generally be useful to weed those out from usage numbers IMHO even if that will show us lower usage numbers, they would be more reliably real.

#1627676: Display stats on enabled components (e.g. modules included in a project)