Why you shouldn’t ever edit the WordPress Core

Why you shouldn’t ever edit the WordPress Core

Ben Stevinson's Layout avatar

You know you can customize and shape WordPress to fit any look or need imaginable, and people have built millions of incredibly unique websites around it. Plugins and themes allow WordPress developers to extend the core functionality and turn it into something powerful and individual.

No matter how a WordPress installation is configured or customized, however, they all have one thing in common: They’re all built on top of the WordPress core.

The core is the cornerstone behind WordPress. It’s a piece of work eleven years and several major release versions in the making. Every WordPress site is powered by the same core code, no matter how differently they operate or look. Let’s peek behind the curtain of the WordPress core and take a look at its biggest cardinal rule — why you should never ever edit the core. Then, on a less strict note, we’ll get into how it’s updated and released, as well as how to get involved in making it better.

Don’t edit the core!

The WordPress core has one big, huge, major, important rule: Never edit core files. Ever. Even core developers don’t mess around with the core on production servers. Here’s why.

When the WordPress core gets updated, it overwrites the core installation with any new updates included in the release. If the core has been chopped up and modified beforehand, it’ll wipe out those changes. That means big sections of the installation will just stop working.

Worse, modifying the core can have all kinds of unintended consequences, like preventing updates from working correctly, further screwing up an installation. But wait! There’s more! Even worse than that is the potential to introduce unintended security vulnerabilities. Messing with core files could easily introduce a hole in WordPress’ security, allowing hackers to take over a site.

never-edit-wordpress-core-1 The WordPress Core is the foundation of all WordPress installations. Image courtesy SuperFamous

Understand the core’s file structure

Now that we’ve hammered home why you shouldn’t edit core files, let’s take a quick nerd moment to look through their structure. Here’s what a base directory looks like:


That’s the WordPress Core in its entirety. The folders wp-admin, wp-content, and wp-includes have the bulk of the code that powers WordPress, namely the back-end code that powers the WordPress dashboard, for example.

Familiarize yourself with the core’s release cycle

So if we aren’t supposed to edit the core, who is? Let’s talk about the people who implement features and push out updates. Lead developers, core developers, and guest committers, many of whom work for WordPress’ parent company Automattic, all work together to maintain the WordPress core. Some core developers and guest committers, however, contribute either on their own accord or because they’re associated with another WordPress related company. Because WordPress is fully open source, anyone is free to contribute documentation and code to the codebase. However, commit access on the core is limited, and any new contributions go through a code review process.

WordPress developers utilize a formalized release cycle for major releases, and according to the core handbook, release cycles are broken down into five phases:

1. Planning and securing team leads
Discussions and planning take place regarding the features and fixes that need to be made, and developers are assigned different tasks and/or take the lead on specific feature implementations.

2. Development work begins
Actual feature implementation and bugfixes begin. At this point, implementing actual code and performing automated tests is done by developers and team/project leads coordinate the arrangement.

3. Beta testing
After development work has made significant progress, the codebase is released to beta testers and anyone who is interested in living on the bleeding edge. Users discover and report bugs and other inconsistencies with the new code, and developers make fixes accordingly. At this point, no new features are added.

4. Release candidate
Once everything is locked in, final tests are run on the codebase to ensure its stability, security, and implementation.

5. Launch
The release is launched to the public and available on every WordPress admin console for downloading.

This phase is repeated for each release cycle, with major point releases being published two or three times a year. There are also usually several security releases, which come in the form of sub points, like 4.0.1. 4.0.1 is a fix for some security vulnerabilities discovered in version 4.0 that needed to be repaired. Security releases do not include any new features — they just focus on hardening the security of WordPress.

Update to decrease your site’s vulnerability

It’s always a good idea to update to the latest available version of WordPress. Also, make sure to use themes and plugins that aren’t version dependent or specific. WordPress is an incredibly popular platform, which makes it a prime target for hackers. Hackers give WordPress a lot of extra scrutiny because of how widely it’s used.

WordPress plugin developers and core developers work hard to keep the platform as secure as possible and to immediately release patches for any discovered vulnerabilities. That’s why keeping WordPress updated is so important — you’ll stay ahead of the hackers while getting to use all of the great new features introduced by developers. You can update the core via the WordPress admin panel manually, although hosts like Flywheel will update it for you automatically, keeping your sites patched and secure.

never-edit-wordpress-core-2 The WordPress Core and Codex are supported by many members of the community. Image courtesy SuperFamous

Get involved

Getting involved with an open-source project can be an immensely rewarding experience, and your contributions have an opportunity to impact hundreds or even thousands of people. For WordPress specifically, there’s a great deal of work to do for developers and nondevelopers alike. It’s always great to write code and contribute to the functionality of your favorite open-source projects, but WordPress also requires a great deal of technical documentation and copy editing as well.

WordPress.org maintains the Codex, which is a large repository of information surrounding WordPress, including information such as technical documentations, How Tos, and introductions to WordPress. The Codex has a section dedicated to contributors and discusses in detail how you can get involved in valuable, important work that doesn’t involve writing and committing code.

