Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

Why?

Sometimes an easy fix to altering the behavior of WordPress itself or a plugin could be to alter the files of the plugin or WordPress directly. When coming up with such an idea, the usual response is:

Don't hack core.

Why is it generally a bad idea to change core files?

Consider?

Sometimes, however, things that can be critical for a site is simply impossible to do, in a nice way without altering core files. When in such a situation, what do you need to be aware of, before you go ahead and starting hacking core?

How?

You have considered all the options, but the only solution is hacking core files. How should you go about doing this? How will having an altered core, influence workflows, like updating?

share|improve this question
    
I strongly disagree with any recommendations to hack core as I have yet to find a single thing I couldn't work around. The only people who have any business hacking core for a production site are those who have absolutely no need to read anything on this topic as they are probably already on the WordPress core team. Explaining to people how to do it simply gives 99 of 100 people who definitely shouldn't be doing it a way to rationalize their decisions. And I'd really hate to see that enabled here. JMTCW. –  MikeSchinkel Sep 10 '10 at 9:12
    
As a follow up, here's an example of a question that was first answers "It's not possible" and I answered with an example showing how: wordpress.stackexchange.com/questions/972/#984 There is (almost always) a way to do it w/o hacking core. –  MikeSchinkel Sep 10 '10 at 9:17
2  
If you change the core, you'll have to re-do the changes after each single time you upgrade, and you'll make your installation non-standard so it's harder for people to help you. Just create a plugin, a widget, a template, a hook, or any of the many methods wordpress provides you to not have to change the core. –  Wadih M. Sep 10 '10 at 16:06
    
Wadih is correct. I’ve made changes to some of the core files to fix/improve/customize various things and I’ve always been frustrated when upgrading because I have to check for changes and apply my patches to the new files. This is even more frustrating when the new files are too dissimilar from the old ones and the locations of the changes are no longer obvious (or even present at all). –  Synetech Apr 7 '12 at 1:15
    
For the record, the reason that people make changes to the core instead of using the “many methods WP provides you with” is that it’s much easier to directly edit them than to learn about the hooks and such. As an example, think about how it is much easier to directly edit a function in a C/C++ program than to figure out how to use any callbacks and APIs it may provide (along with any limitations that imposes). –  Synetech Apr 7 '12 at 1:16
show 7 more comments

3 Answers 3

up vote 12 down vote accepted

If you must hack core, consider doing so in a way that makes it extensible for others.

Add an Action Hook

Nine times out of ten, you could do what it is you wanted if only there was an extra do_action call in a specific file. In that case, add the action, document it, and submit a patch via Trac. If there's a good reason for your patch (i.e. you're not the only one who would ever use it) then you can probably get it added to core.

Next, build a custom plug-in (you don't have to release/distribute it!) that ties in to this new hook and performs whatever function you need it to do.

Refactor a core file

Other times, you might just need a piece of code to behave differently. Pass a variable by reference, for example, or return a value rather than echo it. Take some time to sit down and refactor the code so it does what you need it to do ... then submit a patch via Trac so the rest of us can benefit from your work.


Do you see a theme developing here? Hacking core isn't necessarily a no-no ... just something most developers will highly discourage for new users or novice programmers (if you're asking us how to do something, we'll suggest a plug-in every time before even considering to suggest you hack core).

Hacking core is the way WordPress develops and evolves, but it's dangerous for someone just learning PHP or with no experience working with WP files. Please start with a plug-in before touching core - if you break a plug-in you can uninstall it quickly (removing via FTP if necessary) ... but if you break core, bad things can happen to your site and potentially to your database as well.

But if you are in a situation where a core hack is unavoidable, then make the change. Also, publish your change in a prominent location (if your blog is highly visible, that might be sufficient ... but I suggest Trac because that's how community changes get pulled into the next release). Your change might be the magic bullet that could fix problems in a hundred different sites ... so contribute back to the community that helped you build your site.

If the change gets committed, then your hack becomes part of core and you won't need to worry about it in the future. If it doesn't, at least you have detailed documentation on how to re-implement the hack after you upgrade WP in 3 months.

share|improve this answer
    
Much better wording then mine :) –  hakre Sep 10 '10 at 16:44
add comment

The issues are:

  1. Every time you do an update of the core (e.g. because of a security fix, etc), you will have to manually update it, instead of running the automatic updater.
    If you wish to do this, then make life easier for yourself:
    • mark every change with a common marker (.e.g // PATCH START and // PATCH END)
    • use a tool like WinMerge to compare the existing source with the new source, and copy across changes where necesary.
    • you will have to watch out in case the area of code that you're copying across has changed, and make the appropriate changes to your patches
    • be aware that this is a 'never-ending' job, taking up billable time, unless you can rebill your client for it.
  2. You may cause incompatibility issues with plugins that expect the core to function in a certain way - this will require extra testing

Sometimes this is 100% unavoidable, but I nearly always can come up with another way of achieving things, or altering spec due to the likely cost of time spent doing this. It's just a maintenance nightmare, and many people go for hacking core, instead of looking for the proper solution.

share|improve this answer
add comment

Don't hack core.

Well that's because it's a suggestion for the first level, inexperienced users. Those hacking core would break their installation, they can not ensure that their changes persist an update etc. .

Sure, hack core!

Sure you can actually hack core, for example by using a version management system like SVN. It helps you to keep your own changes on core code into line with project updates. It also helps to create patches for Wordpress and send them to the project.

Hacking core is infact making Wordpress evolve.

Considerations

If you don't want to install a full SVN and you still know which (some) files you've changed, you can use more low-level tools like Diff/Merge (for win: WinMerge) or editors with compare capabilities (e.g. Notepad++ with Compare Plugin). On Linux you can easily install command-line utilities that do the same. The Geany editor comes with a nice shell integration btw. .

I prefer Eclipse PDT for the hard jobs. But that's not for the quick edit or hack.

So I would say, if you're using the right tools and you want to take care hacking the core is the way to go. If you're hacking something together that's left over on some other Noob users server (yup, Wordpress is pretty popular), just provide a plugin that can be thrown out easily if it breaks something.

share|improve this answer
    
Hacking core is NEVER a good solution in the long run. NEVER. –  Fredy31 Sep 2 '12 at 16:31
    
@Fredy31; It's the only way to keep your wordpress installation up-to-date, working and secure. Also the "long run" you speak about here is really long if it takes two years and longer between providing a patch to Wordpress and then getting it in. Even longer for reporting an issue with no patch. Take care. –  hakre May 23 '13 at 9:58
1  
Obviously hacking core is troublesome, but I find the resistance and vitriol to it here surprising. In pretty much every other area of FOSS, forking is actively encouraged. Why is customizing WordPress so anathema? I’ve seen countless other projects do exactly as hakre suggested by using a RCS to create a modified version of a program while keeping up to date with the trunk. +1 for giving the obvious warning but telling the truth that it is indeed possible and giving the obvious suggestion of how it can be done with the least amount of difficulty. –  Synetech Jul 27 '13 at 1:36
    
Oh, and I just remembered that child themes do exactly this! When you create a child-theme, you are essentially forking the parent and whenever the parent is updated, you have to manually copy any changes to the child. So this hatred of modifying core is inconsistent with another, identical WordPress behavior that accepted. –  Synetech Jul 27 '13 at 16:43
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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