How to Develop a Child Theme

So you found the perfect theme for your site. Then you realized there are things you would like to change that cannot be changed through a plugin. Those could include extra widget areas or menu locations, new templates for your custom post types, different responsive layouts… the list goes on. Thankfully WordPress provides a mechanism to build what we call a child theme. That is, a theme which implements its parent’s functionality unless otherwise specified. In this article we will discuss how to develop a WordPress child theme.

Are there any other solutions?

Well, a brute-force solution would be to go ahead and change the theme itself. That would do the job for you, until the next update. When you eventually update the theme, most of your changes will be overwritten and you are back to square one.

Of course, you could be extra careful to never update the theme. Or you could rename the theme altogether so that WordPress will never consider updating it. But then you would miss out on potentially important updates provided by the original theme author. Not to mention the potential limitations imposed by the theme’s license.

So where do I start?

Let’s start with the bare minimum on how to develop a WordPress child theme.

A child theme follows pretty much the same rules as a standalone one. It must reside in a subfolder of wp-content/themes where WordPress should find a style.css with a special header. That header should contain the theme’s name and also a special Template field. A minimal style.css for a child theme would be the following:

/*
Theme Name: Some Theme's Child
Template: some-theme
*/

In the above example we are creating a theme named Some Theme’s Child, which is a child of Some Theme. Note that we reference the parent theme not by its name, but rather by its directory name relative to wp-content/themes.

Now, unlike standalone themes, a child theme does not have to include a default template (index.php or templates/index.html). However, a screenshot image is highly recommended.

Including all the styles

When developing a child theme, we have to check how the parent theme is including the main stylesheet.

If the parent theme is trying to load its style via get_stylesheet_uri(), it will eventually load the child’s style. That happens because this function loads style.css from the active theme’s folder. In that case, we will have to load the parent’s style in functions.php like so:

function child_enqueue_scripts() {
  wp_enqueue_style('parent-style',get_parent_theme_file_uri('style.css'));
}

add_action('wp_enqueue_scripts','child_enqueue_scripts');

On the other hand, if the parent theme loads its own stylesheet, we need to include the child’s style in the following manner:

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

add_action('wp_enqueue_scripts','child_enqueue_scripts');

Since we mentioned functions.php, an important thing to keep in mind is that the child’s functions.php will run before the parent’s. In other words, the functionality of the child theme precedes that of the parent. And, since both files are eventually loaded, we do have to be careful for conflicts, especially in function names.

Overriding and extending

When the WordPress core tries to decide which template (or template part) to use, it will first look in the child theme’s folder. Consequently, if a template exists in both folders, the child’s one will take precedence, thus overriding the parent’s. If, for example, we wanted to modify the parent’s parts/header.html file, all we’d have to do is copy that file to a parts subfolder in our theme’s folder and start editing it.

Another major reason to develop a child theme is to extend the parent’s functionality. For example let’s suppose the parent theme doesn’t support rendering our vehicle custom post type, so it defaults to the single.php template for it. The way to go about that is to copy that file to our child theme’s root folder, rename it to single-vehicle.php and modify it to i.e include potential custom fields or include a different sidebar.

Needless to say that any new widget areas, menu locations, widgets and the like should be defined in functions.php and any new/overriding css code should be included in our child’s main stylesheet file.