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?


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?


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?

  • 2
    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. Commented Sep 10, 2010 at 9:12
  • 1
    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. Commented Sep 10, 2010 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.
    Commented Sep 10, 2010 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
    Commented Apr 7, 2012 at 1:15
  • 1
    It’s as I feared; sometimes when there are no refined hooks (such as modifying My Sites), the only hooks that work for the buffered-output trick are admin_body_class and admin_footer which means capturing the entire page. I just tried it and there is >2MB of content that has to be searched for the relevant section, then parsed and modified before outputting. Or, I can add one line of code to the right part of my-sites.php and use a diff tool to apply the patch after updates (assuming it was modified at all). It’s really hard to make a case against modifying core in scenarios like this.
    – Synetech
    Commented Jul 28, 2013 at 18:16

3 Answers 3


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.

  • Much better wording then mine :)
    – hakre
    Commented Sep 10, 2010 at 16:44

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.


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.

  • Hacking core is NEVER a good solution in the long run. NEVER.
    – Fredy31
    Commented Sep 2, 2012 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
    Commented May 23, 2013 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
    Commented Jul 27, 2013 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
    Commented Jul 27, 2013 at 16:43

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.