One of the most interesting and power features of Drupal web development is the huge library of contributed modules that have been developed over time by the Drupal community. How huge is that library? Well, according to the official module list had about 640 pages as of Nov 7, 2014. With about 25 modules per page, that figure comes out to close to 16,000 modules, and that was more than a year ago!

The breadth and scope of all of these various modules is immense, with some being as simple as a tool to creates a small block that provides weather information, to extensive library API's that open up access to other third party systems. And amazing as all of that is, it is even more remarkable that the vast majority of the work that went into envisioning, developing, and testing all of those modules was done for free as a community effort.

The contributed module ecosystem, while attractive, can eventually be a source of frustration down the road. As is the case with most software, new versions are developed and users are encouraged to update to the latest version. The older versions might be maintained for some time, but they will inevitably be retired to a status of "unsupported". This process presently has Drupal 6 next on the list of versions of Drupal that will soon no longer be officially supported by the core Drupal security teams.

When new core versions of Drupal are available, full functionality equivalency will only be available when the community upgrades the code in all the important contributed modules. The work involved with updating modules to work with the latest version of Drupal can sometimes be significant, with some modules requiring teams of people working on issues. Volunteers taking on this high workload for a new version means that less time can be allocated towards updating an older version of the module that operates with the legacy versions of Drupal.

Module Dependency

So that takes us to the ultimate issue here: by using lots of contributed modules you can potentially open yourself up to being dependent on a lot of different pieces of code being maintained and then updated into the newer versions of Drupal. This is not to say you shouldn't use contributed modules, nobody could suggest that, but rather you might want to think very hard about each module and if you can accomplish the functionality you need in some other way with core-based modules.

I've seen client websites that literally had a hundred contributed modules enabled, and while in some cases maybe there is a business need for that, the risk you take is that your website becomes dependent on the functionality provided by those modules and that the support or upgrade path for all of them may not exist in the future. There are some contributed modules that are so widely used that outside companies will actually sponsor the work being done to upgrade them. So for those types of modules, Commerce for example, you can be reasonably sure there will be support and upgrades into the future.

Other popular modules may even become a part of Drupal Core itself, such as the Views module which is now in Drupal 8. The point is, just because a module is supported now, does not guarantee that support will be there two years from now, or that the module will be upgraded to work with the next version of Drupal. So, it is important to recognize that truth before becoming dependent on its functionality.


If you take the time and care to think of module usage in this way, you could potentially save a lot of time, energy, and money when upgrading your Drupal website in the future. The fewer modules you need to evaluate for their upgrade status, the quicker and easier an upgrade for your whole website will be.

The downside for this type of approach is that you may have to make some hard decisions about how you incorporate functionalities or even if you add certain features at all. You may have to decide between implementing a feature in a way that uses core modules but doesn't work as efficiently as you'd like, or you become reliant on a contributed module to provide the feature set in a way that makes sense.

* * *

I hope by reading this article you do not become afraid to use contributed modules. In truth, they are the lifeblood and most amazing feature of Drupal. I think the main takeaway should just be that the power and usefulness that contributed modules provide should be recognized as requiring a certain amount of discipline. It can be easy to abuse that usefulness and set yourself up with a website that is hard to maintain. But with a little care and initial planning, you can utilize all of the great features and modules that Drupal has to offer - and design a website that you can keep running for a long time to come.