WordPress began its life in 2003 as a Content Management System (CMS) targeted at bloggers. While blogging may have been at its roots, over the years it has grown to be so much more. It still excels as a CMS and blogging tool, but has become more of a hosting platform, a platform that powers corporate websites for Fortune 500 companies, ecommerce sites, landing pages, membership sites and even web apps.
This is largely due to the fact that the ecosystem has grown exponentially, providing WordPress users with a plethora of options to extend and enhance WordPress’s functionality to do just about anything through themes and plugins. The blog page with the sidebar on the right containing category lists and tag clouds is being replaced with responsive pages, interactive sliders, parallax effects and full-screen video backgrounds. Growth in this segment has been good for consumers and WordPress developers alike.
Some years ago it was common for WordPress users to install and test multiple themes all in a single day. We would comb wordpress.org and other sites looking for themes, many free, that gave a blog the style we desired. We were trying to be unique, but it was often the case that these themes had a very similar structure, shared many common elements, and simply applied different stylistic enhancements to page elements.
As Web 2.0 took over, so did the premium theme. Premium themes and enhancements to the underlying WordPress infrastructure gave us new power—the power to build media-intensive, highly stylized sites that allow customization to our hearts’ content. However, with this power comes great responsibility.
Rather than trying multiple themes, we now spend considerable time customizing our premium themes. We add plugins and write CSS to make our sites look and function just the way we want. This capability is great, but what happens when we, the developer of our premium theme, releases an update? If we’ve customized that theme and apply an update, there’s a good chance we’ve just said adios to our customizations.
There’s a surprisingly easy fix for this—WordPress child themes. By subscribing to the best practice of creating a child theme, we can safely update our theme(s) without fear of losing our customizations. (Note that when updating, only the parent is updated, never the child.) For some reason, child themes seem to intimidate many users. People have the impression that they need to be a developer to create and use a child theme, but that’s simply not the case.
A child theme is simply a theme that inherits all of the properties, functionality and styles of its parent. While that may sound a touch complicated, a child theme can be as simple as one small CSS file. Or, if you wish to perform more advanced customizations, it will likely be a small collection of files, but in all cases, it will simply contain only the files needed for your desired customizations and cannot function as a theme by itself. These files are where you make all of your customizations, and it’s these customizations that override elements present and inherited from the parent.
You can think of a child theme as a transparent layer placed on top of the parent theme. If I make no customizations to the child theme, then everything in the parent theme passes through it unfiltered and unchanged. However, if you customize the style (CSS) of an element to the child theme, then that customization overrides the style of the parent, and is displayed to the visitor. The majority of customizations we make with child themes are to the theme’s styles (CSS), but if you know what you are doing, you can use child themes to make much deeper modifications, such as custom PHP functions, and more.
As mentioned earlier, the main benefit of child themes is that they allow us to make customizations to a parent theme without fear of losing our enhancements—but it also provides us protection from ourselves. Should we break something by introducing erroneous or malicious code into our child theme, we can breathe easy knowing that the underlying parent theme is untouched. We can simply remove or reverse the changes we made in the child theme, and all should resort to normal.
Now that I’ve convinced you of the advantages of child themes, you probably want to know how to create one. You have two options—manually, or with a plugin. While I prefer the manual method, if you are only managing one site, then you might find it quicker to find a plugin that will create the child theme for you. There are many good plugins available on WordPress.org (or through your WordPress dashboard) and elsewhere, some of which are specific to a particular parent theme. Should you wish to create a child theme manually, <WordPress.org> has the instructions you will need.
Don’t fear, go forth and create!
