“Only for testing” or not entirely true? Are the experimental modules in Drupal 8 some great “tools” to submit new improvements for testing to the large community of Drupal users or are they more than that? Or are they, instead, some “packages” full of cool new features that you should seize the chance and “unwrap” right now?
It's certain that this new type of Drupal 8 modules has gone beyond the testing phase. But it's also true that they're not yet fully supported and that you still get “Use them at your own risk” warning messages each time you try to install a “tempting” one.
This builds up a lot of confusion around the experimental modules in Drupal 8, no doubt about that!
Now let me try to give you some straight answers to all your questions and to all the legitimate dilemmas that you might be facing. To reveal to you all the upsides and downsides of using experimental modules in your next Drupal web project:
But First: What Are These Experimental Modules in Drupal 8?
The concept of “experimental modules” is still a relatively new one in the Drupal world. It's not until Drupal 8 that we adopted it into our vocabulary as Drupal developers.
Basically, this type of approach to developing the Drupal 8 core aims to streamline the process itself, which is usually a lengthy one (it takes years) and “seasoned” with releases of unstable, problematic versions, as well.
By adding experimental modules to Drupal 8, core contributors can instantly add new functionalities or expand certain features and (most importantly) have all these new improvements tested out by the whole user community.
It's going to be a continuous improvements-adding process all the way to Drupal 9's release.
Meanwhile, the team working on Drupal core can gather usable user feedback, adapt their experimental modules accordingly and have these modules launched on Drupal's minor and major release dates.
And speaking of those (the minor releases), it's precisely this shortening of the release cycle in Drupal 8 that favored the adopting of this type of “experimental” approach: some features and functionalities just need more than 6 months to get fully developed and thus fully stable, as well.
And it's this specific “need” (of more time and a wider test) that the experimental modules in Drupal 8 came to meet.
And Drupal 8's not even the first CMS having experimental features, if you come to think of it! Take the “Features as a Plugin” in Wordpress, for instance. It led to the release of multiple non-core plugins that were being tested and constantly improved without being fully supported!
Which Are The Current Ones in Drupal 8?
Drupal 8 ships with experimental modules so you pretty much get them “out-of-the-box”. Just navigate to the Extend page (/admin/modules) in your Drupal core package and you'll see them all there, listed.
Let me mention just a few of the current ones:
- Migrate Drupal
- Migrate Drupal UI
- Workflows
- Layout Discovery
- Content Moderation
By What Levels of Stability Do They Get Classified?
As you can see in your own Drupal core package, your experimental modules in Drupal 8 fall into the “alpha”, the “beta”, the “release candidate” or the “stable core module” categories.
Now, allow me to briefly describe each one of these levels of stability:
- Alpha: groups modules which are still under development and that still need serious testing; severe bugs and critical issues are being tracked down and examined (feel fee to run your own tests on an Alpha experimental module whose new potential functionality stirs your curiosity!)
- Beta: unlike the Alpha ones, this type of experimental modules is both feature and API-complete. Therefore, you might be tempted to “take one for a drive test”, to install a beta experimental module on a development site. Keep in mind, though, that they might still carry on some undetected bugs!
- Release candidate: are ready to “get released into the wild” and could easily be labeled as “almost stable”, since there might still be some major issues that need to be tackled
- Stable core module: at this point the experimental modules gets fully integrated in core, get fully supported in Drupal
Should I Be Using Them, As Well?
“... that is the question." The one that made me write this blog post in the first place!
My answer's short version would be: “You could, yet you shouldn't.”
Or at least not without knowingly accept the risks and the downsides involved!
Let me detail: experimental modules in Drupal 8 should still be treated as “under-testing” bits of new functionality. They might work now and boost that Drupal site or that app that you're working on as a Drupal developer in Canada, yet you should accept the risk of it being removed from Drupal core at some point.
Critical, well-hidden bugs might pop out at some point and the module might get removed by its maintainer(s).
“But what if I want to build an experimental module and suggest it as a core issue patch?”
If it's on a client's project that you're working on, you should be 101% sure that they know the aspects (risks here included) involved and that all the managers get a clear grasp of and accept your “experimental solution”.
And remember: your own experimental module, too, stands the risk of getting removed from Drupal if it doesn't meet the due requirements!
Tempted to Add Your Own? What Requirements Should It Meet?
And speaking of “due requirements”, let me reassure you that experimental modules in Drupal 8 do not need to comply with standards as high as the stable ones.
Nevertheless, there are certain “rules” that you need to comply with when/if you consider adding your own experimental core patch to Drupal. I'm going to point out just a few:
- your module should, by the time you put it to the "public" test, have already undertaken some serious testing (no issues in HEAD are accepted)
- it shouldn't present any integrity and security-related issues
- elements such as extension names, plugin Ids and namespaces should be valid (and you should stick to those specific names throughout the development process, needless to add)
- a time frame should have already “made public”, one including all the development tasks that you need to carry out, the way in which you'll be addressing followups etc.
- a basic API documentation (for complying with the basic requirements)
When Do Experimental Modules in Drupal 8 Mature Go "Stable"?
It's more than obvious that they aren't being developed with the intention of keeping them “under testing” for ever and ever. That the core contributors' main goal is to help them evolve into stable core Drupal modules.
And how/when do they mature to stable?
First you should know that all these contributors work hard reviewing the status of each experimental module before every minor Drupal release. They check whether the key issues have been addressed, what progresses the module maintainers have made for ensuring their modules' enhanced stability and... they make their decisions.
These are the main criteria by which that Drupal core developers judge whether an experimental module's ready to “get stable” or not yet:
- all the core gates have been satisfied
- the module's API and feature-complete
- all the issues pointed out on the initial time frame have been successfully addressed
- the great majority of bugs and critical security and integrity issues have been solved
This being said, you should keep in mind that NOT all experimental modules in Drupal 8 become stable modules. Sometimes:
- a more viable or an equally effective solution already exists in Drupal core
- the crucial issues don't get resolved within the suggested time frame
… and modules remain in the experimental phase.
Have I managed to clear away at least some of your confusion regarding this “new” experimental modules “trend”? Have you tested any of them, implemented in your own web projects as a Drupal developer or maybe even developed your own experimental feature? Feel free to start a discussion in the comments here below!