Managing obsolete modules

In every Drupal project, it is crucial for your application to be fully defined in code at every time and every state. When working with a configuration management based upon Git (www.git-scm.com/), Features (www.drupal.org/project/features), Drush based shell scripts (www.undpaul.de/en/blog/2013/06/26/simplify-your-development-workflow-dr…) and Master (https://www.undpaul.de/en/blog/2013/06/28/introducing-master-drupal), it is possible to represent your whole Drupal 7 application's configuration state in a traceable and reproducible way.

Watch your Drupal modules

This way your team has a good tool to manage the development of the application and even manage the state of the Drupal modules in your application. Especially in large Drupal projects it is always important to know the modules you are dealing with, what modules to enable and to know what modules you can disable. Even already disabled Drupal modules influence your system and the overall development experience of your team.

For example, if you provide a large set of modules in your project, there will be a lot of noise for the developers when working on the sprint issues (e.g. a developer might find search results in the IDE for a code snippet in modules that are not meant to be enabled anymore). Therefore it is important all modules that should not be enabled are really disabled and uninstalled from the Drupal project. And, if possible, after that the modules should be removed from the file disk. As we are (hopefully) always dealing with a version control system like Git, we are safe to remove those modules without losing any information of the project's evolution.

Remove modules with Master

In projects that have grown for several months and no-one had a look at the modules directory, it will be very painful and time intense to remove those obsolete modules. To ease such tasks in the development workflow, we created the Master module some time ago. With the latest release of Master  (www.drupal.org/project/master), we have also introduced a new command to assist you in finding the modules you really don't need anymore in your directory.

With drush master-removables you will get a list of Drupal module directories that can be removed from the project's file system. When combining the command with the remove command, you can delete those modules from the file system:

rm -rf $(drush master-removables --absolute --pipe)

Make sure you checked the output of drush master-removables, especially when dealing with multiple environments (like develop, testing, live), you have to make sure all modules you are about to remove from the filesystem have been properly uninstalled before. For example, in Sprint 11, when your team decides they will not work with the Context module anymore, but it already has been rolled out and enabled in a previous sprint, they cannot simply remove Context from the Git repository in Sprint 11. That's because the module will be needed to successfully fire the uninstall procedure on the production-installation for that module in the next roll-out. So you may only fully delete the module after the roll-out was successful and make that change in the next sprint.

Tip: When you stumble upon such a situation, simply remind yourself for this task in the next sprint by creating a new related issue in the backlog for that upcoming sprint.

Absent modules

In some cases, e.g. when carelessly updating or removing modules, there might be modules missing, although the Drupal installation needs them to be enabled. For example some module was removed although the module was still enabled. This might be a heavy performance impact, as Drupal will scan the module directories several times each Drupal bootstrap. This would be not good. To make sure we do not run into this scenario, the newest Master release also contains a command to list those modules that are not in the installation but should be present. With `drush master-absent` you will get a list of those modules and can fix the problems.

The command will also list those modules that are part of the master configuration or an unmet dependency of the master modules and are not present in the module directory.

Master development

We are curious about your experience with Master or other approaches of managing your modules' state. As we are currently working on a stable release for Drupal 7 your feedback is very welcome in the Master issue queue on www.drupal.org/project/issues/master.

If you need any help in your Drupal development workflow, we will be happy to help with our professional Drupal service.