Wordpress - Modifying WordPress core files

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.

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.

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.