Bookmark/Search this post with:
Monday, May 7, 2007
Of course, we all know the golden rule about Drupal: “If you’re hacking [modifying] the code, you’re doing something wrong.” And in general, this is a very good rule to adhere to. When you want to modify the behaviour of Drupal, you should in almost all cases be able to either write a custom module to do what you want, or handle the modification at the theme layer.
However, sometimes we need to modify the code. There might be a bug in a contributed module that the maintainer hasn’t gotten around to fixing yet, or we might need to back-port a core patch for the next version of Drupal in order to gain a particular feature or performance benefit. We already know that forking code has a variety of severe disadvantages, so how can we best ensure that we don’t get bitten in the future, while still meeting the needs of our project today?
Quick note to the uninitiated: A “patch” is a file containing a list of all of the modifications to a piece of code. For more information, see Drupal.org handbook page on patches.