When working with WordPress themes, child themes are the promoted way of making customizations to a theme. The logic is pretty simple on paper, the child theme inherits all the functions and styles of the parent theme, but you are now able to overwrite anything you like with your own CSS and add your own template tweaks.
There are a lot of benefits to child themes. One great thing is that you only have to deal with the stuff you want to change in your child theme directory, while you can let the parent theme take care of the rest. Often, all you want to change is some css and that makes organizing your child theme fairly easy as you can get away with using a single file. Most importantly though, the child theme method makes it so that the parent theme can be safely updated (right?).
When I first started with WordPress, it wasn’t that common for themes to get updates and if they did, it was a manual uploading process. Now, it’s far more common for themes to get frequent updates and the update api is similar to that of plugins with push button updates. Nobody really likes updating, especially if it’s a theme because you worry about whether it is going to mess with your design. But updating you must (right?) to stay current with the most recent code base and fix bugs and security issues that are uncovered. Child themes, on the face of it, are designed to protect your customizations.
So child themes are important and provide a lot of benefits. What’s not to love?
Well, consider these common scenarios that child themes can try to tackle and let’s see how well it performs.
Scenario #1: A non-designer/developer wants to make some small css edits
The problem with child themes from the perspective of a regular user who’s not familiar with WordPress coding, is that they first need to understand that they need to make a child theme. If they get that far, they have to figure out how. And to actually set one up requires a bunch of steps. You need to have a basic understanding of how parent themes and child themes relate to each other. They need to create a directory in your themes folder, setting up the stylesheet and so forth. Those are all technical tasks that require a user to work around in the file system. Now it’s important to add that some themes package up a child theme and I think there is a plugin that makes spawning a child theme with a click of a button possible. For sure, a push-button solution to setting up a child theme, that’s a wonderful thought. Even with that, child themes are kind of an abstract concept for a new user to have to come to grips with. Are child themes really needed to make some small tweaks?
Scenario #2: Tweaking templates
If there’s a great case for using child themes, it’s to change how some templates display content, right? Say for instance, you want to move the publish date display from the top to the bottom of a post. Well that’s easy with child themes. You take your template file from the parent theme, copy it to the child theme, modify to your heart’s content and voilà. Oh wait, it’s not showing up on pages, just on posts. No worries, let’s also copy page.php to the child theme directory and make the same edits. Before you know it, you are digging through all the templates and making wholesale copies and edits and your child theme directory all of sudden looks a lot like your parent theme directory. I mean, this is not a terrible thing, but has it made our world that much brighter and clearer? I don’t know.
Scenario #3: Making non-trivial changes to the theme
Let’s say you are making largish modifications to a theme. You want to create this novel front page layout, you are adding sidebars to pages, you are changing how excerpts are displayed and adding templates for some custom post type. All your modifications live in the child theme and so the parent theme can be easily updated without overwriting anything you wrote. Perfect right? Except you update your theme and all of a sudden you find your theme is broken. What?! That’s not supposed to happen. Well it can, given the right circumstances. Just because you’ve prevented updates from overwriting what you wrote, doesn’t mean it’s impervious to breaking when the parent theme gets updated. So we can throw out the idea of carefree updating just because we adopted the child theme methodology.
The other potential issue when making big changes to a theme inside a child theme is that the likelihood of veering off of how things are coded in the parent theme becomes a bit higher. Because the code is more isolated from the parent theme, some users might code things in such a different way than is done by the parent theme. This can lead to confusing situations, as well as a higher likelihood of things breaking on updates. Consider the most common alternative to child themes: copying a theme and renaming it (also has downsides, mind you), you are far more likely to fit your code into the way things are done in the original theme.
Scenario #4: Extending a base theme or framework & theme skins
Another nice use case for child themes is the way it allows theme developers to work off a base theme. That way you can build on a great foundation and create something more unique on top of it. These base themes tend to be updated frequently – all the more reason to use a child theme. What’s not so ideal about this way of creating themes is that it makes things more complicated. If a user wants to modify your child theme, it has to create… wait for it… a grandchild theme. And now we have files for our themes living in three parallel directories. Let’s say a consultant builds you such a grandchild theme and now you need to make some modifications… do you want to create a great grandchild theme? I bet you do.
So now there’s a bunch of things going on. Imagine the cognitive overhead with files living in multiple directories, inheriting stuff. Updating a parent, grandparent or even a great-grandparent theme adds a whole new layer of breakage possibilities. Happy debugging that, newbie! Oh, sorry, are you confused when browsing wp-content/themes/ and you don’t remember what theme is what among all the other themes you’ve downloaded? Yes, the theme hierarchy is not reflected in the file system where you make your edits, so stay sharp!
#holdon
Grandchild themes aren’t actually natively supported so you wouldn’t get the same ease of implementation as you do with child themes even if you wanted to go that route. It begs the question, if grandchild themes aren’t really the solution for these situations, users have to do things differently anyway. Kind of limits the child theme methodology in the first place.
Now, from a theme developer perspective, selling child themes is a tough sell. Try explaining to your users that they need this parent theme installed but not activated. If you are working with a commercial parent theme, you lock your theme’s faith to whatever the parent theme’s developers decide to do with it (or not). Instructing users on editing your child theme is not something to get excited about either.
The myth of solving theme updates
Themes can get updated. Some themes get updated often and some do not. The prevailing mantra is: updating is critically important! Child themes solves issue of people updating, supposedly. Except it doesn’t do it really that well. Stuff can break regardless of being faithful to the child theme paradigm. This is why some people don’t update. Who wants to hit the update button if you know you could be in misery the moment you see your site has been screwed up? You have stuff on your schedule, and solving problems you didn’t need or ask for wasn’t on it! So if people are reluctant to update, at best we can say the child theme setup is only partially delivering on its promise.
But wait, think about this themes getting updates thing. Why are theme updates important to start with?
Take plugins for example, if you don’t update them, you might be missing serious security fixes or performance boosting improvements. Plugins are almost always critically important to keep up to date. But if a theme needs a security patch, it’s probably doing something it shouldn’t be doing in the first place. Many themes try to stash far too much functionality in the theme. Functionality that absolutely should be living in plugins. If themes are created and chosen properly, there would be very little reason to solve a ‘critical security fix’.
Simply put, the child themes paradigm doesn’t tackle the problem of updates at the root.
There are, of course, more reasons a theme gets updates. Usability fixes, improvements, added templates, better file organization, updated support for new WordPress functions. The thing is, a particular theme update might not affect the working of your site at all, good or bad. You probably don’t care that your theme has better multilingual support, fixed bugs with it’s right-to-left language support or added some post format that you are not going to use, ever, anyway. I’m not saying that all updates are trivial, I’m just saying that the need to update a theme as they come out is not important by definition.
When an important update does come out, an alert webmaster can also check to see what the actual changes are and work that in manually if they didn’t go the child theme route. In fact, you might have to do that anyway if those updates would affect your own custom code.
If the person who manages the site isn’t alert, how likely are they to hit that update button anyway? The semi-alert webmaster might hit the update button automatically and then become embroiled in a site debugging session. If there are changes in the parent theme, the code in your child theme may need updating too – so you have to spend time investigating. The end result is the same, either you are being mindful about your WordPress installation, or you are not – hassle free updates are no guarantee. Child themes don’t really tackle the problem that beautifully.
Another road block to using child themes
So you decided you want to make some updates that warrant the creation of a child theme. Your client decided the site needs to be responsive! Let’s get to work on a child theme then. Except the moment you switch to the child theme, you lose a f&ckload of settings that you have to migrate. Oh what fun! And this is the point where I imagine many people decide to edit the parent theme instead. If child themes are so important to use, why is it such a pain?
Functions.php hell
Child themes don’t do anything to actually improve coding practices all that much. Function.php hell continues to exist. Need to tweak your theme’s functionality, stick it in the functions.php. Create a functions.php in a child theme! Yeah. Now we’re doing things proficiently. Wait, no.
Endlessly long functions.php with disorganized snippets are not the answer. Some users are smart and use file organization, but it’s still a bunch of functions living in your theme directory. It’s not ideal. Often functions end up in there, when they are theme agnostic. And even when they are theme specific, a better place to stick certain functionality code is inside plugins.
But you really can’t blame people for this practice because the better alternative is not straightforward enough. I’m all for creating small plugins that handle specific functionality. But creating plugins is a leap for new users and a slight hassle for experienced users as well. There’s no ‘create-a-mini-plugin button’ in the interface. You have to create it all yourself. But the benefits are very nice. You can create functionality that will work in your next theme (custom post type registrations for example) without moving code around. You can toggle small plugins on and off which makes troubleshooting things much easier. If you make mistake, the plugin is deactivated instead of crashing your theme. And – by having it in a plugin – you won’t have to touch your theme’s files.
Alternatives
My frustration with child themes in WordPress stems from the fact that there are better ways to do things. There are alternatives to be had. They are not all perfect, but I will cover some of them in an upcoming article out in a day or two. In the mean time, what do you think could be a better way of dealing with customized themes?
ps. Sign up to my newsletter if you are interested in catching the follow up article.