What are the best practices when it comes to modifying some of the core modules directly to get a desired functionality?

I recently had to add and modify some functionality in the contact module but I would have preferred to make a local overwrite instance or something where I could place modified code and not affect the core installation. Obviously for less breakage during updates. We ended making some custom modules for other functionality but wasn't sure how to handle modifications to core modules, especially when you can't find a hook to program for.

Comments

jinside’s picture

Personally I would look at api.drupal.org first and search the forums to see if your modification might have been handled before. If I do not see what I need I would make a patch. I also would document the use case, submit an issue to the module issue queue, and attach the patch. Let others review the patch and iron out any details.. who knows it might become part of core :)

saborchulo’s picture

Yea the api site is attatched to me at the hip. These modifications are more site specific/client specific and add functionality to the existing code base, based on the client's needs. Not really an issue or to make something work better like creating a patch would usually address.

More like I have something a client wants to accomplish based on his business needs and it requires some code addition or rework to an existing core module, what would be the best approach looking forward when it comes time to update or migrate.

What I went with was creating another module that stated its dependency on a core module and put all the new code in there. I has worked pretty well but was wondering if there was a better/recommended way to do it.

anantagati’s picture

Angie Byron wrote nice article called Strategies for Patch Management (http://www.lullabot.com/articles/strategies_for_patch_management)

She describes simple way how to keep patches manageable. (http://www.lullabot.com/articles/strategies_for_patch_management#managable)