One way to override Drupal core modules - safely

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.

Rob

10.02.2008

Why wouldn't you put your hacked modules in sites/all/modules to conform with Drupal coding standards?

elvis

10.03.2008

@Rob, you are conforming to Drupal standards. Why would you hack a module then update it later and have to your hacked overwritten, or to have to pull your hack into the new updates?

If you create your own module and override other modules, which can be done for the most part, you don't have to worry so much about updates breaking your site.

Modules go in:
sites/all/modules

Custom modules and overrides can go in:
sites/all/modules/custom

In my opinion this is really about good practices, being organized and efficient.

Rob

10.03.2008

@elvis

Please pardon my informality. I didn't literally mean hack the core modules. I was referring to the custom module described in the article. I was just think that instead of putting the module in the core module directory where it cold possibly be overwritten or deleted that it should go in sites/all/modules with the rest of the contributed modules.

Rob

10.03.2008

After rereading the article, I may have misunderstood the point anyways.

Putu

07.14.2009

I've tried to move my hacked core module to /modules/custom/myhackedmodule but the module isn't changging at all.. Actually i only add some text in the template.php, but it still remain the same as the default core module. I've also tried to reinstall that module, no error but nothing's changing.. help me pls..

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