Making child themes part of your business development best practice.

In part one of this series on child themes, I discussed the hows and whys of child themes. Hopefully you understand what they are and why you should use them. In part two I want to discuss the various ways you can access or create child themes as well as show you some cool things you can do with a child theme.

A quick note to the reader, this article is aimed at Divi designers and developers. If you don’t use Divi most of this article will still be relevant, but some of it will be very Divi specific. Also, before we continue, I would like to point out that I wrote a supplementary article to part one discussing the basics of a WordPress theme. If you don’t know how a WordPress theme works I recommend you read that article first before continuing with this one.

Everybody caught up? Right, let’s crack on then shall we…

There are three ways you can get a child theme, buy one off the shelf (from any of the Divi related marketplaces), roll your own using a number of child theme makers available, or create one yourself from scratch (DIY). Lets look at all three options.

Off the shelf

Off the shelf child themes are great. You get a pre built child theme customised with the developer’s choice of style and functionality included. What is quite unique about most Divi child themes is that you also get demo content included with the theme. The ease at which child theme developers can create demo content using the Divi builder and the recently upgraded portability system means you literally get a fully functioning website out of the box. All you need to do is update the content, replace images and tweak some styles here and there and your site is ready to fly. If you want to get a website up and running quickly, these off the shelf child themes are just what you need.

Roll your own

What I like to call a ‘roll your own’ child theme is one that you create using one of the online child theme creators. There are a few options available out there, just Google ‘divi child theme’. These are a pretty cool intermediary step. What the child theme creator does is ask you to input a few fields and it will generate a child theme archive for you to download. This child theme has the most basic of functionality (mostly just rewriting the Elegant Themes footer credits) but it is a great way to see the basic inner workings of a child theme and learn to build your own from there.

Do it yourself.

Otherwise known as ‘developing a child theme’. This is how the pros do it. Don’t get me wrong I have nothing against either off the shelf or roll your own child themes, but if you really want to understand not only child themes but WordPress themes and/or theme development, then you should really be developing your own. Not only does it give you a skill that is sought after, but it will open up a whole new avenue of WordPress and Divi customisation, giving you endless scope to create unique websites for your clients.

Now, as this series of articles is focusing on how to do it yourself, lets learn how to create a child theme.

The very basics.

All of what I am describing here you can read about in the WordPress documentation on child themes. In short, a child theme simply inherits the layout, styling and functionality of the parent theme but gives you the ability to override any of this layout, styling or functionality. A child theme only needs two things to be considered a child theme:

a directory (or folder) to contain the child theme files
a style.css file

The name of the directory is irrelevant. WordPress recommends naming it after the parent theme (eg ‘Divi-child’) but this is not required. Mostly developers prefer to name it after the site its being used on or give it a descriptive name based on it’s content. It honestly doesn’t matter. What does matter is what is inside your style.css file.

The header of the style.css contains the most important part of the child theme, the parent theme registration. This is placed inside CSS comments at the top of the style.css file.

/*
 Theme Name:   Divi Child
 Theme URI:    http://example.com/divi-child/
 Description:  Divi Child Theme
 Author:       John Doe
 Author URI:   http://example.com
 Template:     Divi
 Version:      1.0.0
 License:      GNU General Public License v2 or later
 License URI:  http://www.gnu.org/licenses/gpl-2.0.html
 Tags:         light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready
 Text Domain:  divi-child
*/

Now the only really important part of this is the Template field. To ensure that this is registered as a Divi child theme you need to set Template to Divi. The rest of the fields are not important for a child theme to function, but it’s a good idea to at least give your theme a Theme Name and Version. If you are developing themes for client sites or to sell, its also useful to include the Author URI, as a link back to your site. Finally, while it is not a requirement to do so for the theme to work, because your child theme extends WordPress, which is licensed under the GPL, you should also include the License and License URI, as your child theme will also fall under the GPL.

You can literally start copying template files from your parent them (in this case Divi) to your child theme and edit them to achieve the effect you require. Some of the common things you can do is:

Copy the footer.php file to edit the footer credits (probably the question that is asked the most by new Divi builders)
Copy the archive.php file to change how the default blog archive is displayed.
Copy the /includes/social_icons.php file to add additional social media icons to your header or footer.
Copy the 404.php to create a custom 404 page for your site.

Quite honestly the sky’s the limit. Any file that is ‘auto included’ in the Divi theme can be overridden by copying it to your child theme and making the changes you require. You can also use the Template Hierarchy to create other files in your child theme to change how Divi renders certain views, for example creating a category.php file to enable how your category pages are rendered.

