Drupal 8 was released almost two years ago, and it embodied a reexamination of the CMS. With that shift came the introduction of experimental modules. The purpose of experimental modules is to let contributors test new features in Drupal 8 core and receive feedback in minor releases without having to conform to the typical production requirements. Though the modules, as the name implies, are experimental, they do have to meet some minimum requirements and are processed through separate stability levels from core, which are outlined below. Experimental modules are included in the Core (Experimental) package on the Extend page of a Drupal site and they are not fully supported.


Experimental modules are a good option to test new features in a quicker and less cumbersome manner but if not used correctly, you could end up wasting time. Choose to use experimental modules in instances where your feature will require multiple issues to get to stable functionality or if getting there would be disruptive. Another tip is to open an Idea issue and get feedback from product and framework managers to see how initiatives are chosen and approved.


Drupal.org has outlined the four stability levels for experimental modules that are outside of the Drupal core release that contains them.

·    Alpha – Alpha experimental modules are still under development, but available for initial testing. They may include bugs, including security or data integrity issues.

·    Beta – Beta experimental modules are considered API- and feature-complete for the minimum viable product. Some early adopters may begin using beta experimental modules on development sites, but should be aware that they are not yet fully supported and may contain bugs.

·    Release candidate (RC) experimental modules are essentially stable and may be release-ready, although some changes might be made to address critical bugs.

·    Once an experimental module is judged stable, the module will be moved out of the Core (Experimental) package and its version number and allowed changes will be the same as Drupal 8′s core. Experimental modules may only become stable modules in minor or major releases.


There are a variety of experimental modules currently in core at various stability levels:

Migrate Suite/Stability

Migrate – Beta

Migrate Drupal – Alpha

Migrate UI – Alpha

Workflow Suite

Workflows – Stable for V. 8.4.0

Content Moderation – Beta

Layout Suite

Layout Discovery – Stable for V. 8.4.0

Field Layout – Alpha

Media Suite

Media – Stable for V. 8.4.0 (Hidden, pending better UX)

Other Features

Inline Form Errors – Stable for V. 8.4.0

Place Blocks – Alpha

Settings Tray – Beta

DateTime Range – Stable for V. 8.4.0


Experimental modules can have some outstanding issues however, they must meet the minimal requirements as outlined below on Drupal.org:

·       No known security or data integrity issues.

·       No disruption or regression to stable functionality (including being able to remove the experimental module without lasting disruption).

·       Functional test coverage for the primary usecase, with no test failures in HEAD.

·       Basic API documentation for the minimum requirements, an initial change record draft for the addition of the module, and a plan for completing more comprehensive documentation in the codebase and handbook.

·       Ideas/prototypes for user interfaces that are planned and minimally validated.

·       Wherever possible, extension names, namespaces, plugin IDs, etc. should be valid and match the intended final names, to avoid unnecessary upgrade path issues. (This includes whether it makes sense for the functionality to exist in a separate module at all.)

·       Resolution of other critical issues that maintainers identify as hard blockers.

·       A separate module roadmap (“plan” issue) documenting follow-up steps for outstanding work, including:

·    Follow-ups to meet the core gates.

·    Follow-ups to address concerns with the experimental UI and architecture, and iterate on them as needed.

·    Any other issues identified during planning and review.

·       A timeframe for completing the remaining work (typically two minor releases), a plan for addressing follow-ups, and roughly which follow-ups must be completed to keep the module in core. Follow-ups should be grouped according to whether they must, should, or could be a part of the module’s initial stable release.

There it is: An overview of experimental modules. Given that your features fit the profile and that you prepare and then play by the rules, this can be a bonus for Drupal 8 developers and for the CMS itself. To stay up-to-date on experimental modules, visit drupal.org.

Source: Drupal.org, Updated September 18, 2017

A global team of digerati with offices in Washington, D.C. and Southern California, we provide digital strategy, digital marketing, web design, and creative for brands you know and nonprofits you love.
Stay up to date with our insights by following us on Twitter, Facebook, and LinkedIn.