Why We Hate Child Themes

(And How to Get Rid of Them)

We’ve been developing WordPress websites for nearly 20 years and in that time we’ve inherited, maintained, repaired and rebuilt websites using just about every theme you can imagine.

And if there’s one thing we’ve learnt, it’s that we really don’t like child themes.

In fact, we’ve spent years surgically removing them from clients’ websites and, despite encountering some pretty complicated examples, we’ve yet to find one we couldn’t get rid of.

Why do we dislike them so much? Well, where do we start …

The short version

We hate child themes because they introduce unnecessary complexity, slow websites down and can make updating the parent theme a nightmare. We’ve seen website owners avoid important security updates because they’re frightened of breaking their child theme.

The good news? We’ve yet to encounter a child theme we couldn’t remove. A little Additional CSS, a simple custom plugin for any PHP or JavaScript, and occasionally some work with template overrides is usually all it takes.

The result is a faster website that’s easier to maintain, without the child theme getting in the way.

What is a child theme anyway?

A WordPress child theme is a theme that inherits its design and functionality from another theme, known as the parent theme.

The idea is that you can modify the appearance and behaviour of a website without changing the original theme’s files. When the parent theme receives an update, your modifications remain safely tucked away in the child theme.

Sounds sensible, doesn’t it?

Unfortunately, we’ve found that the reality is rather different.

A child theme creates a dependency between two sets of code that need to continue working together, even as the parent theme evolves. And if the parent theme developer decides to make significant changes, the child theme may need updating too.

Sometimes those changes are minor. Sometimes the parent theme gets completely rewritten (yes, we’ve seen that happen!).

Suddenly, the thing that was supposed to make updating your website easier has become the very reason you’re frightened to update it.

Where our hatred began

Back in 2018, we launched Options for Twenty Seventeen, the first in our range of plugins that extended the functionality of WordPress’s default themes.

The plugin proved rather popular, eventually reaching over 20,000 active installations.

But we began noticing something frustrating. Some users were installing our plugin alongside child themes, then complaining when certain options didn’t work properly.

Now, our plugins were designed to extend the default parent themes. If somebody had already modified the theme’s templates, HTML, CSS or JavaScript through a child theme, how could we possibly guarantee that our options would work as intended?

Sometimes they did. Sometimes they didn’t.

And yet somehow it was our plugin that was expected to accommodate whatever changes somebody else had made to the theme!

But the compatibility problems with our plugins were only part of the story. As we began inheriting more websites built by other developers, we noticed a much bigger problem.

Child themes don’t protect against updates. They prevent them.

This is probably our biggest objection to child themes.

We’re repeatedly told that child themes are the correct way to customise a WordPress theme because they protect your changes when the parent theme is updated.

And technically, they do preserve those changes.

But preserving your modifications doesn’t guarantee they’ll remain compatible with the updated parent theme.

We’ve encountered numerous websites where the parent theme hasn’t been updated for years because the website owner is worried that doing so will break the child theme.

And we’ve seen exactly that happen too. A parent theme gets updated, something changes in its HTML, CSS, JavaScript or PHP, and suddenly the child theme doesn’t work properly anymore.

The solution? Somebody needs to investigate the changes and update the child theme accordingly.

Who’s going to do that? The original developer? The website owner? Another developer who’s never seen the code before?

Often the easiest option appears to be … simply don’t update the parent theme.

And that is a terrible idea.

We’ve had clients come to us with compromised WordPress websites because their outdated parent themes contained documented security vulnerabilities.

These weren’t hypothetical risks. The websites had actually been hacked.

All because the parent theme hadn’t been kept up to date.

Now, to be clear, a child theme doesn’t technically stop you updating its parent. But if updating requires somebody to check that all the customisations still work, and nobody is willing or able to do that, the result is often the same.

No updates.

A system designed to protect your customisations has effectively discouraged the very updates your website needs.

Brilliant.

Then there’s performance

When we remove child themes, we consistently notice improvements in page rendering speed.

And it’s not particularly surprising.

Every child theme we’ve encountered has loaded its parent theme’s CSS alongside additional CSS from the child theme. Sometimes that’s one stylesheet from each. Sometimes there are considerably more.

