This is something I talk about a ton. Not Drupal module’s specifically, but how many ways there are to do things in Drupal. In many cases, there is actually more than one totally valid (if not, perhaps, 100% “right”) way to do the same thing. This is one of the things that makes Drupal so challenging. You don’t just have to learn one way to do something (or wade through documentation and examples of doing things one way). You have to sort through MANY ways of doing something and try to figure out which ones work AND which ones are acceptable / align with best practices. It’s non-trivial to say the least.
So after realizing today on a project that we had enabled a module in a way that wasn’t sustainable long-term (because once it was on, we couldn’t turn it off without also disabling a bunch of other stuff) I thought this would be an interesting exercise.
My challenge for you? Take a guess before you read this post. How many ways do you think there are to enable a module in Drupal 9?
Disclaimers / Rules
I 100% recognize as you read this list, there may be some things that you say “Now Mike, those are actually the same thing.” And I agree! There are duplicates on this list. HOWEVER there are duplicates on this list because that duplication exists in Drupal. It’s not my fault that 3 people could do the “same thing” in 3 totally different ways.
I am not counting any method of “adding modules to the code base” (e.g. downloading tar files or using composer). We can safely assume that the modules are present when you go to enable them.
I AM counting community contributions in this regard. So this is not a “core only” list. There are modules (like Config Split and Features) and there are tools (like Drush and Drupal Console) to consider.
Finally, I recognize that many of these methods would supersede other methods on the list. You wouldn’t (or shouldn’t) use “all” of these methods on the same project. But again, all of them totally work. I’m not sure all of them are “valid” but all of them work!
Ready? Have your guess? Let’s go!
1. Admin User Interface
The OG method of turning on a module. Log in as an admin and go turn it on in the UI. While likely the “simplest” way on this list, it definitely isn’t the fastest. It also is one of the most volatile ways of enabling a module since you are directly manipulating active configuration (and if you have a configuration management strategy in place, the next time you deploy config the module will get disabled again).
2. Configuration Export’s core.extensions.yml
If you are taking advantage of a configuration management strategy, all of your modules will get dumped out into a nicely formatted list in the core.extensions.yml file inside your config dump.
You can enable modules by adding them to this list and doing a config import / sync.
3. Module Dependency
Every module’s info.yml file can (and probably should) contain a dependencies key that makes your module reliant on “other modules.” When you turn on your module, your module will automatically enable all of those other dependencies.
4. Theme Dependency
Same as #3 but in the theme’s info.yml.
5. Profile Dependency
Same as #3 but in the profile’s info.yml.
6. Profile Install List
This one is “similar” to #3 but has one significant difference. The install list will turn on a bunch of modules but will not make them dependencies (meaning that you can uninstall them later).
7. Drush Install (CLI)
One of the most common “non-Drupal” core ways to turn on a module is drush pm-enable (or drush en). Obviously this requires Drush to be present / installed and like #1 (enabling via the Admin UI) this is quite volatile as the module’s enabled state won’t survive a config import / sync unless you capture the config change.
8. Drush Install (code)
Did you know you can call drush with PHP and then execute drush commands in your code? Well you can! I don’t really think you “should” (because Drupal ships with its own module installer service, see #10) BUT you “can” do it this way.
Legacy versions of drush have the “drush_invoke_process” command which was recently deprecated and replaced with the Drush::drush() command.
9. Drupal Console Install (CLI)
The same as #7 just with Drupal Console instead of Drush.
10. Module Installer Service (code)
Drupal 8/9 ships with a handy module_installer service that can be called in PHP. Usually you’d want to do this during a cron job or .install file’s update or install hook.
\Drupal::service('module_installer')->install(['module']);11. Config Split
When you define a config split (conditional config) you can toggle modules on as part of the split. Then, when the split gets turned on and config is synchronized then the additional module(s) get enabled.
12. Features
Features are basically modules so this really runs the risk of being a dup of #3 but given that Features has its own UI and commands for managing its processes, I think it’s still worth calling it out as a way to do it!
In Conclusion
Did I miss any? I think 12 is a pretty long list of ways to do something like “turn on a module.”
For me, on most projects, I use core.extensions to manage my enabled modules and config split to toggle them on / off. Drush is technically used to run the config import at that point (which I didn’t put on the list, because drush cim enables modules via core.extensions.yml and config split, so it felt like cheating).
This is one of the many reasons that Drupal is “so hard” to learn. Do you need to know “all” of these ways to be successful with Drupal? Definitely not. But as you start trying to learn about Drupal it’s highly likely to find conflicting information about “how best” to accomplish this task. Worse, wading through the above list requires a lot of related material and related topics (like configuration management).
I think it’s important to lean into lists like this, though. We need to recognize the complexity of a thing before we can work together to make it simpler!
Related Content
Sometimes the order of updates is quite critical. And while Drupal usually has a quite predictable order for those updates to run in, they don’t always land in the order you expect. This tutorial will help you to execute updates in the order you want.