Are you prepared to take a chance with Experimental Modules?

Lately, a lot of our attention has been dedicated to Drupal modules. We have explored the most popular ones and the best for Drupal 8. But we will not stop here. We'll also look at the experimental modules, which may confuse some Drupal users. As you will see, there is also some risk in having them.

What are the experimental modules?

As stated on the official website of Drupal, experimental modules are modules that are included in Drupal core but are for testing purposes, so they are not (yet) fully supported. This new approach was introduced in Drupal 8. New experimental modules can only be added in minor releases. They may change between patch releases, while still being experimental. That differs them from the other features. Experimental modules allow site builders and core contributors to receive feedback and test out functionality that might eventually be supported in an upcoming minor release and might be included as a stable part of Drupal core. However, not any module can be experimental, because they too have to meet the minimal standards.

 

Experimental modules not stable

 

Alpha, Beta, Release candidate …

There are different stability levels of the experimental modules. Alpha experimental modules are still under development. They are, however available for testing, but may include bugs, security issues and the developers should not rely on their APIs. Beta experimental modules are, on the other hand, considered API and feature complete. They are still not fully supported and may still have bugs. If critical bugs are removed, the experimental module can become a release candidate, which means that it is release-ready. Once they are judged as stable, they are labelled as stable core modules. But they can become so only in minor or major releases.

Examples

These are experimental modules in Drupal 8.0, released in November 2015.

 

Experimental modules

 

However, the number of the experimental modules has at least doubled since then. Until recently, it was only the Big Pipe module that »has evolved« from being an experimental module to being an official module. But there might (!) be two more in Drupal 8.4.0 on 4th October 2017, as the Drupal 8.4.x Media API has become stable, after an enormous effort by the Drupal Media Initiative. The second one is DateTime Range, which also became stable for Drupal 8.4.0.

On the other hand, several experimental modules have 8.4.x alpha deadlines, which is on Monday next week (31th July!), when Drupal 8.4.0-alpha1 will be released. If these experimental modules will not reach their follow-up requirements until that deadline, they may be removed from core. These experimental modules are:

1.      Workflows and Content Moderation 

2.      Inline Form Errors

3.      Place Blocks

4.      Settings Tray

 

Workflow

 

Drupal 8.4.0-beta1 will be then released on the week of August 14th, while the release candidate phase will begin the week of September 4th.

Possible risks

Despite the fact that new capabilities can be added faster to Drupal – for that you have previously required a new major version – there are some possible risks of having the experimental modules. As you may have found out, not all experimental modules became or will become stable core modules. If they turn out not to be a good fit, they are removed from the core in future versions. Moreover, they can even change. That basically means that if you have found a solution to optimize your work, you may, after some time, be left without it. So, there were some arguments about, what kind of message does the Drupal send to the end users by giving them something that might not work.

 

Experimental modules at own risk

 

There are of course some other reasons for experimental modules to not become the stable core modules. They may not have made a sufficient progress or a better solution in core supersedes the module. Nevertheless, the experimental modules do not share core's version. When you want to enable them, you get the message saying "Use at your own risk", which is also a big problem, especially with the users that do not like to take risks. The risks are, in general, connected with APIs, bugs, security and other issues.

All in all, it will be once again up to everyone to choose whether to use experimental modules. But as the founder of Drupal Dries Buytaert said on DrupalCon Baltimore, it’s probably not wise to use them in production.