WordPress Child Themes: When to Use One and How to Build It

A child theme is a theme that declares another theme as its parent. WordPress loads the parent for everything, then lets the child override individual pieces.

The override rules are worth knowing because they differ by file type. For template files, the child's version wins entirely — if the child has single.php, the parent's single.php is ignored. For functions.php, both run: the child's loads first, then the parent's, so the child can hook in before the parent does. And stylesheets are both loaded, with the child's coming later so its rules win on equal specificity.

The practical result is that you can change one template, add some CSS and hook into the parent's behaviour, without touching a single file that an update will replace.

A child theme needs exactly two files to exist. In wp-content/themes/, create a folder — parenttheme-child is the convention — containing:

• style.css with a header comment declaring Theme Name and, crucially, Template set to the parent theme's folder name exactly. A typo here is the most common reason a child theme doesn't activate.
• functions.php that enqueues the parent stylesheet.
• Optionally screenshot.png so it doesn't look broken in the theme picker.

Older tutorials — and there are thousands of them still online — tell you to pull in the parent stylesheet with @import in the child's style.css. Don't. @import blocks the browser from downloading the two stylesheets in parallel, which measurably delays rendering, and it has been discouraged for many years.

Instead, enqueue the parent stylesheet from the child's functions.php on the wp_enqueue_scripts hook, then enqueue the child's stylesheet with the parent's handle as a dependency so the order is guaranteed.

There's a subtlety: many modern themes don't register their main stylesheet under a predictable handle, or load styles differently again. Check what handle the parent actually uses before assuming. If the parent already loads its own stylesheet properly, your child only needs to enqueue its own, with the parent's handle as a dependency.

Give the child's enqueue a version number tied to the file's modification time rather than a hard-coded string, so your CSS changes aren't stuck behind a browser cache.

Copy the template you want to change from the parent into the child, keeping the same path. If the parent has template-parts/content-page.php, the child needs template-parts/content-page.php, not content-page.php at the root.

Copy only what you're changing. Every file you override is a file that stops receiving the parent's updates — including its bug fixes and security patches. A child theme with twenty copied templates is a maintenance burden that will drift further from the parent every release.

Keep a note of the parent version you copied from. When the parent updates, you can diff its new version of that file against the one you copied and decide whether the changes matter to you. Without that note, you'll never know what you missed.

Before copying a template, check whether the parent offers a hook or filter that does what you need. Well-built themes have plenty, and hooking is always preferable: your change is a few lines in functions.php rather than a whole file frozen at an old version.

The same applies to removing things. Rather than editing a template to delete a section, look for the action the parent used to add it and remove it with remove_action. Rather than editing a string, look for a filter on it.

This also applies to WooCommerce, which has one of the richest hook systems in the ecosystem. A great many WooCommerce template overrides exist only because the person didn't know about the hook that would have done the job in three lines.

A child theme's functions.php is for presentation: enqueuing assets, tweaking the parent's output, registering a menu location. It is not the place for custom post types, shortcodes, tracking scripts or integrations.

The test is simple — if you switched themes tomorrow, should this survive? If yes, it doesn't belong in the theme. Put it in a small site-specific plugin. Custom post types in a theme means your content model disappears the day you redesign.

• You're overriding most of the parent's templates. At that point you're maintaining two themes and benefiting from neither.
• The parent theme is abandoned. A child theme doesn't make an unmaintained parent safe; it just adds a layer on top of code nobody is patching.
• You only need CSS changes. The Additional CSS box in the Customizer, or a theme's own custom CSS field, is simpler and survives updates too.
• You're building from scratch anyway. Starting a new site with a child of a commercial theme, then replacing nearly all of it, costs more than starting from a minimal starter theme.
• The parent is a block theme and you only want to change styling. theme.json in a child theme handles that far more cleanly than template overrides.

Block themes change the picture. A child of a block theme can override HTML template files in the templates/ directory and parts in parts/, the same way classic child themes override PHP templates. But most of what people used to need a child theme for — colours, fonts, spacing, layout defaults — is now handled by theme.json, which a child theme can provide and which merges with the parent's.

For a block theme, start by seeing whether a child theme.json alone gets you there. It's a much lighter thing to maintain than a set of copied templates.

• Template in the child's style.css header matches the parent folder name exactly.
• Parent styles enqueued from functions.php, not imported with @import.
• Child stylesheet declares the parent's handle as a dependency.
• Only the templates you actually changed are copied over, with the parent version noted.
• Hooks used in preference to template overrides wherever the parent offers them.
• Anything that should outlive the theme lives in a plugin instead.