Welcome to the first official tutorial post from the Digital Fellows Tutorials blog! This post is dedicated to our illustrious fellow Erin Glass. She posted the first ever Fellows support request to Redmine regarding an interesting, and often times difficult to understand, facet of developing custom and advanced functionality using WordPress (WP): the parent/child theme relationship. My response to that ticket, as well as an earlier email, prompted me to consolidate all of that information into this – the first Digital Fellows Tutorial.

Erin began by asking a couple of very important questions:

As I understand, the functions.php file (if needed) rests alongside the style.css file within the child theme folder?

I also understand that most WP themes have multiple PHP files. When altering PHP files within a child theme, does one only need a new functions.php file?

While we’re also working on some site specific questions and issues, these broader ideas about the inner workings of how WP decides which templates to use and how they’re ultimately stitched together are fundamental to grasping the more advanced topics that allow you to truly take control of how your site looks to your visitors; which, at the end of the day, is what really matters.

Basic Instincts

I’ll start off with as simple an explanation as I can: a child theme inherits its functionality from its parent theme, just like you and I get our defining features and characteristics from our parents (hence the name). Once a child theme has been enabled as the active theme for a site, WP will look at the comments at the top of the style.css file. WP does this for all themes. It will see this line in the comments: “Template: [NAME_OF_PARENT].” This tells WP that if it needs a file to render a page that it cannot find in the child theme’s directory, it should look in the parent theme for an appropriate template.

Future Proofing the Future

With a basic definition and brief explanation out of the way, we can talk a little about the freedom and peace of mind that child theming provides. A totally plausible scenario will work best, so please bear with me for a moment. Fast forward 6 months into the future. You’ve worked long and hard to make your site the envy of the entire Commons community. You’re receiving requests daily to speak at CUNY events about how you implemented such advanced functionality into a WP blog. Unfortunately, you never setup a child theme. All of your enhancements, changes and groundbreaking features were done inside of the parent theme. Fast forward one more month. You get an email from me notifying you that a new version of your theme has been released and will be upgraded on our server during our upcoming upgrade. Suddenly, it’s as if the very fabric of space-time has been torn open revealing an alternate reality where all the hours you spent making the site into the greatest collection of pixels to ever grace a monitor are now effectively preventing you from upgrading to the latest and greatest version of your theme! To make matters worse, my email goes on to inform you that not only does the newest version of your theme fix all the issues you’ve been steadfastly working to correct, but it has also added an admin page that, once activated, provides a solution to bringing peace to the Middle East. You see, if you’d started with a child theme, the parent would have remained untouched. And therefore, an upgrade to the parent is as simple as dropping the new theme folder into the themes directory and refreshing the page.

While admittedly a little far fetched, this scenario plays out day after day on WP sites across the InterWebs. Separating your custom code from the functionality provided by your parent theme, while initially a little more work, saves you hours of backtracking and patching when it’s time for an upgrade.

Theme Template Technicalities

Now that we’ve laid a solid foundation for the reasoning behind the parent/child theme relationship, it’s time to get a little technical. I won’t go too deep into the guts of WP but I would like you all to have at least a cursory introduction to what’s going on under the hood.

A WordPress theme has only two requirements: a style.css and a single template (PHP) file. In the case of child themes, the template file requirement is almost always (at least initially) satisfied by the parent theme. Remember, a child theme is nothing more than an “extension” of the parent. When you enable a child theme, WordPress looks in that theme directory first for any files it may need; if it can’t find what it needs to render the requested page, it looks to the parent. Kinda like when you’re young and you get your first apartment. The rental agent looks first to you for the rent, and if you can’t come up with the funds, they go to your co-signer (most likely a parent).

What this means is that to customize a child theme, all you have to do is copy whatever file you want to change from the parent’s directory to the child’s and then edit to your heart’s content. Let’s try out one more scenario for a slightly longer explanation.

The file header.php is a very important template file. It defines all the crucial information that must be included at the top of a web page. Elements like <html> and <head> and all the <meta> tags that tell a browser what it needs to know about the current page. Let’s assume that you’d like to change the output of the <title> element. Further assume for a moment that you just created your child theme directory and you added the required style.css file. All requests to your site are now going to be using the header.php template from your parent since no template by that name exists in your child theme. Currently the parent’s <title> element looks like this:

[html]
<title><?php wp_title(); ?></title>
[/html]

Instead, you want your child theme to define a single title on all your pages (not good for SEO but that’s a topic for a future tutorial). Here’s what you want the code to look like:

[html]
<title>Dominic is Awesome!!</title>
[/html]

Think back to how the parent/child relationship works. There’s currently NO header.php in your newly created child theme folder. So when WP goes looking for that file it can’t find it; but it does know where our parent folder is and looks there. Finding the file in that folder it loads it up and moves on to look for the next template file it needs. So by copying header.php to your child theme WP will find it there first. This is basically how you change the way a theme works. By copying files to the child and editing them there, you can customize the functionality yet still retain the ease of updating the parent without overriding your customizations.

I’m Out

There is no magic, no top secret system for making your WP site utilize a child theme. It all comes down to a simple series of rules followed internally by the core WP code. As long as you activate a theme that references its parent in the comments of the style.css file, WP has all the information it needs to render your custom templates over those defined in the parent. Once you understand the underlying structure, it provides an incredibly powerful system for controlling the inheritance of theme functionality.

If I’ve glossed over any specifics that still remain unclear please leave a comment, contact me via email or through this site’s contact form. I’ll attempt to clarify as best I can.

Additional Resources

•  Child themes explained on the WordPress Codex

Featured Image credit: Stephan Hochhaus via Flickr.