16

I couldn't believe that this question hasn't already been answered on this site, but I didn't find it when I searched, so...

Why is it such a bad idea crime against nature to hack core?

  • Is it really that great to be able to upgrade your core version? Most of my sites end up having horribly out of date cores anyway, so why bother?
  • Even if it is so bad for site owners, why does the community care so much? Why is it referred to as "killing kittens"? Isn't that rather hyperbolic?
  • Hacking core is so easy, don't we like taking the easier route to a problems' solution?
  • Aren't there problems that can only be solved by hacking core? What then?
Improve this question
11
  • i think if you are creating small web site by yourself without team, maybe you can hack core if u need, but why do you need that? i believe that you can solve any problem without hacking core
    – Petro Popelyshko
    Commented Jan 30, 2013 at 16:47
  • 4
    @beth I am actually pretty serious about this. The patches necessary for secure pages in D7 have been hung up for over year now because problems with the unit tests. As far as I can remember there is still a bug in D6 with menu machine name lengths. None of these have shown any headway of actually getting committed.
    – mpdonadio ♦
    Commented Jan 30, 2013 at 17:56
  • 3
    @MPD That's a great example actually, I know a fair few people who are crying out for those patches to make it in (me included). Kittens aside, obviously sometimes you absolutely have to patch core and there's nothing wrong with that as long as those patches are well documented and available to everyone on the team. It also speaks to the importance of having a solid deployment process, one that doesn't blindly perform updates without semi-manual checks happening before hand. On my (small) team we just document what's changed and make sure everyone knows to check it before updating
    – Clive ♦
    Commented Jan 30, 2013 at 18:04
  • 3
    Apply the patch and note it in a text file that's in the root of your repository.
    – Charlie Schliesser
    Commented Jan 30, 2013 at 19:40
  • 1
    I would rephrase it to "Never hack core, unless you have a mechanism to still have your updates". This requires some thinking, and has implications on your development workflow. If you or your team are not up for this extra babysitting, don't do it.
    – donquixote
    Commented Jun 9, 2015 at 23:03

6 Answers 6

Reset to default
8

Generally speaking, there are three reasons for not altering the Drupal core code:

  • Your changes would be lost each time you update Drupal, if you don't take any necessary steps. Even in the case you create a patch for the current Drupal version you are using, the patch could not apply to the newer version, and you would need to create a patch for the new version too.

  • Security fixes apply to the Drupal core as maintained on Drupal.org, but could not apply to your hacked version. That means you should check your version is not affected by the security issue raised against Drupal core.
    In the case your hacked version introduces a different security issue, you are the only person you can find it, as you don't have the support of the security team that investigate on security flaws present in Drupal core code, and in third-party modules hosted on Drupal.org.

  • The changes you introduce could be incompatible with Drupal itself, but also with third-party modules, which are required to work with Drupal core, not with any hacked version one can create.
    Every time Drupal introduces a new feature (which still happens in Drupal 7, and in Drupal 6, although with less frequency), or a new API change, there is the chance the hacked version is incompatible with the recent changes.

That said, it is possible to create an hacked version, but that is not the task a single developer can carry, in the same way Drupal is not maintained by a single person. In fact, Pressflow is an hacked version of Drupal that has been created with performance in mind, and to resolve some performance issues a Drupal site could have.

Aren't there problems that can only be solved by hacking core? What then?

Most of the times, it is possible to alter the features/behavior without editing Drupal core code. There is always a hook that allows to change the features/behaviors Drupal has, and that is the preferred method.

