By the_undefined on

Advice

You all know the problem. No matter how hard you try, sometimes you've just got to hack a peace of code somewhere in either the drupal core or a module. Nothing wrong with that (pragmatically spoken), until the point you want to update to a newer Drupal Version and don't want all your Hacks to be lost.

So here is my idea about how to deal with this problem:

  • Put a file called hacks.txt on your drupal root
  • Whenever you hack a peace of drupal code add the path to the file you hacked in the hacks.txt
  • In front of the lines you hack add a comment: "// HACK" and then copy the code like it was before you hacked it directly below.

So whenever you want to update drupal or a module you just overwrite everything and then you look for the files you've modifed. Open up the old ones and search for the term "HACK" in the document. That way you'll find everything you've changed real quick. Then you look in the new file and see if the fix already has been made or needs to be applied again.

I know this is actually something very simple and still requires a good amount of handwork but I think it's a very reliable way of handling things. Before working like this I thought about using Subversion/CVS and patch my files by diffing them, but this isn't going to work pretty often since the hacks you make are often just "error fixes" which might be done in the next version and so the patch is going to be applied "double" and you have to figure out why things aren't working.

So maybe this is useful to somebody.
I also would like to hear how other people deal with this issue.

--Felix

Comments

mach’s picture

mach commented

I deal with hacks in a similar way. I just found out about drupal, so I haven't hacked anything yet, but I use a similar method with other software. They key is to comment out instead of deleting, and note the changes you made. It only takes a little longer, and can save a lot of headaches when upgrading.

laura s’s picture

laura s commented

I've just been keeping local copies and taking copious notes. Your idea of making a repository file to reside right there, for easy reference, sounds like a nice backup.

Ultimately I prefer upgrading via patch, so that unless the code I hacked is part of the patch, or affected by it, I don't lose the hack, but with new releases comprised of dozens upon dozens of patches, that's often not practical.

Laura
===
pingVision • rare pattern • scattered sunshine

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

the_undefined’s picture

the_undefined commented

Hi Laura,

I really like your website (pingVision), very nice work!

May I ask how you did the Flickr Style Tag boxes that make scale the font according to the relance of the Tag? Is there a module for it?

Felix

laura s’s picture

laura s commented

...though I modified it to fit more tags.

(Thanks for the comment!)

Laura
===
pingVision • rare pattern • scattered sunshine

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

dman’s picture

dman commented

I run under CVS, so I ensure my file is up-to-date (with my local repository),
Hack (with a useful comment),
Create Patch/Diff
Name the patch file something useful.
The comment is a readable, hopefully self-explanatory part of the patch file, but sometimes I edit the preamble also.

To see what changes are in place on my install, I just have to list the patch files (which I left next to the source files)

I dunno how this approach will pan out in the long run.

Yes, CVS is tricky to get comfortable with at first, but once you've got it configured, you might as well do it properly.

http://www.coders.co.nz/

.dan. is the New Zealand Drupal Developer working on Government Web Standards