If you’ve ever built a WordPress site from the ground-up, chances are that at some point you needed to do something that your theme and plugins couldn’t or wouldn’t do. You probably already know that you can add code directly to your theme, in a child theme, or in a site-specific plugin. But each approach comes with its pros and cons. Do you know when and why you should choose each one?
When I say “custom theme”, I mean a theme where you edit the theme files directly. This is usually what new WordPress users do in order to customize their site, as they don’t know what a child theme or a site-specific plugin is, and certainly don’t know how to create one. Indeed, those solutions are more involved whereas directly modifying the theme is usually as simple as locating the appropriate file and line, and adding/modifying/deleting said line.
If you use an off-the-shelf theme, such as one from our themes catalogue or from the WordPress themes directory, directly modifying its files is generally a bad idea. While it may be a quick and easy way to do what you need, an updated version of the theme will be released sooner or later; and once updated, you will lose all of your modifications, as updating a theme is really deleting the old theme folder and replacing it with the new version’s theme folder.
Now, a “custom theme” may also be a bespoke theme, built from scratch just for your website. In this case, you might not expect any updates to be issued by the developer (or perhaps you are the developer yourself), so you can safely modify the theme’s files, without worrying that they’ll be overwritten.
A child theme, is a theme that inherits the functionality of its parent theme (an off-the-shelf or custom theme) and builds upon it. In its simplest form, a child theme does nothing and (depending on the parent theme) the website looks identical as if the parent theme was enabled. The biggest advantage of using a child theme is that if the parent theme gets updated, the child theme is left untouched, maintaining all your modifications.
One big disadvantage of child themes however, is the fact that you no longer directly control the theme. For example, if you need to change something in the footer, you (most probably) need to override the footer.php template file in your child theme; that is, copy it to your child theme and modify it there. If you need to comment some code inside a function in functions.php, well, you can’t. If the function in question is pluggable, then you can provide your own version inside the child theme’s functions.php file, and if it isn’t, you need to be a bit it luck. Good themes (such as our themes!) provide actions and filters so that your code can hook and modify the default behavior. Good themes are also child theme-aware, anticipating that may be used as parent themes and trying to make your life easier. Bad themes don’t do any of that.
Having said that, child themes are a great way to add theme-specific styles and functionality. Styles and functionality that only make sense while using the specific parent theme. Is the slider too fast? Are the headings too big? That kind of stuff are good candidates for going into a child theme.
A very important feature of child themes, is that they are part of the template hierarchy. When WordPress tries to determine which template file to load, it first looks into the child theme, and if no matching file exists, it then looks into the parent theme. So, do you need to override the parent’s index.php file? No problem! Just provide it inside your child theme’s folder!
Since child themes usually contain customized files of the parent theme, it mostly doesn’t make sense to keep using a child theme with a different parent. Say for example that you use our free Brittany Light theme and you have a child theme ‘brittany-child‘ that integrates a newsletter signup form onto the footer, and it changes the typography of the site. You then switch to our most recent premium blogging theme, Spencer. Spencer includes a newsletter widget doing exactly what you had in your child theme, and your CSS rules are not needed since you like the typography of the theme. Instead of removing almost everything (including renaming everything) from ‘brittany-child‘, you create instead a new child theme, ‘spencer-child‘ where you start fresh, adding your favorite colors, etc. This has the added benefit that you can switch back to Brittany Light and ‘brittany-child‘ anytime you want!
From the example above it should be clear that, things (code, styles) that go into a child theme, should only be relevant with the parent theme itself. If you find yourself needing a piece of code that should apply to your site, regardless of the active theme, then it has no place in a child theme. It should go in a site-specific plugin instead.
Site-specific plugins are, as the name suggests, plugins tailored for a specific website. There’s no functional difference between a “normal” plugin and a site-specific plugin. Both are “just plugins” in the eyes of WordPress. The only difference is that a site-specific plugin is not going to be used by any other site, and it usually carries a distinctive name of the fact, such as “My Site plugin” or whatever you choose to name it. As previously mentioned, site-specific plugins should include the code that should be working no matter what the current theme is.
Let’s say for example, that you want an image of your signature to appear below every post, so that your blog feels more personal. One way it could be done, is to override single.php inside a child theme, and add the image right after the call to the_content(). If you change parent & child themes however, you’ll need to do this again in the new child theme, using the new parent’s single.php file. A better way to do it, is to create a plugin, and use the ‘the_content‘ filter to add it. Now, no matter which theme or child theme you’re using, the signature will always appear after each post. Isn’t this cool?
Plugins don’t have anything to do with the template hierarchy, so you can’t simply drop replacements of single.php, footer.php, etc in your plugin folder. This is neither a disadvantage nor an omission. In 99.9% of the times you’ll need to override a template file, it should be done in a child theme. For the 0.01% of the cases, there’s the ‘template_include‘ filter.
You may opt to create one plugin that contains all your site-specific code, or add more smaller ones, so that you can activate/deactivate specific features whenever you want, without affecting other functionality. Don’t worry, adding many files isn’t going to create a performance problem, not unless you plan on adding thousands upon thousands of files.
Which one should I use?
When it comes to your website, there are no hard rules to dictate what you should and what you shouldn’t do. While you may choose one method over the other, the reality is that in order to not lose your modifications, you should almost never touch the parent theme, even if it’s a custom theme. Using a child theme or a plugin instead of customizing directly the theme, allows you to change and experiment without the risk of messing up irreversibly. (But you do keep backups regularly anyway, don’t you?)
This leaves us with the other two: child themes and site-specific plugins.
Generally, child themes should concern themselves with the presentation of the site, while plugins should handle the functionality. As previously discussed though, some things might cross over and can go to either one; functionality applicable only to a specific theme can go into a child theme, and presentational elements that should apply regardless of the theme can go into a plugin.
In reality, most of the times you’ll have both a child theme and a site-specific plugin. Whenever you need to add a new feature, you’ll decide at the spot where it will live (hopefully remembering the contents of this post), but that decision is only right as long as the requirements stay unchanged. Perhaps you’ll change theme in the future and you’ll need to move some code from the child theme into the plugin. Perhaps it will be the other way around. Only time can tell. You can minimize the chances of moving code around however, by giving it a good thought beforehand.
WordPress is powerful, and as such, it gives you multitude of ways for achieving the same effect. Each one has its own merits and side-effects, and choosing the right one from the get-go will save you time and trouble down the line. Changing any file that may eventually get updated, will only end up with you (or me) crying over lost code.
So, how do you handle customizations on your site? Do you use a child theme or site-specific plugin? Both? None? Why? Let us know in the comments!