WordPress Child Themes: Why You Should Never Edit a Parent Theme

Editing a theme's files directly is one of the most common mistakes in WordPress development. When the theme updates, every change you made to those files is silently overwritten. Hours of work, gone, and if you did not take a backup of your modifications, there is no recovery. A child theme is the correct solution: it stores your customisations separately so they survive every parent theme update.

How child themes work

A child theme inherits all styles and templates from its parent theme. WordPress loads the parent theme's files by default, but any file that exists in the child theme directory takes precedence over the parent's equivalent file. If you place a modified header.php in the child theme directory, WordPress serves your version. The parent's header.php is ignored for that template, but all other parent templates continue to work normally.

CSS added to the child theme's style.css is applied on top of the parent's styles. Because child theme CSS loads after parent theme CSS, your rules take precedence when specificity is equal. The parent theme can be updated at any time and your child theme is untouched, it lives in a completely separate directory under wp-content/themes/.

This separation of concerns is the core principle. The parent theme is a library you inherit from. The child theme is where you put everything that is specific to your site. Updates to the library do not touch your additions, and your additions do not interfere with the library's update path.

Creating a child theme manually

A minimal child theme requires exactly two files. First, create a directory in wp-content/themes/ named after your child theme, convention is to append -child to the parent theme's folder name. For example: twentytwentyfour-child/.

Inside that directory, create style.css with the following header comment:

/*
Theme Name: Twenty Twenty-Four Child
Template: twentytwentyfour
Version: 1.0.0
*/

The Template field must exactly match the parent theme's folder name in wp-content/themes/, this is how WordPress identifies the parent. Then create functions.php and enqueue the parent stylesheet:

<?php
add_action( 'wp_enqueue_scripts', 'child_theme_enqueue_styles' );
function child_theme_enqueue_styles() {
    wp_enqueue_style(
        'parent-style',
        get_template_directory_uri() . '/style.css'
    );
}

Activate the child theme in Appearance > Themes and it is live. WordPress loads the parent's resources automatically and your child theme is ready to receive customisations.

Using a plugin to generate a child theme

If you prefer not to create files manually, plugins handle the setup automatically. Child Theme Wizard and One-Click Child Theme both create the correct directory structure, style.css header, and functions.php from the WordPress admin without any file editing. They are useful for clients or less technical users who need to manage child themes without command-line access.

WP-CLI offers the cleanest approach for developers who work from the terminal: wp scaffold child-theme twentytwentyfour-child --parent_theme=twentytwentyfour creates the directory and all necessary files in one command. It also generates a readme.txt and correctly wires the parent stylesheet enqueue.

What to put in a child theme

Custom CSS belongs in the child theme's style.css. For simpler or temporary CSS changes, the WordPress Customiser's Additional CSS panel writes to the database rather than a file, which also survives theme updates, but for anything substantial or version-controlled, the child theme stylesheet is more appropriate and portable.

Template overrides are the most powerful use of a child theme. To modify any template from the parent theme, copy the file from the parent directory into the child theme directory with the same filename and path. Edit the copy in the child theme. WordPress will serve your version for that template and leave all others untouched. Common templates to override include single.php, page.php, archive.php, header.php, and functions.php.

Custom functions go in the child theme's functions.php. This file is loaded in addition to the parent's functions.php, not instead of it. You do not need to copy parent functions into it. Hook into existing actions with add_action() and add_filter() to modify parent behaviour without editing parent code.

Template hierarchy: knowing which file WordPress will load

WordPress uses a defined template hierarchy to determine which PHP file to use for each type of page. At the top of the hierarchy are the most specific templates, single-product.php for a specific WooCommerce product post type, for example, and at the bottom is index.php as the universal fallback.

When you want to override a specific type of page, find its position in the hierarchy and create the corresponding file in your child theme. For example, to customise the layout of archive pages for a custom post type called events, create archive-events.php in your child theme. WordPress will use it automatically for that post type's archive and fall back to archive.php for others. The WordPress developer documentation includes the full template hierarchy as a reference.

When a child theme is not necessary

Child themes apply specifically to classic PHP themes where you make file-level changes. If you are building entirely within a page builder, Elementor, Beaver Builder, Bricks, and your customisations live in the builder's data stored in the database, a child theme provides no benefit. The builder's data is in the database and is not affected by theme updates. You would only need a child theme if you were also editing PHP template files alongside the builder output.

Block themes using the WordPress Site Editor work differently. Block themes store global style overrides in a user-edited theme.json and block templates saved in the database. These customisations also survive theme updates without a child theme. That said, if you need to modify a block theme's PHP template parts or add custom PHP functionality, a child theme is still the correct approach, the mechanism works the same way for block themes as for classic themes.

Version controlling your child theme

A child theme is a small directory with a handful of files, the ideal candidate for version control. Initialise a Git repository inside the child theme directory, commit your changes with meaningful messages, and push to a private remote (GitHub, GitLab, Bitbucket). This gives you a full history of every change, the ability to roll back to any previous version, and a deployable package that can be installed on any WordPress site via Git or FTP.

For agencies managing child themes across multiple client sites, a private repository per client child theme is the correct structure. Each site's customisations are isolated, traceable, and recoverable. Combined with daily hosting backups, you have both the file history (Git) and the full environment backup (hosting) available independently, two recovery paths for different failure scenarios.