The theme framework you've built will be used as a parent theme in the sites you develop. This means that in each case you'll need to create a child theme to create a unique site with its own design and with extra or different functions compared to the framework.
The obvious way to go about this is to dive in and start creating template files in your child theme to override those in the framework, but thanks to the action and filter hooks you've added to your framework, this might not always be the best approach.
In this article, I'll outline some of the techniques you can use in your child themes to make best use of your framework and improvise your workflow.
The topics I'll cover are as follows:
- Creating starter child themes
- Amending code via the framework's filter hooks
- Adding code via the framework's action hooks
- Creating template files in your child theme
- When to use a plugin instead
Creating Starter Child Themes
The main purpose of developing your theme framework is to adopt the DRY (Don't Repeat Yourself) principle, and that applies to your child themes, too.
It can make you more efficient if you create one or more 'starter' child themes for use with your framework, which contain the core code you need to get started on new projects.
When deciding how to go about doing this, consider the way you work and the sites you build:
- Do you create a lot of sites for clients in the same sector with similar needs?
- Do you want to offer low cost template based sites to smaller clients?
- Are there specific template files you tend to create for most of your new projects?
- Is there functionality you need to include on some sites but not others? (For example, I use two starter child themes, one with comment functionality and one without.)
- Is there styling you tend to use for most projects, or can you use object oriented styling or a CSS preprocessor for most projects?
- Are there libraries or resources you use for most new projects, or for a significant proportion of them?
- Do you have two or three main categories you can place projects under, with each category involving similar development work?
If you've answered yes to any of these questions, then developing one or more starter child themes may save you time. You can create a set of child themes with the basic code that you repeat across all projects using them, and then you don't need to rewrite that code (or create those files) for each new project.
Note on caveat: If you're adding some code to every single new project, you may want to add it to your framework instead of to child themes, maybe by using a hook so you can override it if a different need arises in the future.
Even if you answered no to the questions above, it's worth creating a very basic starter theme with an empty stylesheet and functions file, and adding the instructions WordPress needs to access your framework's parent theme in the stylesheet:
/*
Theme Name: My Theme Framework Child
Theme URI:
Description: Starter Child Theme
Author: Rachel McCollin
Author URI: http://rachelmccollin.co.uk
Template: wptutsplus-theme-framework-part6
Version: 1.0.0
Tags:
Text Domain: tutsplus
*/
@import url("../wptutsplus-theme-framework-part6/style.css");
The required fields above are Theme Name and Template, the rest are optional. Make sure that for the Template, you use the directory of the framework theme, not its name. It's helpful to also complete the other fields as relevant for your theme.
The @import declaration is also important if you want to load the framework's stylesheet. As long as you place this above any other CSS, this will load the parent theme's stylesheet before any styles in the child theme's stylesheet, meaning you can add to and override styling in your framework in the child theme as necessary.
You might also want to create a starter functions.php file with the functions you most frequently use in your child themes. You can then choose to remove any of these and/or add to them for specific projects.
Amending Code via Filter Hooks
As well as adding styling to your child theme, you'll most likely want to make changes to the code output by the framework. The most lightweight way of doing this is via filter hooks, so it's worth exploring those first to identify if you can use any of them.
Creating a function which you then attach to a filter hook is much more efficient than creating a whole new template file for the new code; however, if you find yourself doing this repeatedly with the same filter hook, you might want to consider changing that filter hook to an action hook and writing a new function for each project which you activate via that action hook.
To be more efficient, you might want to create a set of relevant functions which you place in the functions file of different start themes or even create a plugin with your function which you activate when needed. I'll cover plugins in more detail later in this series.
I covered the process of creating filter hooks in an earlier part of this series, but to recap, you attach a function to a filter using the add_filter() function. So for example, to amend the link and name used in my site's colophon, I create two functions as follows:
function wptp_amend_colophon_name() {
$name = 'Rachel McCollin';
return $name;
}
add_filter( 'wptp_colophon_name', 'wptp_amend_colophon_name' );
function wptp_amend_colophon_link() {
$link = 'http://rachelmccollin.co.uk';
return $link;
}
add_filter( 'wptp_colophon_link', 'wptp_amend_colophon_link' );
These hook into two filters in my theme framework: wptp_colophon_name and wptp_colophon_link, and change what's output by each of them.
Adding Code via Action Hooks
Your theme framework will also have action hooks which you can use to insert content in various places in your sites.
If you've been working on the code files for the framework bundled with this tutorial series, you'll have seven action hooks to work with:
- before the header
- inside the header
- before the content
- after the content
- in the sidebar
- in the footer
- after the footer.
So for example, say you wanted to add a call to action button to the sidebar. You could create a new sidebar.php file, but it would be more efficient just to use the wptp_sidebar hook instead.
To do this, create a functions.php file in your child theme and add the following to it:
function wptp_cta() {?>
<div class="cta">
<p>Email us on <a href="mailto:[email protected]">[email protected]</a></p>
</div>
<?php
}
add_action( 'wptp_sidebar', 'wptp_cta', 1 )
The wptp_cta() function creates the markup for the call to action and the add_action() function fires it via the wptp_sidebar hook with a priority of 1 so that it appears before any other content activated via that hook.
There is plenty of other content you could add using your action hooks, such as sharing buttons above or below the content, extra content in the footer, a search box in the header and much more.
You might just want to add some content on specific page types, such as single blog posts, in which case the most obvious place to start would be by creating a new single.php template. But you can still use your action hooks with the addition of a conditional tag:
function wptp_after_single_posts() {
if( is_singular( 'post' ) ) { ?>
<h3>Enjoyed this? Try reading more!</h3>
<?php
// query to list latest blog posts here
}
}
add_action( 'wptp_after_content', 'wptp_after_single_posts' );
This would create a new query (using WP_Query) which outputs a list of the most recent blog posts, to encourage visitors to read something else after they've finished a blog post. The is_singular( 'post' ) conditional tag ensures that this is only output for single posts, and by attaching it to the wptp_after_content hook you'll display it after the main post content.
Creating New Template Files
On occasion you won't be able to do what you want using the filter or action hooks in your framework, in which case you'll need to create new template files in your child themes.
These might be the same template files as are stored in your framework, in which case the files in the child theme will override them. Or they might be new template files, for example for a new category, taxonomy or post type.
If you are creating template files in your child themes, it makes things easier if you use the template files in your framework as a starting point. The steps I follow are:
- Identify the template file you need to create with reference to the WordPress template hierarchy
- Create a blank file with the appropriate name in your child theme
- Identify the file in your framework which is closest to the new file (again with reference to the template hierarchy)
- Copy the contents of that into your new file
- Make amendments to the new file as required.
Doing this saves you the work of duplicating any code which will be common between your new file and the existing files in your framework, such as the calls to include files.
When to Use a Plugin Instead
Another option you have when creating sites based on your framework is to use plugins in conjunction with your child themes. A plugin won't replace a child theme completely, but it can be useful in the following circumstances:
- The functionality you want to add isn't theme-dependent (i.e. you want to keep it if the site ever changes theme in future). This might include registering custom post types or taxonomies, for example.
- You want to use this functionality on a number of the sites you create, but not enough for it to go into a starter child theme or the framework itself.
I'll cover developing plugins for your framework in the next part of this series.
Summary
Your theme framework is just the starting point of a library of code and files you'll create to support the sites you develop. Each site you create will need to run on a child theme, which will have your framework theme as its parent.
As we've seen, your child themes will add their own styling and functionality, and they can do this by hooking into the action and filter hooks in your framework, or via the creation of new template files. It's always a good idea to adopt the solution which needs the least code, as that makes your site faster and your life easier!
Comments