Improve this answer
6
  • 4
    I may post two real world problems I have run into that may challenge the assertions in the last paragraph.
    – mpdonadio ♦
    Commented Jan 30, 2013 at 18:09
  • 3
    In the case your hacked version introduces a different security issue... I don't see this as a particularly strong argument modifying a core file versus anything else. If I am not hacking core, and instead I introduce a security issue via a module then my system will still be compromised. Compromised is compromised, it doesn't really matter if that came from me editing an existing file, or adding a new one.
    – Zoredache
    Commented Jan 31, 2013 at 0:05
  • @Zoredache If the security issue is present in your module, you can always disable it, and the rest of the site would work without security issue, even without features. If you introduce a security issue in Drupal core code, and it is not possible to simply copy back the original files because you also changed the schema of some tables used by Drupal, then that is a bigger problem.
    – avpaderno ♦
    Commented Jan 31, 2013 at 0:12
  • 2
    The statement that "there is always a hook..." is not correct. It is not entirely uncommon that there is something that is baked into drupal core that can't be worked around without hacking, and also that there are open issues for drupal with patches that have not been committed, in which case you have to patch core to address those issues.
    – rooby
    Commented Feb 2, 2013 at 1:31
  • 2
    Absolutely, but that is a simple example. In most cases there are hooks, but there are still times you need to patch core, unless you want to duplicate a lot of code and build something more custom. For example, to allow admins to properly administer unpublished books you need the patch at drupal.org/node/520786 or if you want drupal's default SQL searching to match partial words (including the views search filter) you need the patch at drupal.org/node/498752#comment-6001310 - working around these without hacking core is not feasible.
    – rooby
    Commented Feb 2, 2013 at 13:00
13

I could write a massive answer here, but I'm just gonna post this link: Never hack core!

The main reason I guess is that if you hack core to do something you need, and then update it...BANG! Your changes are gone. Lost. You could then try and roll back the code from your VCS, but seeing as you can't roll back database upgrades from Drupal core - you're looking at restoring all code from VCS, and then restoring databases from your backups. All the time you're trying to roll back your code, you'll probably then notice that your last pre-update database backup failed, and you'll swear more than you've ever sworn before.

Also - most importantly - if you hack core, then Dries and Webchick both kill a kitten :-o

Improve this answer
2
  • 4
    What, they kill the kitten? I thought it was God.. My world is falling in around itself...
    – Clive ♦
    Commented Jan 30, 2013 at 17:44
  • 1
    You know, I wrote my comment above before I saw kittens mentioned here.
    – mpdonadio ♦
    Commented Jan 30, 2013 at 17:51
12

"What can not hacking core do for me, the developer?"

  • Your site can be upgraded for security releases
  • Your site can be upgraded to fix annoying bugs in core
  • Your site can be upgraded to support new modules
  • Your bug reports and support requests on core and contrib will be able to be responded to
  • You want to use a supported CMS, that's why you chose Drupal. When you hack core, in the words of webchick, "If you hack core, congratulations! You've created your own fork of Drupal, and now you and you alone are responsible for maintaining it!"

"What can not hacking core do for my client?"

  • Your site can be maintained by someone else after you fire your client/win the lottery/get hit by a bus

"What can not hacking core do for my community?"

  • Your bug reports will actually provide useful info for the maintainer of core or contrib modules.
  • If you find a legit bug in core that must be patched, the line between 'hacking core' and 'becoming a core contributor' is as fine as simply diff'ing your changes and uploading them as a patch into a relevant d.o issue. Violá! Core is better for your efforts, and your name is associated with giving back code to the community.

Everyone's a winner when you don't hack core!

Improve this answer
2
  • 3
    Not all patches get committed to core, even the simple ones.
    – mpdonadio ♦
    Commented Jan 30, 2013 at 17:59
  • 1
    True, but by uploading it, you at least have a record of the patch, what it does, possibly some versions that were improved by others, and the ability to download it and apply it to your project again if you have an update that overwrites your change. And frequently a reason why it wasn't committed, and alternative suggestions. All for free.
    – beth
    Commented Jan 30, 2013 at 18:04
5

I am currently working on a hacked core website. I have difficulties finding how something as simple as font is being set up. I also spend few days fixing a bug that was introduced by the core hack. I found it by searching for a string in the whole drupal code.

