A client came to us recently and wanted to transfer his site from another company. We needed to apply security updates to the code but we didn't have access to any version control history of the source code. We used the Hacked! module to see if there is any custom code added to Drupal core or contrib modules so that we don’t lose any custom changes when we update the site. Hacked! Comes with a web user interface but I prefer to run it in Drush because like most Drush commands, it just get things done quicker in the command line.
Download the Hacked! module to your project and enable it
drush dl hacked drush en hacked
To confirm the hacked commands are now available, run
drush help from the command line, and search the output for something like this:
hlp) to analyze your site
If the Status field is “Changed” for your module then it means there are custom changes. You will need to dig deeper to see what was changed.
Compare your version of the module with the one from drupal.org so you can analyze the custom code to see if you can move the changes to a custom module. If not then you will have to merge the custom changes to the latest version of the module.
drush hacked-details nice_menus
This tells you which files are changed
drush hacked-diff nice_menus
Output a unified diff
Sometimes in the analysis status field, it will say your module is changed but it could be a false positive if the module is a development version. (i.e. The version ends with “–dev”) You will have to compare your dev version with Drupal.org’s dev version from a specific date. I won’t go into details for this. You can check out this excellent article on how to do that.
Lock Modified Modules
After you are done reviewing and upgrade all your changed modules, if all remaining modules need to stay at the current version and should not be upgraded in the future, you can run the
drush hacked-lock-modified command to keep them from getting upgraded when you run