Every where you read on Drupal.org, Professional Drupal Development book, IRC ect, all of us who know Drupal intimately say "Not to hack core" files. I include core module files with that statement. Here are a couple of reasons why:

  • there should be no reason to hack it. Almost all output from core files can be overriden with the use of theme functions within tempate.php. By changing the output from the theme function you can bypass hacking core files
  • when it comes time to update, chances are you are going to forget about the small changes you made to that one core module file and overwrite those changes. That can cause some headaches if no backups are available.

But what do you do if there are no theme functions to override within a certain core module file? You want to play it safe and not risk writing over your hack(s). For example, the blog.module file, it has no theme overrides in Drupal 5. I have a client who wants to rid the "Post new blog entry" link when visiting your own blog page. Sure you could hide it in CSS but that is dirty. You could do a PHP str_replace() too. Even more ugly.

Here is what you can do. Create a "custom" directory inside the core "modules" directory. Then move the core module you want to hack (it's folder with module files) to the "custom" directory. Then do your hacking. Be sure to visit admin/build/modules, scroll down and click on submit - to reset the module path in the system table. Now when you do an upgrade you won't write over your hacks.

ipsita

03.15.2008

It's a bit unclear to me. After moving the core module to /modules/custom/ , should I change the code in core module file?? I mean manipulating the ****.module file directly?
Please clarify.

elvis

03.16.2008

Hello ipsita, no you don't have to. Did you run into problems? If so share what version of Drupal you are working with. Also, be sure to reload the site.com/admin/build/modules url, as it will pickup the new path to modules/custom/modulename

elvis

03.16.2008

Another way to do this is through multisite method. I prefer my method simply because it keeps the custom core modules in a the core modules directory.

The alternative, to use the multisite method and put the core modules inside sites/all/modules/custom_core/coreModuleName

The effort here is to keep core modules organized and seperate. Thanks to Boris for sharing the multisite method.

Name
E-mail (Kept Private)
CAPTCHA
Are you human?
Image CAPTCHA