You're Doing It Wrong: Don't hack Drupal core

Companies love Open Source Software. They do. Sure, you might think many think of OSS as buggy, unstable or insecure (and you're right, some do), but more and more companies embrace OSS.

But many don't do so for the right reasons.

They do so because they can hack the s&%+ out of it to make it fit their every need.

Same goes with Drupal.

"Never hack core!"

This phrase is commonly heard in the Drupal community. You might have seen it on T-shirts or stickers. It is one of the most important best practices for Drupal.

"Core" means all the files that belong to the original Drupal installation. That is all files except the ones in the "sites" folder. You can add installation profiles to the directory "profiles," but you should not modify any of the files already present in that folder.

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...

How to tell if it's (almost) 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 on IRC and asked some experts?

Maybe 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. You should only consider hacking core or contrib as a last resort.  

That said, once in a while it is clear that a hack is (almost) 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.

The rule is this: if you decide to hack something then you must (without exception) submit a patch on drupal.org

Finally, 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. 

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.

About Lumturio

Lumturio’s update manager for Drupal and WordPress' modules and cores continuously checks for new versions of you or your client’s websites CMS (including contributed modules and themes), and alerts you when updates are available.

Our dashboard indicates and/or notifies when new releases of modules, themes or core updates are available for download.