Working with style.

So obviously seeing as you have a style.css in your child theme, you’re going to want to also use it to add custom CSS to the site you are working on. As mentioned in part one, this is a quicker way to add custom CSS to your child theme and in my opinion easier to manage and tweak. For this to happen you’re going to need to add a functions.php file to your child theme. By adding this file you can queue up the parent and child style sheets, as well as use it to add any custom PHP functionality to your child theme, and therefore your site.

A good methodology is to simply always create a functions.php in your child theme with the following PHP.

function my_theme_enqueue_styles() {
   $parent_style = 'divi-style'; // This is the 'parent-style'.
   wp_enqueue_style( $parent_style, get_template_directory_uri() . '/style.css' );
   wp_enqueue_style( 'divi-child-style', get_stylesheet_directory_uri() . '/style.css', array( $parent_style ) );
}

add_action( 'wp_enqueue_scripts', 'my_theme_enqueue_styles' );

What this does is the following

Registers a function called ‘my_theme_enqueue_styles’, to be fired when the WordPress ‘wp_enqueue_scripts’ action is fired.
Enqueues the parent theme style sheet (in this case the style.css from the Divi theme)
Enqueues the child theme style sheet (in this case the style.css from your child theme) and makes it dependant on the parent style

It’s important to note that the parent theme style needs to be loaded as well as the child theme style, and in which order, so that the child theme styles override the parent theme styles, should they be applied to the same HTML elements.

It’s also important to note that when loading the parent theme’s style.css in your child theme functions.php, you should always use the correct style handle (or name). For Divi this is ‘divi-style’. If you use something like ‘parent-style’, as shown in the example on WordPress.org, it will end up loading the child theme style sheet twice. The example on the WordPress.org codex is just that, an example. You shouldn’t copy paste that code without altering the parent handle to match the actual handle being used by the parent theme. An easy way to check this is to enable the parent theme, view the source of the home page, and see what the id is of the parent style sheet being loaded.

Once that is done you can do ahead and start adding custom CSS to your child theme style.css. As I’ve said before this is the recommended way to make large CSS changes to your Divi site.

Fully functioning.

But what else can be done with the functions.php file? Well this file really acts like a plugin file for your child theme. So you can add pretty much any custom functionality to your child theme in this file. Some examples include:

Creating a function that will allow you to edit the contents of your footer credits from the WordPress Customizer
Pre populating your new Divi site with common Divi settings
Adding custom widgets
Adding custom functionality to your Divi site, like custom modules or layouts.
Customising the WP admin area

The sky is the limit really.

Active stations

Once you have created your child theme you will need to install it within WordPress. This is done by uploading an archive (zip) of the child theme directory via the Appearance -> Themes menu in your WP admin area (just like you would any other theme) and activating it.

A simple example.

I thought I would round of this article with a simple example of (more or less) all the things I’ve discussed above. I’ve created a simple child theme that registers two additional customiser settings for editing the Divi Footer credits. It also contains some custom CSS for the footer, just to show how custom CSS is implemented. You can download it from the GitHub repository.

For the next article in this series I will dive into each of the functions of the example child theme as well as add some more cool Divi specific things that can be done. I’ll also look at some of the comment WordPress specific things you need to know about, like actions hooks and filters.

The Basics of a WordPress Theme

In the first part of my article on child themes I explained a little about the history of WordPress themes and child themes, what they are and why you should use them. After sharing the post in a couple of online groups I am a part of, I received a fairly good positive response to the topic and my thoughts on it. One thing that also stood out from some of the comments was that a lot of Divi users don’t necessarily know how a WordPress theme works in the first place.

Everything I am writing about is (pretty much) included in the WordPress Theme Handbook, specifically the articles on the Template Files, Template Hierarchy and Child Themes. If you can afford the time to read through the handbook I highly recommend it. However it can sometimes be a little technical, so it’s often easier to get a ‘primer’ on the topic, to give you the relevant information you need in a manageable size. So, based on the responses to my first article I’ve chosen to first write this article to explain a little about how WordPress themes work.

Understanding the basics

To be able to understand child themes, first we need to understand WordPress themes. This means we need to talk a little about the Template Files and the Template Hierarchy. I’m not going to go into too much detail, but in short it’s the way in which WordPress looks for and loads the various template files in your theme to render content.

Template Files

