Do You Need a WordPress Child Theme?

Somebody changed your theme's files. Months later the theme updated, and the change went with it. That is the entire argument for child themes, it is a real thing that happens, and it is also the reason people build one when a two minute alternative would have done. The useful question is not whether child themes are good. It is whether the change you are making needs one.

What an update actually destroys

A theme update replaces the theme's folder. Every file in it goes back to the vendor's version, including any file somebody edited.

That is narrower than it sounds, and the confusion costs people real money in unnecessary work. Almost nothing you do through the WordPress admin lives in that folder.

One row loses data. If nothing you have done falls into that row, a child theme solves a problem you do not have.

When you do not need one

Most sites, most of the time. Three cases cover nearly all of it.

You want to change how something looks

Use Appearance, then Customise, then Additional CSS. On a block theme, use the Site Editor's styles panel. Both are stored in the database, both survive updates, and neither requires a single file.

This covers colours, spacing, hiding an element, changing a font size. Our guide to changing fonts in WordPress works entirely this way.

You want to add a small piece of PHP

A code snippets plugin holds it, keeps it out of the theme, and gives you a switch to turn it off when it breaks something. That last part matters more than it sounds: a broken snippet in a child theme's functions.php takes the site down and you fix it over FTP, while a broken snippet in a plugin can usually be disabled from the dashboard.

You are on a block theme and using the Site Editor

This is the part the older guides have not caught up with. On a block theme, everything you change in the Site Editor is saved to the database as a layer sitting above the theme. The Theme Handbook describes it as working like a grandchild theme, with the difference that it is stored in the database rather than the filesystem.

You already have an update-safe customisation layer. Adding a child theme underneath it is a second solution to a solved problem.

When you genuinely need one

Three cases, and they have something in common: all of them involve files.

• Overriding a template. Changing the structure of a single post, an archive, or a page template means a file of the same name in the child theme. There is no admin screen for this.
• PHP that is part of the site, not an add-on. Custom post types, changed hooks, altered queries. Things you want in version control and moved between environments.
• Work you need to hand over. A child theme is one folder. It is portable, it can be committed to a repository, and it can be handed to whoever maintains the site next. A pile of snippets and Customiser settings cannot be.

If a developer is building something for you, they will use a child theme, and they should. The advice in this article is for the person deciding whether to become that developer for an afternoon.

Building one, and the part that catches everybody

The mechanics are two files. Create a folder in wp-content/themes/, name it after the parent with -child on the end, and put a style.css in it starting with this:

/*
Theme Name:  Twenty Twenty-Five Child
Template:    twentytwentyfive
Version:     1.0.0
*/

The Template line must exactly match the parent's folder name, lowercase, including hyphens. Get it wrong and WordPress will not see a parent at all. Then activate it under Appearance, Themes, like any other theme.

Loading the stylesheet

Here is where most tutorials are wrong, and they are wrong in two different directions.

The first is @import. Older guides tell you to put @import url("../parent/style.css"); at the top of your child's style.css. It works and it is slow, because the browser has to fetch and parse the child stylesheet before it discovers it needs the parent one. It has not been the recommended method for years.

The second is copying an enqueue snippet without reading the parent theme. The handbook is blunt about this: what your child theme needs depends entirely on what the parent already does, "this is different for every theme, and there are no hard rules". Three cases:

Both of those are worth knowing, because they are the two themes most people meet first. Twenty Twenty-Four enqueues nothing. Twenty Twenty-Five does enqueue a stylesheet, but it asks for it with get_parent_theme_file_uri(), which means it loads the parent's file and never yours. Different code, same outcome: your child's style.css is ignored until you load it yourself.

The snippet goes in a functions.php in your child theme folder, and uses wp_enqueue_style:

<?php
add_action( 'wp_enqueue_scripts', 'child_enqueue_styles' );

function child_enqueue_styles() {
    wp_enqueue_style( 'child-style', get_stylesheet_uri() );
}

Note there is no closing ?>. A stray blank line after one produces the "headers already sent" error, and leaving it off is the accepted convention in WordPress files.

Three things that surprise people

functions.php does not override the parent's

Templates override by filename. functions.php does not. Both files load, with the child's running first.

This trips people up in both directions. Copying the parent's entire functions.php into the child produces "cannot redeclare function" and a white screen, because every function is now defined twice. Meanwhile, removing something the parent does needs a hook, not a deletion, because you cannot delete a file you are not replacing.

There is no such thing as a grandchild theme

The hierarchy has exactly two levels. You cannot make a child of a child, so a child theme bought from a marketplace cannot be safely customised the same way. Your options there are to edit it and accept that its updates will overwrite you, or to fork it into a parent theme of your own.

Your Additional CSS does not come with you

This one loses work, so it is worth knowing before rather than after. WordPress stores Additional CSS against the active theme's slug. Activate a child theme and the slug changes, so the Customiser's CSS box appears empty and the styling disappears from the site.

Nothing is deleted, and it is still in the database under the parent's name. Copy it out before you activate the child theme and paste it back afterwards, and this is a non-event instead of a bad afternoon.

When a child theme is the wrong tool

Two situations where the answer is something else entirely.

When the customisation is extensive. The handbook says this itself: making extensive customisations from within a child theme "can eventually become a management headache", and for larger projects it is often better to fork the theme and maintain your own. Once your child theme has overridden most of the parent, you are maintaining a whole theme while still tracking somebody else's updates, which is the worst of both.

When the parent is abandoned. A child theme protects your changes from updates. If the parent has not been updated in three years there are no updates to protect against, and you have built scaffolding around a building nobody is maintaining. Check that first, using our guide to spotting an abandoned WordPress theme. The same applies with more force to a nulled theme, which will never receive an update by definition.

One last warning, because it is the most common way child themes cause the problem they exist to prevent. A child theme that calls a parent function is coupled to the parent's code. When the parent renames or removes that function in an update, the site fails with "call to undefined function". Our guide on what to do when a theme update breaks your site covers the recovery, and the point here is that a child theme is not a guarantee against updates. It just moves where the breakage happens.

The short version

If you are changing how the site looks, use Additional CSS or the Site Editor and stop there. If you are adding a small piece of PHP, use a snippets plugin. If you are overriding templates or writing code that belongs to the site, build a child theme and take the ten minutes to read the parent's enqueue setup first.

And whichever you choose, take a backup before you activate anything. The failure modes above are all recoverable, and they are much quicker to recover from with a copy in hand.

Frequently asked questions