Quote from Experimental modules in Drupal 8:

Drupal 8 core introduces the concept of experimental modules. These are modules that are provided with Drupal core for testing purposes, but that are not yet fully supported. Experimental modules are included in the Core (Experimental) package on the Extend page of a Drupal site (/admin/modules).

I do understand what "testing purposes" means, and I'm aware of best practices like having a Dev / Staging / QA / Prod configuration.

But when using Drupal 8 in a Prod environment, I'm looking for a way to ensure to a site owner something like "You can be 100% that there is no way that any of these experimental modules can ever be enabled in the prod version of your site.". Imagine it's about a business critical Drupal site where "testing in production" is not ever allowed.

So what options do I have in Drupal, apart from hacking core (which is not an option), to be 100% sure of this? And so that:

  • It applies for "everybody" (any user), so even user/1 should not be able to do so if (s)he'd be tempted to do so.
  • It doesn't matter if you're using the Admin UI, Drush, Console or anything similar


There are some D8 core issues about these experimental modules, which IMO are either related, or contains some inspiring comments for finding a possible solution (work around?):

  • Just thinking loud ... how about (option 1) some highly secured GIT construction combined with some relevant 'GIT ignore' files or (option 2) something with file permission to restrict access to the crucial parts of those experimental modules (eg: all relevant *.info files) so that Drupal can't find the modules and hence are not even available for being enabled? Haven't tried it yet, but I wonder how Drupal core would react to such attempt to confuse Drupal ... Commented Feb 22, 2017 at 10:23
  • (option 3) start a petition to have them removed. Perhaps, they should only be kept in the dev versions of core and not on full releases. Based on the official Experimental Docs it makes no sense to me to have them in full releases.
    – No Sssweat
    Commented Feb 22, 2017 at 12:13
  • It's the only way to get feedback on them and evolve Drupal faster. Otherwise, modules like BigPipe and Content Moderation won't get the mainstream feedback core developers are looking for in effort to improve Drupal itself to be better than it's peers. Ones that don't make the cut are removed from later releases, ones that do are promoted to core status after being stablized and approved.
    – Kevin
    Commented Feb 22, 2017 at 12:29
  • Hey @NoSssweat your option 3 somehow goes in the direction of some of the issues I (concurrently) added as an update to my question. Also merci for undeleting your previously deleted answer. Suggestion: how about you "un-strike" your option 1 and 2 again, and rework your answer in something like here are various options which all won't work (= your "Option 1", "Option 2", and with relevant comments below your answer included as quotes). And maybe then add your "option 3"? Commented Feb 22, 2017 at 12:29
  • 1
    @Kevin : I do understand your "only way" viewpoint. But for anybody who has some experience with business critical systems, it should be clear that you just D.O. N.O.T. test (= do experiments) in production. How would you feel if such system would be part of a plane, in which there is a risk that "somebody" would want to start such experiment ... while "you" were flying with it? Variation: there are systems for which it costs over 1,000,000 USD (or EUR?) if they are only 1 second not available ... Commented Feb 22, 2017 at 12:39

3 Answers 3


This is by far not as black and white as you make it in regards to experimental modules.

First, on a mission critical production site, you don't want to do anything directly on production. Completely irrelevant then if it's an experimental module or not. Any configuration change or module should be tested first. There are modules to enforce a read only configuration system for example, that's one way to approach that. One example is Configuration Read-only mode, note that I have no personal experience with it.

Second, there are experimental modules and there are experimental modules. The first experimental module apart from migrate, wich is a special case anyway, was big_pipe. Which is now officially stable in 8.3. It is a module that has zero data, zero API, zero configuration, zero UI. You just enabled it and it does its thing. As such, it was perfectly fine to use it on production already and people have been doing that, myself included. After testing it first, like any other module/functionality. If you found a bug, you could disable it from one minute to the other, without loosing any data or critical functionality.

On the other side of that spectrum is content_moderation and anything around that. Once you start using it, it is a critical and central part of your content creation workflow, and getting rid of it again is much harder. We specifically made it so you could uninstall it, and your content that was published was still published and same for unpublished. But your workflows and metadata around that would be gone. Also upgrading is likely going to be tough from 8.2 to 8.3. That's also why we're working hard to get media_entity into core as a non-experimental module, so people have a stable API and data storage that they can rely on.

