Last updated 23 August 2017.

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).

Experimental module group on the module page.

# What is the purpose of experimental modules?

Since the release of Drupal 8 in November 2015, Drupal core has scheduled minor releases every six months. Experimental modules allow core contributors to iterate quickly on functionality that may be supported in an upcoming minor release and receive feedback, without needing to conform to the rigorous requirements for production versions of Drupal core.

Like other features, new experimental modules can only be added in minor releases, but unlike other features, they may change between patch releases while they are still experimental, including API changes. (See the Drupal 8 allowed changes policy for background on what changes are acceptable for patch and minor releases generally.) The section on experimental module versions below describes how they may change in more detail.

# Who should use experimental modules?

Experimental modules allow site builders and contributed project authors to test out functionality that might eventually be included as a stable part of Drupal core. Use them at your own risk. See the experimental module version information below to help you evaluate whether you should test the module. Also keep in mind that the experimental module might be removed from Drupal core if it turns out to not be a good fit.

# Experimental module versions

Experimental modules have separate stability from the Drupal core release that contains them. The current experimental modules in core are:

Module Stability Deadline
Migrate suite
Migrate beta N/A
Migrate Drupal alpha N/A
Migrate Drupal UI alpha N/A
Workflow suite
Workflows beta 8.4.0-alpha1
Content Moderation beta 8.4.0-alpha1
Layout suite
Layout Discovery Stable for Drupal 8.4.0! 8.5.0-alpha1
Field Layout alpha 8.5.0-alpha1
Media suite
Media Stable API for 8.4.0!
(Hidden pending better UX)
Other features
Inline Form Errors Stable for Drupal 8.4.0! 8.4.0-alpha1
Place Blocks alpha + hidden; to be incorporated as a core patch to Block module in 8.5+ 8.4.0-alpha1
Settings Tray alpha 8.4.0-alpha1
DateTime Range Stable for Drupal 8.4.0! 8.4.0-alpha1

Experimental modules that do not meet their followup requirements by the listed deadline may be removed from core at committer discretion. See the release cycle overview for current release cycle dates.

Definitions for the different stability levels of experimental modules:

# Alpha (e.g. 8.y.x-alpha)
  • Alpha experimental modules are still under development, but available for initial testing. They may include bugs, including security or data integrity issues.
  • Alpha modules are not subject to the restrictions on allowed changes and may have backwards compatibility (BC) breaks even between patch releases. Developers should not rely on their APIs.
  • No upgrade path is provided from alpha versions. To resolve issues for the module, uninstall and reinstall it (backing up any data).
# Beta (e.g. 8.y.x-beta)
  • Beta experimental modules are considered API- and feature-complete. 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.
  • Developers can begin using beta modules' APIs, but should be aware that some things may still change to address bugs. Beta modules are subject to the beta allowed changes policy.
  • An upgrade path may be provided from beta versions, but be aware it may contain critical bugs.
# Release candidate (e.g. 8.y.x-rc)
  • Release candidate (RC) experimental modules are essentially stable and may be release-ready, although some changes might be made to address critical bugs.
  • RC modules are subject to the RC allowed changes policy.
  • Upgrade paths are provided from release candidate versions.
# Stable core modules
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 core's. Experimental modules may only become stable modules in minor or major releases. Not all experimental modules will necessarily become stable core modules.

# When should I propose an experimental module?

If your proposed feature will require multiple issues to meet the quality requirements for stable functionality, or if implementing the feature against stable functionality would be disruptive, consider creating it as an experimental module. Start with opening an Idea issue and get feedback from product and framework managers before starting to write code to avoid wasting time. See How are initiatives chosen and approved. While your module proposal may not be an initiative in itself, a new module is substantial enough that you don't want to spend time building it as a core patch without first figuring out if it has a chance of getting accepted.

Once the ideas process is completed, experimental modules are proposed as core issue patches, like any other feature request.

# What requirements must an experimental module meet?

Experimental modules are not subject to the same rigorous quality standards as stable Drupal core modules and do not yet need to meet all the Drupal core gates. They can be added with known architectural issues, imperfect coding standards (so long as they do not fail automated checks), minimal UIs, outstanding issues, etc. However, to add an experimental module, there are minimum initial requirements and followup requirements:

  1. No known security or data integrity issues.
  2. No disruption or regression to stable functionality (including being able to remove the experimental module without lasting disruption).
  3. Functional test coverage for the primary usecase, with no test failures in HEAD.
  4. 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.
  5. Ideas/prototypes for user interfaces that are planned and minimally validated.
  6. 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.)
  7. Resolution of other critical issues that maintainers identify as hard blockers.
  8. A separate module roadmap ("plan" issue) documenting followup steps for outstanding work, including:
    • Followups to meet the core gates.
    • Followups to address concerns with the experimental UI and architecture, and iterate on them as needed.
    • Any other issues identified during planning and review.
  9. A timeframe for completing the remaining work (typically two minor releases), a plan for addressing followups, and roughly which followups must be completed to keep the module in core. Followups should be grouped according to whether they must, should, or could be a part of the module's initial stable release.

    For must- or should-have followups that require numerous screenshots, detailed code snippets, or in-code @todos, or for those that need to be completed soon, an explicit issue should already be filed and referenced. In other cases, a bullet should be added to the roadmap issue's summary, for example:

    Must have

    • [#NNNNNNN]
    • Usability review of UI texts

    Should have

    • [#NNNNNNN]
    • Theme system maintainer review for theme implementations

When reviewing proposed experimental modules, consider whether your feedback is part of these minimal requirements, or whether it should instead be followup work as part of making the experimental module stable. If it does not need to block commit, post a followup issue on the roadmap instead of commenting on the initial patch. (Also see the approval process for initiatives.)

# How do experimental modules become stable?

An existing experimental module may be marked as alpha, beta, or release candidate at any time (including in patch releases) except during the overall core release candidate phase.

Before the alpha phase for each minor release, core committers review the status of all experimental modules in core and work with the modules' maintainers to reassess their stability and whether they are still on track to become stable modules. In order for the module to be moved out of the Core (Experimental) packaged and be considered a stable part of core:

  • All the required followup issues on the approved roadmap must be finished.
  • All core gates should be satisfied.
  • The module should be considered feature- and API-complete by the maintainers.
  • Most major bugs and any critical issues identified during real-world testing should be resolved.

# When would an experimental module be removed from core?

Not all experimental modules may graduate to stable status. The following situations may lead to the experimental module being removed from core:

  • The technology used is found to not be a match to implement the feature desired.
  • A better solution in core supersedes the module.
  • Sufficient progress is not being made on the required followup work within the timeframe indicated on the module's roadmap.

This list is not exhaustive.