Any WordPress theme has a base set of template files that is uses to render content for different sections of your WordPress site. If you take a look at the files inside a ‘standard’ WordPress themes (like those found on WordPress.org) you will see that, at their base level, all themes are made up of of two things, a style sheet and a bunch of php files, also known as templates. Theses templates include, but are not limited to, files like the header.php, footer.php, archive.php, single.php page.php and sidebar.php. Each of these templates performs a different type of task within your WordPress theme. The templates themselves are also divided into different template types, depending on what they do.

Template partials are template files that will be included inside another template file. For example the header and footer template files are partials. They will be included (and reused) inside other template files to render specific sections of a page, in this case the header and the footer of the site.

Examples:

header.php – contains all code to render the header
footer.php – contains all code to render the footer
sidebar.php – contains all code to render the sidebar

The common WordPress template files are the templates that will render the specific content of your site they related to. They can be very specific (rendering a specific category of posts, or a specific page) or very generic (for example the index.php file which will be used whenever a specific template file doesnt exist for the content being rendered)

Examples

page.php – contains the code to render a page
archive.php – contains the code to render any blog post archive (or list)
single.php – contains the code to render any individual post

If you read up in the Template Files section of the theme developer handbook you can learn what each one does.

Template Hierarchy.

The next thing to understand is the template hierarchy. This is the way in which WordPress will look for a series of template files to render the specific piece of content. If the first template in the list doesn’t exist it will keep going down the list until it finds a template it can use. The easiest way to explain this is to take a look at a WordPress blog.

On a standard WordPress blog, you usually have a ‘list view’ (list of blog items, a thumbnail image, an excerpt and some form of link to the full article) and then an ‘article view’ (the actual article itself, including any content for that article). So, that means that you would need at least two templates, one to render the list view and one to render the article view. This means that the WordPress engine will look for a template for each view and use it to render the content. For the list view, WordPress will look for a ‘archive.php’ file in your template folder to render the list view and a ‘single.php’ file in your template folder for the article view.
So your archive.php would contain some HTML to display the list view as well as a WordPress Loop to render the list of blog posts, and the single.php would contain HTML specific to the article view, as well as some PHP to get the relevant article content for display.

Now, if you are a theme developer you are probably swearing at me right now, and that’s fine. That last statement is not 100% correct but I am simplifying it a bit, bear with me.

So great, there is a template for list views and a template for article views, what now? Well, lets say that you want to have links to a list of blog posts per category and you want a different display for each category list view. Whenever a user views blogs under a certain category you want to include a description of that category above the list view. Well you could do this in two ways. Either you would add some code to your archive.php to check if the user is browsing a list of blog posts per category and show that description or you can use the category specific templates in the template hierarchy and create a different template per category. For example, if you had a category with the slug ‘products’ and you created a template in your theme called category-products.php, whenever the user browses to the products blog category, WordPress would use that template file to render the products category blog items. This is useful because it means you don’t have to add extra processing to your archive.php template file and you can just service products category specific content to the user, just by adding a template file.

The other important thing to understand is that for each level of WordPress, from pages to posts, categories to tags, there is a hierarchy in place as to what gets loaded. So for example, when WordPress renders a list of blog posts, it first looks for a category specific template (either by slug or by id) then a general category template, then the archive template and then finally the index template. So in our products category example above (lets say the product category id was 5) WordPress would look for the following template files, in this order, to use to render the list:

category-products.php
category-5.php
category.php
archive.php
index.php

That’s 6 levels of template hierarchy that you could use to render things differently for different points of just your blog!

The same goes for blog posts, you have the following set of templates at your disposal when developing a theme. Lets say I was rendering a page with the slug (or name) ‘my-page’ which has an id of 7. WordPress would look for the following templates, in this order, to render the page content:

a custom template file – (The page template assigned to the page in WP admin).
page-my-page.php
page-7.php
page.php
singular.php
index.php

Each template is the fallback to the previous template, with index.php being the final template for pretty much all sections of a WordPress site. You can probably see now why any theme developers reading this article were a little annoyed at my oversimplification of the theme hierarchy earlier ;-).

To get a better understanding of the different levels of template types available to you, as well the order in which WordPress loads them, I highly suggest you read Hierarchy in Detail section of the Theme developers handbook.

So what does this mean in terms of Divi. Well the base of the Divi theme is a small subset of the template partials and common template files. Divi doesnt have (for example) category based templates or even an archive template in its template file list. Because Divi has modules which render the blog lists and pages. Divi tends to use the templates towards the end of the hierarchy (single.php page.php and index.php) to render all content, because the modules are handling all the grunt work. However we need to have an understanding of what these template files do and how they can be ‘overridden’ using the hierarchy to be able to build our child theme.

