3

Is there a module or something else that you can use to check if all enabled modules on a site are really used?

I've searched the internet but with no results ...

5
  • What do you mean "really use" enabled modules ? You enable modules to use module features...
    – Anil Sagar
    May 8 '14 at 15:11
  • 1
    The OP seems to be asking if the modules enabled on a site are performing any useful function. I'm sure we've all seen sites with enabled modules that weren't actually doing anything useful. When I see that I investigate and disable/uninstall those modules whenever possible.
    – keithm
    May 8 '14 at 15:36
  • Yes that's what I mean. Sometimes you install modules to test or find better modules for the functionality you need and you forget to disable the last one ..
    – nielsv
    May 8 '14 at 15:38
  • 2
    I don't think this question warrants the current downvotes. I am sure we have all gotten ready for site deployment and stared at the module pages trying to remember if we are actually using a particular module on a site. And just because something can't be done doesn't make it a bad question (if that was the reason for the downvoting).
    – mpdonadio
    May 8 '14 at 16:25
  • @MPD I guess the question is down-voted because it doesn't show any understanding of the problem.
    – apaderno
    May 8 '14 at 16:44
8

It sounds as if you're installing modules on a production site willy-nilly, just to try them out. I suggest you stop doing this. While people like me earn some of our living from helping the owners of such garbage piles sort through their wreckage, I'd rather get paid for building stuff than for cleaning up.

Instead:

  • Set up a staging site for testing stuff. Only deploy on the production site if it is proven useful.

  • Keep a log of everything you deploy on the production site, with details about when and why. Log also when you disable and uninstall, so you don't forget and make the same mistake twice.

The above is absolutely essential if more than one person runs the web site - but I've found it helpful even if there is only a single webmaster that does it all.

There is really no way of keeping tabs on "what you really use" automatically or semi-automatically. Configuration management is just one of the tasks a webmaster is supposed to do as part of a honest day's work.

3
  • interesting and harsh comments. i came to this question as there is a module called Title which came via a theme and now that module is not supported on drupal 8, however the site is live and i thought to check if there is a safe way to figure it out. else i will resolve to experiments on a backup. Dec 6 '18 at 1:51
  • @KalpeshPopat this was written before D8 and configuration sync came along, so, for new sites, you can commit all your configuration to Git (which you should because it makes deploying to production a lot easier) and later see when modules were added/removed (look for changes to core.extension.yml). In case of the title module, this issue lists working alternatives. Dec 6 '18 at 13:29
  • 2
    Yes you are right, though it is not about version and its features, it is about assuming that people add modules willy nilly - i am saying there can be many reasons why one may end up having modules that are not needed...and answer should focus on the problem in hand. Dec 7 '18 at 15:32
4

I see sites with this issue a lot. Not all of us get to build wonderful clean sites from the ground up, sometimes you get stuck with a project where people were irresponsible about modules and installed them willy nilly. The method I use is:

  1. Make a list of potentially unused modules. Sometimes you just know something is being used, but if you've never heard of it, you might want to see if it's actually in use.
  2. By examining the module's code, look for what database schema it uses. Then examine your databases and see if those tables contain information at all. If they do, does it look important? (Now that I'm thinking about it, you could probably use the Schema module for this).
  3. If it doesn't look important, pull up the site in your local development environment and test out disabling that module. It's a good idea to have functional tests or at least a site function testing checklist to work with at this point.

It's kind of a lot of work, which is why in my own from scratch projects I take a hard line in making sure unnecessary modules aren't installed on live sites. But not everyone does this.

0
3

A few years ago, I inherited a handful of Drupal sites. Upon looking at the installed modules, it was obvious that some were unnecessary (e.g. the LDAP module, when no LDAP authentication was being used, and the module was not even configured). But others weren't so obvious, like Views Isotope and Webform Hints, which I eventually discovered were installed and enabled but not used in any capacity within the sites.

In my case, it took some good old detective work and digging through the sites; however, I also got some help from the module called Unused Modules.

It lists unused modules and projects that can be safely deleted.

1
  • 1
    I agree. Especially for those of us who get pulled in to "rescue" or migrate poorly constructed sites, it's essential to be able to be able to figure this kind of thing out.
    – Melissa
    Oct 29 '15 at 18:07
0

Perhaps you could setup a development environment for testing these modules. But as soon as a module is registered it does something. It might hovever never get called. On the other hand, you might install a module to perform a future function, so at the moment it does nothing, but it might later.

The way Drupal uses hooks makes it very hard to find if a module actually is called. The only way would be to fire all available hooks and see if something comes back. But since most modules invoke hook_menu (to register pages) they all do something and the system will never know if this is just a settings page or a fancy page doing magic things.

In short, a module won't be able to tell if it actually performing a function.

0

I understand the need, but as far as I know there is no way to do this automatically.

Creating a universal module that would work in any installation would be quite complex. There are too many ways in which you can use a module in a non-standard way.
For example, you could use some of the module functions in a theme, a block (PHP input filter), Rule (raw PHP), Context (again raw PHP), etc.

You have to understand/check the installation yourself and then remove unnecessary modules manually.

Not the answer you're looking for? Browse other questions tagged or ask your own question.