8

Every so often, I need to make a little hack to a contributed module to add a bit of needed functionality, usually something specific to the project that the module maintainers probably would not want to use.

Currently, I create a patch file for every hack, and I store all such patch files in sites/all/modules. This way, whenever I update a module, I can easily reapply my hacks and address any conflicts.

I can't help but feel like I'm doing something wrong though. Am I?

3 Answers 3

12

A patch doesn't necessarily apply to a new version of a module: It is enough the patched function is moved to a different line, or the code for that function is changed, and the patch doesn't apply anymore. For the function to be moved to a different line, it is enough another function is re-written to take more lines (or less lines).

A better way to alter the behavior of a module is, for Drupal 7:

  • If the module uses code for a page callback that you want to change, change the page callback with hook_menu_alter().
  • If the module implements a theme function you want to alter, change the function associated with hook_theme_registry_alter(). In alternative, if it is sufficient to change the variables the theme function gets, then you can implement the preprocess function for that theme function (e.g. hook_preprocess_rdf_metadata() for theme_rdf_metadata(), and change the variables that theme function will get.
  • If the module executes an SQL query using db_select(), and assigns a tag to the query, change the executed query with hook_query_alter().
  • If the module implements a hook you don't want it is executed, you can implement hook_module_implements_alter() to avoid it is executed.
  • If the module implements an alter hook (e.g. hook_page_alter()), and you want to change what that hook altered, implement the same alter hook, being sure it is executed after the one implemented from that module.

In the case the function you want to alter is not a hook, then:

  • Check that function is using hooks implemented from other module. For example, node_save() invokes hook_node_presave(); if I would want to change the "changed" property of the node, I don't hack node_save(), but I rather implement hook_node_presave() to alter it.
  • Check that function is referenced/used from a hook; in that case, you can do something for that hook, as I previously described.

If anything I said until now doesn't apply, then it is better to create a custom module, and use the code of the other module to create it. I would also try asking a feature request for the existing module, hoping the feature is implemented.
Hacking a third-party module is never a good idea, especially because automatic updates of the module (via the Update Manager, or Drush) would not anymore possible for that module.

0
2

Most modules comes with hooks to override many of the functionalities of the module and theme functions to over ride the themes. You should try and use that in most of the cases. And avoiding hacking the code it self.

If you are absolutely sure that what you want to achieve is not something that can be done with the overrides then the next option I would choose is to create a copy of the module and give it some other name and even strip down the functions that I really dont need and create a new modules out of it.

If the changes are very little then I dont see any harm in changing the code itself but have to keep track of the changes to make it work again after an upgrade which I suppose you are already doing.

2
  • 1
    Thanks. I do use hooks when possible. The hacks I am referring to are always pretty minor, so copying a module can be more trouble than it's worth, especially for dealing with module updates.
    – Dave
    Jan 19, 2013 at 6:12
  • So I guess you are on the right track :-) Jan 19, 2013 at 6:13
1

Yeah, IMO you're "doing it wrong", but maybe your project requirements are just less than my average project requirements :) Put all your patches and module versions in a drush make file so you can always build out your platform with drush if something happens.

http://drupal.org/project/drush_make

Make files are very straightforward to write once you know the syntax.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.