The browser has to request and process those stylesheets, with the child’s CSS typically overriding rules from the parent.

Then there’s PHP.

WordPress loads the child theme’s functions.php, followed by the parent theme’s functions.php. That’s two files containing code that needs to be loaded and potentially executed on every request.

And WordPress also has to resolve which template files should come from the child theme and which should come from the parent.

Individually, these things might not sound particularly significant, and the overhead will vary depending on the theme. But why introduce additional work when there’s often no need for it?

We’ve removed child themes that contain nothing but an almost empty style.css file and a handful of lines in functions.php.

We’ve even encountered child themes that do absolutely nothing!

We suspect this happens because developers use pre-built child themes or plugins that automatically generate them, complete with a style.css file and the code to load it. Which makes sense if you’re expecting to put CSS customisations there, but we’ve encountered examples where nobody ever bothered to add any!

So the browser ends up requesting an additional stylesheet containing absolutely no useful CSS. 🤦‍♂️

Why?!

Our experience has been consistent: remove the unnecessary child theme, retain the required modifications and the website becomes faster.

Sometimes the difference is quite noticeable.

So how do we get rid of them?

This is the bit we actually enjoy.

Removing a child theme isn’t necessarily complicated, although some require considerably more work than others.

We normally begin by examining every file in the child theme, starting with functions.php and style.css, then working through any JavaScript, additional assets and overridden templates.

The objective is simple: work out exactly what the child theme changes, then reproduce those changes without needing the child theme.

Ideally, we’d do this on a development server. We’ve also performed these migrations on live websites where no development environment existed, making changes progressively and checking that everything still works.

We wouldn’t recommend experimenting with this on a live website without a backup and a reliable way to restore it.

1. Move the CSS into Additional CSS

This is normally the easiest part.

We take the CSS from the child theme and move it into Customizer > Additional CSS, which has been available in WordPress since version 4.7.

We then check that the website looks and behaves exactly as it did before, removing the migrated CSS from the child theme once we’re satisfied.

Why is this better?

For a start, WordPress provides an interface for editing and previewing the CSS without needing FTP, SSH or access to the theme files.

The CSS is stored in WordPress rather than being buried inside a child theme’s stylesheet, and it’s preserved when the parent theme is updated.

And we no longer need the child theme’s additional stylesheet requests.

There is one important detail to remember. WordPress stores Additional CSS separately from ordinary Customizer settings, using the custom_css post type, and associates it with the active theme.

So when we eventually switch to the parent theme, we make sure the CSS is copied into the parent’s Additional CSS section too. Otherwise, those styles won’t automatically follow us across.

Simple.

2. Move PHP functionality into a custom plugin

Next, we look at functions.php.

Sometimes there’s a single function in there. Sometimes there’s rather more.

Either way, we move the required functionality into a small custom plugin.

There’s no need for an elaborate framework. Often the plugin looks remarkably similar to the original functions.php, with the appropriate plugin header added and any theme-specific paths or hooks adjusted.

The important difference is that the plugin is independent of the active theme.

That makes it considerably easier to identify and resolve problems.

For example, if we suspect some custom functionality is causing an issue, we can simply deactivate the plugin and see whether the problem disappears.

Try doing that with a child theme without changing the active theme!

Obviously, we check that the code works correctly from its new location. Some functionality may need its hooks or execution order adjusted, particularly where it originally relied on the parent theme having already loaded.

But in our experience, everything we’ve needed to move has been achievable.

And if the parent theme gets updated, our custom plugin remains separate.

3. Move JavaScript into the plugin too

If the child theme contains JavaScript files, we move those into the custom plugin and enqueue them using WordPress’s normal script-loading functions.

Again, we check that everything behaves as expected and adjust file paths or dependencies where necessary.

No additional theme required.

4. Deal with any overridden templates

This is where things can become a little more interesting.

Some child themes contain replacement template files, occasionally modifying large portions of the parent theme.

But sometimes the actual modifications are remarkably small. Perhaps a developer has copied an entire template simply to remove a bit of HTML or change the position of an element.

In cases like that, we can often achieve the same result with a little CSS or JavaScript, or by using an existing WordPress hook.

If the replacement template really is necessary, we can move it into a /templates/ directory in our custom plugin and use the template_include filter to select it when required.