Third, the concept of experimental modules is pretty new and there's a bunch of modules in core that we would have made experimental if we could have back when they were added. rest.module and the related modules is one example there.

And last, lots of contrib modules are at least as experimental as experimental core modules, they just don't warn you about that in such an obvious way. Especially development/pre-beta versions. They just don't warn you about themself in such an obvious way.

To summarize, as with many other things, you need to do your research about an experimental module before using it, and for example check if it's big_pipe-like or content_moderation-like. And then decide what that means for your site.

  • Merci for this interesting answer (also)! Everything you wrote about is great stuff, exciting, etc. The phrase "There are modules to enforce a read only configuration system for example" is IMO the part that would probably give me the 100% assurance of what my question is about. Not to hijack your answer, but do you have specific module name(s) that you're aware of? PS: I'm not allowed to post a followup question like "which module can help me to enforce a read only config" (off topic ...). Commented Feb 22, 2017 at 20:37
  • @Pierre.Vriens "How can I have read-only configuration in production?" would be a great question, as long as it isn't an explicit module reco. I don't recall seeing anything similar here, and I think it would be a good long term question for the site.
    – mpdonadio
    Commented Feb 22, 2017 at 21:41
  • I added a link to the one module that I know of in the answer
    – Berdir
    Commented Feb 22, 2017 at 21:43
  • 1
    Thanks for not using my module as the "other end of the spectrum" :) Also worth noting that a contrib author can tag anything as "stable", even if it isn't or they make BC-breaks.
    – mpdonadio
    Commented Feb 22, 2017 at 21:43

I am not 100% sure about this, but I think the only bulletproof way is to

  • Extend ModuleHandler or implement your own ModuleHandlerInterface class, and exclude experimental modules from the methods. Then replace the @module_hander in the service container.
  • Extend ModuleInstaller or implement your own ModuleInstallerInterface class, and exclude experimental modules from the methods. Then replace the @module_installer in the service container.
  • Implement a hook_system_info() to remove experimental modules from the discovery list.
  • @Pierre.Vriens ModuleHandler is beast of a class that is used in a lot of places. Install/uninstall is primarily done in ModulesListForm ; you can look at that for uses, but also note that it directly uses ModuleInstaller. drupal.org/docs/8/api/services-and-dependency-injection/… has info on swapping out services. IEF, the Language Service, and one or two other core services use this.
    – mpdonadio
    Commented Feb 22, 2017 at 18:42

Wanted to delete this, but going to leave this undeleted for the comments sake.

Option 1)

Don't give client the Administer modules permission and don't give them user 1.

Option 2)

Custom module with hook_form_alter that loads the CSS or JS file which hides those rows.


jQuery to hide the table row that belongs to a experimental module.

(function ($) {

    $('tr').each(function() {

       var module_attr = $(this).attr('data-drupal-selector');

       if (module_attr == 'edit-modules-content-moderation' || 'edit-modules-datetime-range' || ...) {




Or you can hide them all with



CSS #edit-modules-core-experimental { display: none; }

Also add a validate function in case the client strips the CSS/JS or checkmarks the value via inspect element.

  • Thanks for trying, but ... Option 1 is not an option I think (user/1 can get around it). Option 2 I need to think about it ... But what about using possible work arounds like drush, etc to enable such modules then? PS: you have like at least an hour to "think" ... (Be back) Commented Feb 22, 2017 at 9:12
  • what about using possible work arounds like drush, etc to enable such modules then? so this is a smart client then :p. Regarding option 1, you don't give them user 1.
    – No Sssweat
    Commented Feb 22, 2017 at 9:17
  • @Pierre.Vriens regarding Drush, take a look at this answer assuming it works, then your next question is what about Drupal Console? How do you guard against being enabled by editing the mysql table? I guess the answer is, you cannot guarantee 100%.
    – No Sssweat
    Commented Feb 22, 2017 at 9:36
  • 1
    Option 2 is just bad advice I'm sorry to say. Hiding the elements will do nothing to prevent the user from editing the values and submitting the form.
    – Clive
    Commented Feb 22, 2017 at 10:03
  • 1
    @Pierre.Vriens This is English speaking site, you shouldn't be surprised to see English words here. There's no point burying your head in the sand, if something is bad, call it bad. Then less people will suffer because of it.
    – Clive
    Commented Feb 22, 2017 at 10:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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