If you don't follow the standard structure of programming in drupal then how can someone else find and edit the changes you introduce? This is especially painfull because in drupal every single php file can implement a hook. Try finding out which one is causing problems.

Improve this answer
4
  • 4
    This. If you inherit a site that was built on any given framework, and then discover that the framework was hacked and thus the documentation for that framework is potentially irrelevant, you're in a world of pain. (in addition to all of the other aforementioned reasons above...)
    – Charlie Schliesser
    Commented Jan 30, 2013 at 17:19
  • 5
    Bet you wish you'd heard about drupal.org/project/hacked earlier?
    – Chris Burgess
    Commented Jan 30, 2013 at 21:33
  • Looks good Chris. I'll definitely have a look.
    – Pawel G
    Commented Jan 31, 2013 at 8:31
  • A decent Source control system should be able to tell you what has changed and show all modifications to core. Searching for strings in a codebase should be standard part of your debugging toolkit in php.
    – Toby Allen
    Commented Nov 1, 2014 at 12:34
4

"Aren't there problems that can only be solved by hacking core? What then?"

To answer this question, yes, there are sometimes problems you have to overcome that mean you have to hack core (or a contrib module).

In this case I believe it is ok to hack as long as you put lots of comments in your hacked code and document everything you change.

For example, for any core or contrib change I make I create a patch. If it is generic and useful to other people I submit it to drupal.org in an issue, otherwise it is for my own use.

I then commit the patch file to my version control along with the code change.

This means that I can see by looking for patch files if something has been hacked.

In addition to that, I also add a list of hacks to the developer documentation for the site (you really should have developer documentation for the sake of others that might work on the site and for yourself when you inevitibly forget things).

In this hacks documentation I list each hack with what the hack does and why, modules/files affected, the name of the patch file that contains the hack code, and a link to a related drupal.org issue if there is one (almost always in my case there is).

Then you and whoever else works on the site in future has a full list of hacks and doesn't have to worry about accidentally breaking something with an update.

Then for the update process I check my list of hacks and have a quick look for patch files in all the modules I am updating. If there is a hack and it has a drupal.org issue, I check the issue to see if the latest version has the patch included, in which case I blow away the hack with the update and remove it from my list of hacks (make sure by looking at the drupal.org commit messages that what was committed was the same as the version of the patch you are using, or at least in functionally the same).

If the patch was not committed, all I have to do it update the modules and reapply the patches. In a lot of cases the patches will still apply cleanly and the process is easy, but sometimes you have to reroll the patches for the new version and then commit the new version of the patch to your local repository (along with posting it to the relevant drupal.org issue where applicable).

Another thing I like to do if I have more substantial patches or patches that interact with core fucntionality of a module (or just custom modules that extend on top of a drupal.org module), is to check the release notes of the updated module (that means all version in between your current version and the version you are updating to) and make sure there is nothing in there that is likely to break your code. Note: A lot of module maintainers are good these days with giving complete release notes but there are still a lot that do rubbish release notes. In this case in some cases I go through all the commit messages since my current version (this is usually only in cases where I have complex code that interacts deeply with another module). Note: In this case it might be easier to do a diff between the version you have and the new version to see what has changed.

Then, after updating (on a development copy of the site), test thoroughly. You will eventually learn what thoroughly means after a few bugs slip through.

Then when it has been tested sufficiently, upgrade the live site or push your local updates up or whatever your deployment process might be.

The reason why everyone says don't do it, even if it is easier: Because most people don't have a system like I have outlined, so when it comes time to do updates, or the site is handed to someone else to work on, it becomes a nightmare and a lot of time (sometimes an enormous amount of time) has to be spent solving bugs and tracking down hacks and working out why they are there, etc.

If you ever inherit a site like that you will fully understand :)

Improve this answer
0
1

If you earn a living from installing and creating Drupal websites, then it's necessary to keep them up to date. If most of your sites end up being horribly out of date, then you are not professional.

Improve this answer

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.