Cleaning House: Find & Purge Unused Modules from Your Codebase

A codebase can end up with a bunch of unused modules one way or another. Identifying unused/installed modules is tough, but identifying unused/disabled modules is pretty easy.

Modules and their status exist in the system table of Drupal. It's simple enough to query for disabled modules, but that will return results of modules which may have already been removed from the codebase.

In a case of a very large inherited D7 project, we had about 150 modules show up when querying the system table for modules where the status was 0, but only about 40 of those still existed in the codebase.

Here's how to quickly determine which modules are disabled, but still exist in the codebase.

Note, this isn't a matter of gaining performance, it's simply a method for a bit of house cleaning. This example assumes your contrib directory exists in sites/all/modules/contrib.

First open up a shell and navigate to sites/all/modules/contrib.

Then run this command to get a SQL friendly string of all the modules in that directory.

ls | awk 'BEGIN {ORS=", "}; {gsub(",","",$1); print "\47"$1"\47"}'

The output should look something like this:

'admin_menu', 'admin_views', 'advanced_forum'

Now fire up your favorite SQL client and run this query. Replace <STRING> with the output of the command above.

SELECT name 
  FROM system 
  WHERE type='module' 
    AND status = 0 
    AND filename LIKE 'sites/all/modules/contrib/%' 
    AND name IN (<STRING>);

This will produce a list of contrib modules which are not enabled. If you would like to purge the custom directory, navigate there and modify the SQL to use the custom directory name instead of contrib.

Note, the results won't include submodules, but they are usually dependent on the primary module anyway. Also, you should make sure these modules are uninstalled before purging them from the codebase.