3 Tricks For Improved Child Theming in WordPress

3 Tricks For Improved Child Theming in WordPress

There are a lot of reasons why it is better to create a child theme instead of modifying a theme, but one of the most important reasons is that doing so allows you to keep the parent theme up to date without losing your customizations.

The more template files you copy from the parent theme to the child theme, the more likely it is that you will miss out on the benefit of a future update to the parent theme as the changes are in a file your child theme is overriding.

In this tutorial I will show you three simple tricks to easily avoid having to copy and modify any parent theme files. These simple tricks will allow you to customize your theme as needed, while overriding as few of the parent theme’s template files as possible.

If you’re not familiar with how to create a child theme, I recommend that you read the excellent beginner’s guide to child themeing by WPMU DEV’s Raelene Wilson.

elephants

Override Parent Theme Functions And Classes

It’s important to keep in mind that every time you copy a template file from parent to child to modify it, you are effectively losing the ability to benefit from future updates to the parent theme. This is often unavoidable, but if you are only modifying the template to swap out a call to a function with one you created in your child theme’s functions.php file, there is a better way. Hopefully…

Any WordPress theme that is wrapped in a conditional check to see if the function of the same name has been declared or not makes your life easy. For example, if you were creating a child theme for the default Twenty Fourteen theme and wanted to customize the paging navigation by replacing twentyfourteen_paging_nav() with your own navigation function, you could write your own function, copy all 7 templates that the function exists in into your child theme’s folder, and then replace the function call in each. Or instead, you could just call your custom paging function “twentyfourteen_paging_nav()“.

How does this work? If you look in the template-tags.php file in TwentyFourteen’s inc folder, you will see the funciton is preceded by this line:
{code type=”php”}
if ( ! function_exists( ‘twentyfourteen_paging_nav’ ) ) :
{/code}
Since WordPress loads the child theme’s functions.php before the parent theme’s, when it comes to this function in the parent theme, this conditional will return false, and the parent theme’s version will be skipped over.

Getting Classy

The same strategy goes for entire classes as for functions. For example, take a look at the bottom of Twenty Fourteen’s functions.php and you will see these lines:

{code type=”php”}

if ( ! class_exists( ‘Featured_Content’ ) && ‘plugins.php’ !== $GLOBALS[‘pagenow’] ) {
require get_template_directory() . ‘/inc/featured-content.php’;
}

{/code}

Because of this, you can create your own featured content system, totally replacing the existing system, simply by creating a class called “Featured_Content” in your child theme.

Removing Actions And Filters

Any function in the parent theme that is hooked to an action or filter can be “unhooked” using the functions remove_action() and remove_filter(). Once the original action or filter is removed, you can replace it with your own.

You only need to specify one argument for remove_action() and remove_filter(), the name of the function that is hooked to the action or filter you are removing.

These functions must be called inside of another function hooked to an action that runs before the action or filter being removed. In general, the best way to ensure the removing action runs first is to hook it to “init”.

For example, if you wanted to remove all of Twenty Fourteen’s widgets, you would want to find the action that adds them, which is this one:

{code type=”php”}

add_action( ‘widgets_init’, ‘twentyfourteen_widgets_init’ );

{/code}

The key piece of information is the second argument in <em>add_action()</em>, which is the callback function for the action. We will use the same function as the callback for remove_action().

Our function will look like this:

{code type=”php”}

function child_removes_parent_widgets() {

remove_action( ‘twentyfourteen_widgets_init’ );

}

add_action( ‘init’, ‘child_removes_parent_widgets’ );

{/code}

Use A Plugin Instead

The strategy I discussed in the previous step is very useful for theme frameworks that define lots of actions like those designed for the Genesis Framework. When working with Genesis and similarly designed frameworks, you are already using a child theme, which you don’t want to modify. The best solution may be to write a simple plugin to remove actions in the child theme.

For example, if you want to replace your Genesis child theme’s footer, find the action(s) in the child theme and hooked to ‘genesis_footer’ and remove them, from a plugin, and then add your own footer in a function hooked to that same action.

For example:

{code type=”php”}

<?php

/*

* Plugin Name: Child theme customizations

*/

//remove child’s footer

function slug_remove_footer() {

remove_action( ‘function_for_child_theme_footer’ );

}

add_action( ‘init’, ‘slug_remove_footer’ );

function slug_new_footer() {

//create your new footer here

}

add_action( ‘genesis_footer’, ‘slug_new_footer’ );

?>

{/code}

What Can You Do?

These are some of the tricks I use to child theme with a light touch, maintaining (as much as possible) the ability to benefit from future updates to the parent theme. I use this approach when creating site or client specific child themes for my own starter theme, which changes regularly. I don’t want a child to lag behind over time.

What strategies do you use when creating child themes to get maximum benefit of continued development of the parent theme? In the comments share your own tricks, or some cool application of the three tricks I’ve shown you.