For example, we might use conditions such as is_page() or is_singular() to determine when a particular PHP template should be loaded.

There are exceptions, of course. WooCommerce has its own template-loading mechanisms, and block themes use a different templating system. The correct approach depends on what we’re replacing.

We also need to make sure any images, scripts or other assets referenced by the original templates are moved or have their paths updated.

It’s sometimes fiddly, but we’ve yet to encounter a template override that couldn’t be dealt with.

And yes, parent theme updates can still affect our customisations. If a theme update changes something our modifications depend upon, we’ll need to investigate and fix it.

The difference is that those modifications are now easier to identify and aren’t tied to an entire child theme.

5. Transfer the Customizer settings

There’s one final problem to solve before we can activate the parent theme.

WordPress stores Customizer settings against the active theme. That means settings belonging to a child theme aren’t necessarily available when you switch to its parent.

Fortunately, we’ve got a plugin for that too!

Our free Reset Customizer plugin allows you to back up and restore a theme’s Customizer settings.

Here’s how we use it:

1. Install and activate Reset Customizer.
2. Go to Dashboard > Appearance > Backup Customizer.
3. Download the active child theme’s settings as a .json file.
4. Activate the parent theme.
5. Return to Appearance > Backup Customizer and use the Restore option to import the settings into the parent theme.

The plugin also creates a backup of the parent theme’s previous settings, just in case.

Don’t forget the Additional CSS! As we’ve mentioned, WordPress stores this separately in the custom_css post type, so we copy it into the parent’s Additional CSS section rather than assuming it will be included in the Customizer settings backup.

Once we’ve confirmed that the website looks and behaves exactly as it did before, we can remove the child theme.

Bosh. Done.

No more child theme.

But isn’t a child theme supposed to be best practice?

That’s what we’ve been told for years.

And WordPress still officially supports and documents child themes, so we’re certainly not suggesting they’re broken or that developers shouldn’t be allowed to use them.

But we’d question whether the traditional advice is still appropriate for most websites.

If you need to change some CSS, WordPress already provides Additional CSS.

If you need to add functionality, why not create a plugin?

If you need to modify the appearance or templates of a modern block theme, the Site Editor can already do an enormous amount without writing any code at all.

And if you need something more ambitious, WordPress provides hooks and APIs that allow you to achieve an awful lot without modifying theme files.

So what’s the child theme actually for?

We’ve been building websites exclusively with WordPress’s default themes for years, and we haven’t needed to create a child theme in all that time.

Our designers create the designs they want. We make WordPress do what they want.

Sometimes that requires a bit of creative thinking, CSS, PHP or JavaScript, but we’ve yet to encounter a design we couldn’t implement.

More importantly, our clients’ websites aren’t dependent on a child theme remaining compatible with its parent.

What if you already have a child theme?

Don’t panic. We’re not suggesting that every website using a child theme is about to break or get hacked.

But we would recommend taking a good look at what yours actually does.

You might discover that it’s making a handful of changes that could easily be transferred into Additional CSS or a small plugin.

Or you might discover that somebody has built practically the entire website inside it.

We’ve encountered both.

Either way, we’d strongly recommend making sure the parent theme is kept up to date and that somebody understands how the child theme might be affected by future changes.

And if you’d rather get rid of it altogether, that’s something we regularly do for clients. It’s often considerably less expensive than people imagine.

Good riddance to child themes?

We’ve been removing child themes from WordPress websites for years, and our opinion hasn’t changed.

We think they introduce unnecessary complexity, create maintenance headaches and, in our experience, discourage website owners from applying important theme updates.

We’ve also consistently found that removing them improves performance.

We know plenty of WordPress developers disagree with us, and that’s fine. If child themes work for you and your clients, carry on using them.

But we’re not going back.

In our previous article about why WordPress themes are dead, we explained why we believe modern WordPress has made the traditional concept of choosing a theme for its design increasingly irrelevant.

Child themes are another part of that old approach we think WordPress has outgrown.

We’ve never met one we couldn’t surgically remove.

And we can’t think of a good reason to stop trying.

What do you think? Are child themes still an essential part of WordPress development, or have they had their day? We’d be interested to hear your thoughts in the comments.