TF-1 Technology Blog

I came across an issue when updating core and contributed modules on a system that had changes made to both.  Now normally you just use drush pm-update (or the alias drush up)  and that will show the update information, prompt you to update your core and contributed modules to the recommended versions and then update your database.  You can also do the code and database updates separately by using pm-updatecode and updatedb.

With local hacks to the core and contrib however, you will lose your custom changes if you update your system in the normal fashion.  What we’ll have to do is find the changes we made to the modules and apply them to the updated modules.

1. Download all the contrib modules using the same version number that you have installed. This replaces all the modules with clean unchanged modules (I created a custom drush command which automated this process).
2. Create patches for each project.  This create a file that records the difference from the modified versions to the clean versions you just downloaded (I used git and a shell script to create the patches).
3. Download the updated versions of the modules. (modified and reused the custom drush command).
4. Apply the patches to the updated modules. (I used git and another shell script to apply the patches).
5. Make sure the patches applied and check to make sure they still work.  (They may not always apply correctly since files may change drastically or maybe eliminated altogether.  Even if they do apply correctly, they may no longer work correctly due to the updated modules not functioning in the same fashion).
6. Try to avoid having maintenance nightmares by not hacking core and contrib.  Try submitting your hack as a patch or retain the functionality in the contrib module and implement the custom functionality into custom modules instead.

This is a measure taken to deal with updating hacked core and contrib modules.  Hacking core and contrib modules creates a nightmare for site maintenance and should be avoided as much as possible.

If your changes are bug fixes or can be used by others then the best thing is to incorporate your changes into the  Drupal core or contrib modules.  This allows the module to improve and become more robust.  Your changes can be helpful to the community and others can improve on features that you use as well.

If your changes are only useful to your particular application then making a custom module is also a viable solution.  You can create a module from scratch to provide all the functionality needed.

A better solution is to use the functionality provided by the core or contrib modules and then use a custom module to modify the behaviour to suit your needs.  This way the main functionality is provided by the contrib module and the specific functionality needed for your application is provided by your custom module.

The advantage of this is that you are able to benefit from the security updates and maintenance to the main module by the community and only have to make changes to your custom module.

One of the major obstacles to clean coding is duplicate code.  If you have the same code functionality in different areas, then you are forced to update the code in every area it’s placed.  It’s much better to refactor the code, put that functionality into one place and call it where it’s needed.  If we hack core and contrib then we are replicating code in 2 locations.

We should try follow the DRY principle (Don’t Repeat Yourself) which is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”.