This section is focused mostly on classic themes, as child themes are less useful for block themes. Nonetheless, the concepts described are universal to both types. Block theme-specific topics are discussed in the Block Themes section.
A theme acts as a parent theme when it has an active child theme. Any standalone theme can become a parent. We’ve been discussing standalone themes throughout this entire section. Let’s assume we created a new theme called Awesome Theme and we started selling it. Users download it and activate it.
Now let’s imagine a power user wanting to modify the look of the footer. They head to the wp-content/themes/awesome-theme folder and they modify the footer.php file. It works, they are happy. But then we push an update (version 1.1). They download it and POOF… All of their changes are gone. The parent theme files have been replaced with their new versions. That’s what child themes are for.
Creating a Child Theme
It’s surprisingly easy to create a child theme. There’s just 1 file a child theme needs: style.css. index.php is not required (nor encouraged unless you want to modify the parent theme’s index.php).
Let’s create a child theme for our Awesome Theme. We go to wp-content/themes, and create a new directory: awesome-theme-child (the name doesn’t matter). We create the style.css file inside this directory. There’s only 1 additional header you have to add to style.css for the theme to be recognized as a child theme. It’s the ‘Template’ header.
/*
Theme Name: Awesome Theme Child
Template: awesome-theme
// other style.css headers (as explained in the style.css section)
*/The Template header has to match the directory name of the parent theme. WordPress basically makes this a child theme for the theme located at “wp-content/themes/$Template”. The Theme Name and other options don’t matter for the child theme to work.
How Child Themes Work
As already noted, the main purpose of a child theme is to provide a way for adding persistent changes to a theme. After you create the child theme directory with the style.css file, you have to head to Appearance > Themes and activate the child theme. That’s right, our Awesome Theme should be inactive and the Awesome Theme Child should be active instead.
When WordPress is looking for templates (e.g., single.php, archive.php, etc.), it searches the child theme first, and if it doesn’t find the file, it proceeds to look for it in the parent theme. The order in the hierarchy (child first, parent second) is what allows child themes to override their parents.
Outside of full templates, there are also other files that your theme users might want to modify. These are template parts, assets, JS files, etc. If you paid attention reading the section about loading assets, you might already know how that works.
The built-in functions for getting file paths and URLs are designed to search the child theme first. I’m not going to explain them again, but those are functions like get_theme_file_uri() and get_theme_file_path(). The same is true for get_template_part() used to include parts. That is the whole reason why we’re using these functions instead of hard-coding the URLs or doing require(‘content.php’).
Persistence of modifications is ensured by the fact that updates apply to the parent theme only. Child themes are not touched when an update is released and downloaded. The way you’d usually modify a file from the parent theme in the child theme is by copying the file to the child theme (with the same name and directory structure) and making your modifications.
Child themes are a double-edged sword. They are amazing if you only have to make a small amount of insignificant changes, but they become a nightmare if you’re heavily modifying an actively maintained theme.
Just imagine you change 10 template parts. The parent theme is getting updated once a week. Every time you have to check if any of the modified parts have been updated. If they did, you have to analyze the changes and decide if you should merge them. Sometimes the updates will introduce breaking changes, which will make your files (which still contain the modified old versions) not compatible with the rest of the theme, and your site will break.
Trust me when I say this, as I have made that mistake – the less modifications in the child theme, the better. If you can add something with a widget, do it. If you can change an option in the Customizer, do it. If you can use a hook, do it. Try as hard as you can not to modify files directly in the child theme, and try to choose themes which will not force you to do so. If you find you need to heavily modify a theme, you might be better off forking the theme and maintaining it yourself.
functions.php In Child Themes
functions.php is a special case when it comes to files. It doesn’t override the functions.php in the parent theme. Both of these files are loaded. The child’s version is loaded first. This is powerful because it serves as your main PHP file for things like enqueueing assets or adding hooks – all while the parent’s functions.php (which is usually a critical file) still runs.
The benefit of running the child’s version first is that you can override so-called pluggable functions. Pluggable functions are functions enclosed in if ( ! function_exists( ‘function_name’ ) ). Most themes will make all of their functions in functions.php pluggable, so that you can override them if you find you need to.
Some poorly coded themes will use get_stylesheet_uri() to enqueue their style.css file. If you remember this function from the section on loading assets, then you should know why it’s a terrible mistake. As soon as a child theme is activated, this function will return the URL of the child’s style.css. Suddenly, your website will have no styling, as the parent’s style.css is not loaded. If you encounter that, you’ll have to enqueue the parent’s style.css yourself in your child’s functions.php.