Child themes – what are they and why you should use them

Since joining the Divi community late last year I think the one topic I’ve seen asked about or discussed the most is the concept of child themes, mostly when it comes to editing the footer credits in a Divi built website.

In this article I hope to give you a thorough understand of what a child theme is and why you should consider using one.

In the begining there was WordPress.

When WordPress was first released, it didn’t support themes as we know them today. If you wanted the front end to look a certain way you would edit the default templates with your own HTML and CSS. It also meant you had to have a pretty good grasp of PHP to ensure you integrated the correct function calls into your theme to ensure that the info from the database appeared to your user.

Later on the ability to create and install separate themes was added. At its core this was done to allow more flexibility to the WordPress user when it came to creating a front end for their WordPress powered site. It still meant that you needed some level of understand of HTML/CSS and PHP but it also brought about a shift in the adoption and usage of WordPress. Enterprising designers and developers realised that there was a market for selling premium themes to non technical end users who just wanted a good looking site. Fast forward a couple of years and themes are now not only able to render your data in a clean, well designed way, you’re even able to use page builder frameworks to design your page templates yourself, with the Divi theme being one of the most popular.

However, the big thing that a lot of people miss, don’t understand ( or don’t even know about ) is that WordPress also supports child themes. This was added a few years after the theme system was added and its important to understand what a child theme is to be able to understand its power.

In simple terms, a child theme inherits all the functionality of it’s parent theme, with the ability to override or customise how the parent theme works, without making changes to the parent theme files. To explain it a bit easier let me use a more real world analogy.

Lets say you buy a car. Two of the important aspects of a car are it’s underlying engine and drive train components, and the body. Now, if you want to change how the car looks, you can do things like repaint it. However, you can also modify it by doing things like adding a front or rear spoilers. Both options will change how the car looks but the respray is a permanent change, whereas the spoilers are temporary, they could easily be switched out with other parts.

Now I’m really extending the metaphor here, but the engine and drive train of your website are WordPress. This gets tweaked and upgraded from time to time (servicing and parts repair) but the core engine remains mostly the same for the life of the site. The installed theme (or parent theme) is the body work. Once you’ve chosen your theme you don’t really want to make changes to it (well get to why later). A child theme is like adding spoilers, making small changes to the main theme that are discardable or interchangeable (more or less).

Hopefully this makes things a little clearer for you. So lets talk about things like why you wouldn’t make changes to the installed theme and why its better to do it in a child theme.

To theme or not to theme.

If you have purchased a premium theme, either from a theme marketplace or a theme vendor (like Elegant Themes) you don’t really want to be making changes to any of the theme files. The reason for this is that if the theme every gets updated, you will have to either make copies of the changes to made to those files, update the theme manually and then make those changes again. If you choose to update the theme manually, then you’ll automatically loose any changes you’ve made and have to remake them.

So the first reason to use a child theme is if you have to make changes to theme files. Putting those changes in a child theme means that when update time happens you won’t loose any changes. It also means that if there are any structural changes to the parent theme that could break the site with any customisations you’ve made in your child theme, you can simply deactivate your child theme and activate the parent theme. Your customisations won’t be present until you fix them, but at least you’ll still be able to use the parent theme and keep most of the general look and feel of your site the same.

The second reason is speed. While themes like Divi allow you areas in your ePanel for custom CSS or JavaScript, its not ideal to use this for large chunks of either CSS or JavaScript code. The main reason for this is that these code snippets are stored in the database. So every time a page on your site loads, the script loading that page has to do extra queries to the database to fetch that code to render it on your page. If you use a custom header.php or footer.php in a child theme, WordPress will simply load your child theme template file instead of the parent theme template file, causing less overhead in the rendering of a page.

Finally child theme customisations are reusable on multiple sites. For example, lets say you are a web designer and you want the Divi footer credits (designed by) to be replaced by your own name. If you used a plugin to achieve this, every time you create a new site you would need to install that plugin and enter the relevant data for it to display as you want it. If you had a ready made child theme, with the correct data in the footer.php, all you would have to do is install the child theme to your client’s site and the footer credit would be correct. ( and by the way, this is not me bashing plugins, I’m a plugin developer after all, I just believe in using the right tool for the job ).

So hopefully that’s given you a good understanding of what a child theme is and why you should use it. In the next article in this series on child themes, I’ll explain how to create your child theme ( specifically for the Divi theme ) and some of the cool things you can do with it.