Drupal 7 came out a decade ago and in that time there has been a lot of innovation, both in the community (via contrib modules) and in Drupal core itself (via both Drupal 8 and Drupal 9). As more and more folks prioritize their rebuilds from Drupal 7 to Drupal 9, it’s a great time to talk about what the process looks like. I’ve both blogged and presented on this generally, but today I wanted to focus heavily on modules. This is, by the way, essentially the opposite of the post I did recently on the top modules to use on every build.
In Drupal 7 the rule of thumb was “there’s a module for that.” In Drupal 8/9 the rule is… you may not need a module for that. Why? A few reasons:
Drupal core may do the thing already out of the box (so a module isn’t required)
Drupal 7 didn’t give you a way to modify a given behavior / functionality, so a module was required to work around the issue. MANY of these cases have been resolved in Drupal 8/9 simply because of object oriented programming, others have been resolved because they were explicitly identified as areas of focus.
Folks that used to maintain a module no longer do so (or actively recommend against using it).
So, let’s get into the list of 15 modules that you “probably” used in Drupal 7 that you shouldn’t / don’t need to use in Drupal 9!
If you want to follow along, here’s the list of top Drupal 7 modules on Drupal.org.
1. Views
Ok so this one is a bit of a misnomer. You will absolutely use views in Drupal 8 and Drupal 9. BUT you don’t need the views contrib module for it anymore. Views is in drupal/core as of Drupal 8.0!
So chalk this one down to community innovation and don’t look back. I’ve not found anything that the D7 module “used” to do that the D8/D9 iteration “doesn’t do.” The UI is the same, and the custom hooks / processes are far improved (but it may require some refactoring if you have custom fields or other plugins).
2 and 3. Features (and Strongarm)
Features (and Strongarm) were ahead of their time. Given that Drupal 7 didn’t have any sort of configuration management system in core, these two modules allowed teams wanting to implement config a way to do it. Thankfully, in Drupal 8 and Drupal 9 we have the core config management system and a whole new host of modules.
Features itself CAN be used in D8/D9 but even its maintainer recommends against doing so in most situations.
Check out my introduction to configuration management to get started on more modern methods!
4. Libraries
The libraries module actually did persist well into the Drupal 8 life cycle, but recently (as if Drupal 8.9 and 9.0) much of the need for this module has gone away thanks to this work in drupal/core.
Also, there is a fairly robust libraries system built into Drupal core (as of 8.0) for managing css/js as well, which should NOT be confused with the libraries module. What’s the difference? It comes down to “internally managed” CSS / JS that ships with the module/profile/theme and “external” CSS / JS. Again, as of Drupal 8.9 and Drupal 9.0 this can all be managed with drupal/core!
5. Admin Menu
As I’ve mentioned in a few other venues, the Drupal admin toolbar needs help. In D7 that help came in the form of the admin menu module. In Drupal 8 and Drupal 9 you still need this enhancement (because core hasn’t adopted it) but you’ll instead need to swap to the admin toolbar module.
Yes it more or less does the same thing! No, it’s not the same module.
6. Rules
If I recall correctly, I never built a D7 site without the rules module. I used it ALL THE TIME. I haven’t used it in 5 years though. Why? A few reasons.
It’s not stable for Drupal 8 and Drupal 9 (yet).
Despite D8 having been out for the better part of five years, rules still isn’t stable. I think that speaks volumes. Why? Because, if rules was still as critical as it used to be, it would be stable.Most things I needed Rules for have alternatives.
For instance, if I want to send an email after a workflow transition, in D7 I would have likely used Rules for this. In D8/D9 I would use something like workbench email or content moderation notifications.
Rules is a prime example of a module that was so critical in D7 because there just wasn’t a great way to do certain things. In D8/D9 though, many of the uses of rules aren’t required because you can actually jack into the processes in question and write custom code as necessary.
7. Entity API
The Entity API is no longer needed. Why? Because drupal/core treats everything as an entity now. While there are some additional improvements to the D8/D9 core entity api in the module, I’ve not used this module personally in some time.
8. IMCE
IMCE is one of those modules that can be quite controversial. I personally prefer to not use it in favor of the core Media capabilities. Why? IMCE is fundamentally a file browser. I personally do everything in my power to avoid letting my users browse the file server and instead focus on browsing Media entities.
There IS a D8/D9 stable version of this module and you CAN use it, but I don’t recommend it!
TLDR using Media gives you a lot more control over the user experience and limits the chances of duplicate files.
9. Date
The date fields are in core now. Easy peasy, nothing to see here!
10. WYSIWYG
WYSIWYG is in core now!
11. CKEditor
CKEditor is in core now! Note too that core gives you a pretty simple mechanism for adding additional CKEditor plugins / libraries, so if you want to add additional functionality to the editor it’s pretty simple.
12. Link
Link is in core now!
13. jQuery Update
The D7 release and major/minor version cycle made updating core dependencies (like jQuery) nearly impossible. Enter the jquery update module. But in Drupal 8+ the release cycle is designed to give the maintainers and opportunity to update really critical dependencies (like Symfony, jQuery, etc). You no longer need a module for something like this.
14. Transliteration
The transliteration module was one of a suite of modules required to jack in multilingual capabilities to Drupal 7. I remember an early Drupal 8 DrupalCon presentation from Schnitzel that talked about how in D7 he commonly used 15+ modules to make “everything” translatable. But in D8? All the modules are in core AND you only need 2-3 modules. This is one of the biggest advancements between D7 and D8.
15. Media
Media is, IMHO, one of the areas that D8 has made the most advancement. There’s a whole initiative around it! There are really significant improvements to media in core. And you don’t need the media module anymore to make it all work.
In Conclusion
What I’m doing in this post should hopefully demonstrate one of the most critical activities when it comes time to rebuild your D7 site on D9. You have to go through module by module and figure out:
do I still need this? if yes…
is this module still available (meaning it’s D9 compatible)?
if it’s not, what is the alternative? that alternative is usually…
it’s in core
it’s in another contrib module
I have to build it myself.
This shouldn’t be scary. In almost all cases I’ve found that doing things in D8/D9 is actually easier than it was in D7. But, just because it’s easier doesn’t mean it’s the same.
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.