If you’re a developer and getting involved in core code is more of your thing, an awesome way to start contributing is by submitting bug fixes. The WordPress core team has put together a great guide on finding bugs to fix and how to go about fixing them.

Comments ( 2 )

  1. Anthony Iacono

    May 19, 2018

    My team and I have released a plugin that allows you to modify core files :) Without the guilt! It is called WordPatch, you should give it a shot :) I would be happy to show you how to use it. It allows you to make patches that are automatically applied to core, plugin, and theme code when updates for WordPress occur. This means you never have to suffer with having out of date versions of stuff!

  2. Allen

    October 20, 2015

    "Don’t edit the core!
    The WordPress core has one big, huge, major, important rule: Never edit core files. Ever. Even core developers don’t mess around with the core on production servers."

    Thanks for your post, but please indulge an old man who wants to go on a rant concerning 'coreism'.

    This article needs to define "Production" Small time vs. big-time, client security risk levels (like PCI), simple backups or mirrors, single DB, clustered, or sharded... See what I mean? Additionally, you do not mention Plugin hell --often orders of magnitude worse that a simple tweaking and an occasional update merger! Another thing, most of MY core mods are never touched by updates and only few have added new features that I already created and that were dismissed for months or years!!!!

    Your view on updating is simply wrong because CAREFUL version mergers --done correctly-- are the only true 0-risk safe way to modify a high risk production server going from beta to production ---NOT some @%$#*&^ AUTOMATED stupid half brain dead (S)FTP overwrite. ONLY Ding-Dong wanna-be's do that.

    This part is really wrong. It's the attitude that core code is like the Bishop of Rome. My View is that WordPress.org may maintain the Codex, but I maintain my own damn code! NO WordPress "core developer" wants to tell me how high to jump, or anything else -just the opposite- WordPress opening statements and philosophy invite innovation!

    Come on Man, core dev's become core dev's by tinkering and smashing and gluing and gutting PHP. That's why they are called CORE developers, Duhhh. And we want to try and break PHP, especially WP's core PHP. Everyone, get into the melee. WP is finding NEW upper limits, and that's the fun stuff! Core is like downhill mountain biking, not at all timid.

    Core developers are not coding gods, just a great bunch of folks who are turned into gods by "don't touch core" scare tactics invented by money hungry WordPress plugin jockeys (no insult intended guys, we all have to make a living). Please, you should link or embed the WP bill of rights located at https://wordpress.org/about/philosophy

    The freedom to run the program, for any purpose.
    The freedom to study how the program works, and CHANGE IT TO MAKE IT DO WHAT YOU WISH.
    The freedom to redistribute.
    The freedom to distribute copies of YOUR MODIFIED VERSIONS to others.

    WHY EVEN HAVE OPEN SOURCE SOFT AT ALL- except to invite a little experimentation? For instance, I just finished a little(big) mod that totally changes the thumbnail system and how it works IN CORE, and that my friend was not possible without messing with the beating heart of WP.
    What I did was totally impossible without modifying our sacrosanct core. In the end, my client was all smiles and giggly, and I have guaranteed future work. (_btw_they_read_the_disclaimer) All automatic updates are disabled and EVERYTHING flows through a Mercurial that I (me) manage, and now I have a happy as hell client. Their site is lean, mean, super fast, and hosting 100,000 posts, 12 full-time authors (growing), and over half-million externally hosted images.
    (original images are cloud hosted, high active thumbs are mem-cached and CDN'd, standard draft post attachments stay local until published, Nginx does all image pre-process and load balancing, admin uses memcached objects on low latency CDN. All new thumbs are generated on the fly and only when needed by theme or admin. Basic themes need not apply for residency on this machine and no image server rip-offs noooo! Modding core saved me time and trouble and because I work alone I pocket the difference.)*

    Try that with a stock engine in a Ford Pinto and you could not even pull the first hill! You should be experimenting and encourage experimentation, especially you young folks (I'm getting old'n slow). If you have success, send in your idea to core, and who knows, it may just get adopted. Yes, YOU get the credit and a really good resume reference. Get out of your safe little tiny old box and discover the real power inherent in WP4+. Talking about boxes, If WP doesn't get with it, NodeJS will eat us all up. Lets hope PHP 7 does the trick. I have my doubts.

    I would like to thank you for your article, it stirred in me more passion than I have felt in a long time. BTY I like your open encouragement for people to do bug investigations requiring bottles of xdebug and Visine. One of my recent new projects involved a bug fix that was adopted at WP core and I discovered it because of one of my core hack attacks!. My current bone-headed modify-core project is recreating some middle-ware to do some real-time data push to a client using ReThinkDB. By the time I am done I will be very tired looking and really old --and wondering why I did not spend more time watching sleepy Dave Crockford videos. PS I was inspired into a code induced hallucination by the prime hackers over at http://rethinkdb.com/blog/rethinkdb-a-new-kind-of-database/.

Join the discussion