Don't Hack Core

You hear it all the time. Any CMS worth its developers' sweated salt has some system of hooks available to other developers to use for customization of their own projects. What the same CMS would have is an entire commando unit who refuses to use the hooks available because they don't understand them, refuse to rtfm, or simply feel like hacking core is the right, easier, or *whatever-they'll-never-try-to-upgrade-anyway* way to go... or something like that.

The bottom line is:
DON'T HACK IT. HOOK IT!

The hooks are there for a reason. And most.. if not all of the CMSs that are anywhere near popular enough to mention have a set of API calls - including hooks - that mimic anything available to its core. So save yourself, your colleagues, your client, and your boss some headaches and don't hack core.

USE HOOKS, NOT HACKS

With the lack of time that I have to explain and fully complete this post, I will simply say that the two biggest reasons for using hooks over hacks are:

  1. Upgrading a site with a hacked core means you have to go through great pains to either avoid upgrading the files with the hacks or recode the hacks in the upgraded file -- which also includes the possibility that your hack has been made obsolete by the upgrade somewhere else within core.
  2. Hacking core damages the notion of reusable code. "It's the Drupal way" lol. Seriously though, following standards is usually the right way to do it. and the standard says that if there's a way to do it with the current API or core methods, then use that method. You get a lump of coal if you don't make a valiant effort to do so.
Technologies: