Hacking Core & Contrib Responsibly

By now we have all (hopefully) heard the Drupal mantra "Don't hack core!" Usually this statement is followed by a quip about killing kittens and then a long (and necessary) diatribe about how hacking core makes it more difficult to maintain your site; leads to unexpected behaviors; and makes debugging issues ...um... adventurous. These things are all true. Very, very true.

But if you work on enough Drupal sites with enough complex requirements for enough time, then invariably you (and/or your team) will find yourself in a position where it seems like the right thing (or only thing) to do...

Caveats

Take the adice below with great care. All the scary diatribes I describe above are true, so tread lightly. Remember to always backup your site (both code and DB) and always test (a lot) before putting your hack on a production site.

How to tell if it's ok to consider hacking core (or contrib)...

Have you considered all other options? Maybe there is a way to use Drupal's hook system or various avenues of theme overrides? Perhaps there is an _alter function you can use? Have you gone into IRC and asked some experts (be nice in there)? You should only consider hacking core or contrib as a last resort.  

Generally there are only two situations where you should ever consider the big H: either you find a bug or you need a feature that cannot be achieved otherwise. "It would be so much faster if..." is never a good enough reason. 

That said, once in a while it is clear that a hack is ok. For example if you come across a patch on Drupal.org that has already been committed (or a maintainer has indicated that he or she plans to commit it (ex. as soon as this is documented...) then it is probably a safe bet to go ahead and apply that patch.

Usually it is not so obvious, but if you do your due-diligence and don't have another option then maybe its time.

Some helpful hints on what to do if you do hack core or contrib... 

My team has a rule that helps guide us. The rule is this: if we decide to hack something then we must (without exception) submit a patch on drupal.org. This keeps us from being nonchalant about things and it also makes us good Drupal citizens by submitting patches for bugs and/or feature requests. Maybe it will get committed, or maybe it will help someone else, OR (and this happens a lot) maybe someone will come along and say "oh, did you consider _____" and our hack becomes unnecessary. 

In addition we have a rule that every Drupal project we work on contains a file called PATCHES.txt. In that file we document every change we make to every contrib module and to core including a link to the patch on drupal.org. This makes updates easier because we have one file to check before any update. If there is a new version of the dfp module (for example) and we have hacked it then we know to take extra care during the update by following these steps:

  • Backup everything. (you should be doing this anyway)
  • Update the module locally. (you should be doing this anyway)
  • Apply the patch if needed. Maybe your problem got fixed in this release.
  • Test and then test again. Now have your friend test.
  • Document any changes in PATCHES.txt so that you are prepared for the next time there is a new release.
  • Commit your code and move it up to production.

Some people (especially those who use drush make files) keep a folder with their sites and actually store the patches they use in there. Not a bad idea...

Finally, and most importantly, change as little as possible. If you can change just one small thing to get yourself over the hump where you could continue in a more traditional Drupal way then do that. For instance, often all you need is to add a module_invoke_all() or drupal_alter() somewhere and then you can do what you need in a custom module. The more changes you make, the more likely you will regret it later. 

Got Milk? 

My point is simple, hacking core and contrib is like drinking milk past its expiration date; you know you shouldn't but sometimes you've already poured the cereal, so you give it a good sniff, check for lumps and you do a quick google search on when milk really expires. Now you have to decide to dump it or drink it.

If you decide you're going to drink the milk, just make sure you have done everything possible to prevent making yourself sick... because if you're not smart about it, there is a decent chance you will.