Click here if you want to skip directly to the 'how' and slides.

History: WHY?!?

Over the years, I've seen and heard the phrase "Don't hack core!" mentioned by countless Drupal developers, designers, site administrators, etc. There are many blog posts on the matter (the most recent being a few weeks ago though his stance is slightly different from what I see from the rest of the community) and the number of kittens that die whenever someone hacks core. There was even a wristband created a few Drupal Conferences back. Heck, I may have had it and worn it at some point.

I have a strong feeling that I'm going to get a lot of hate for this (I've been hesitating hitting the 'Save' button), but in thinking more and more about the phrase over the years, I've grown a dislike for the mentality behind it (the wristband is long gone, that's for sure). My early days of working with Drupal 4.6 involved doing things to core on my project that really shouldn't have been done ("optimizing" queries so they would only work with MySQL which involved , attempting to rewrite database.inc to work with a master->slave db server connection) . And when the phrase started getting around, I was wholly into it.

In many ways, the feeling was great. I would still look through the issues queue, see if the issue for something not working existed. If it did, then I waited till the issue was fixed. And if it didn't, I reported on it, and waited. Somewhere along the way, I grew an (unwarranted) expectation that there were a group of super talented developers who worked on Drupal day and night like robots. And that they would solve what I needed immediately and things would be fixed up by the next release. Slowly, I stopped looking at Drupal Core. Before I knew it, I wasn't really going into the issues queue to help out with contributed modules (and Drupal Core though I was quite scared of entering that realm) like I used to.

In the beginning (or atleast for some modules), my expectations were met. But there were other bugs and features that weren't being answered at all. And as my expectations from the community weren't being met (did I mention these expectations were completely unwarranted?), I was starting to grow a dislike for many things Drupal. I had sites, they needed some of these fixes / features. And nothing was happening with them. So I slowly started writing patches again to try and fix them up (which meant getting familiar with some of the modules in contrib and now in core - is a great experience) and trying to make sure to post my findings in the issue queue in the hopes that I have done the legwork so its a matter of adding it in. I came to the realization that I am hacking core in the process (even despite going through the right channels and pushing my patches online for everyone to review) because I am nonetheless using some of these patches and making changes to what core (and contrib modules) is on sites that need them.

I also came to the realization that Drupal is not (and does not need to be) an all-in-one swiss army knife that can tackle each and every situation. Not should it be expected to (we have the numerous modules that we do for this very reason, and the fact that the number grows shows that there are even more use cases popping up that weren't there before). As site developers, we need to make a best judgement on what tool will best fit the kind of project we are tackling. And sometimes, that tool will need some refinement to properly complete the project (see the slides below for use cases that fit in).

Ultimately, I feel that there are safe approaches you can take to 'hacking' core. And it is for that reason I feel that, by not doing so, you really miss out on understanding a lot of very good code that is in the Drupal project. You also get to see the not-so-good, try to hack the code to something that could be better, and your participation hopefully makes its way over into making Drupal a better tool for everyone :)

How?

Now that I have tried to justify my reasons for hacking core, let's dive in! For the purposes of this blog post, I am only going to tackle core drupal modules because that is the most likely place of change for a lot of people and they are surprisingly simple to hack. As a note (as pointed out in the comments by *everyone*), this is only one possible approach. You should remember to keep a track of your patches so that any future updates to the core modules / contrib modules can be applied easily when the version changes.

Copy the module you are going to change into your sites/all/modules directory
Go to the modules configuration page and click on 'Save Configuration'

That's it! Now your drupal project will use the module that is in your sites/all/modules directory instead of the core version of the modules in the modules directory. You can now change it up and perform whatever tests you need to perform inside the new module directory. And any time Drupal updates, it will not affect the changes you have made. And you can slowly add the updates made between the core module and your altered version before deploying out into your web site. Finally, once the changes that you made make their way into core (I should mention that whenever possible, try and work on an existing issue that is similar to yours so the fix is 'official' or try and make an issue with your patch so it can hopefully make its way into the Drupal project), you can remove your version of the module, go to the modules page again, hit 'Save Configuration', and you're back to using the core version of that Drupal module :)

I presented on this very topic as a lightning talk to the Los Angeles Drupal Group on Tuesday night and posted the slides portion of this talk on slideshare where I discussed the why, showed use cases where I needed to hack core, and how to do so (I did the hack using a pre-existing issue in the Drupal Issue queue). And their webpage has the slides download link if you want to print a paper copy to burn :) Alternately, I have embedded it in this site as well so you can view it here:

Hacking core

Like what I wrote? Hate it? I like kittens so please don't torch my car! Leave a comment to talk about it ^_~

BTMash

Blob of contradictions

Articles tagged with hacking

Drupal and "Hacking" core - one possible approach

Written 2011-06-30

History: WHY?!?