Customizing WordPress Using Vendor-Built Child Themes

Almost without exception, whenever I build a WordPress Web site using a theme that could be updated in the future, I create a child theme and use it as the basis for the site. As I try to explain in this post from May of 2012, the child theme method effectively ensures that the modifications I make are preserved when the parent theme is updated. The child theme method is also a great way to stay out of the kind of trouble you can potentially get yourself into by messing with parent theme files.

Except for…

One exception is when I’m building a site based on what I’ll refer to as a vendor-built child theme. Examples of such child themes are all of the StudioPress themes (which are child themes of the Genesis theme) and the child themes of the WooThemes Storefront theme.

Since StudioPress’ child themes are (supposedly) never updated, they represent a unique class of vendor-built child themes. So let’s focus on WooThemes’ Storefront child themes — which can be updated and are.

The child theme method doesn’t work so well when customizing WordPress sites based on vendor-built child themes. If I make changes to a Storefront child theme’s functions.php or style.css files, those changes will be overwritten when the child theme is updated. Not good.

What to do?

Grandchild Theme?

A tempting approach might be to create a child theme of the child theme &mdash or a grandchild theme. Although this is possible, it is not recommended (here and here, for example).

Grandchild themes are not natively supported by WordPress, and they add levels of complexity and opportunities for problems to arise.

A Better Way

Here’s the approach I just implemented for a WooThemes Storefront child theme: I place my customizations in the site’s mu-plugins directory.

Suppose I want to add some new CSS rules. I will create a css file (call it custom.css) and upload it to the mu-plugins directory.

Then I’ll create a php file (call it functions.php) with the following lines of code and upload it to the mu-plugins directory.

Here’s the code, which utilizes a few WordPress functions/hooks:

function nwb_enqueue_scripts() {
	wp_enqueue_style( 'nwb', plugins_url('custom.css', __FILE__) );
}
add_action( 'wp_enqueue_scripts', 'nwb_enqueue_scripts' );

Note: Instructions in php files stored in a site’s mu-plugins directory are automatically read and excecuted (in alphabetical order) before normal plugins and before the theme’s functions.php file. Therefore, the above script effectively adds the custom.css style sheet to the head tag of every page of the site before any other theme- or plugin-related style sheets. If I want custom.css to load after another style sheet (e.g., after the main style sheet for the theme), I would include the optional third “dependencies” parameter in the wp_enqueue_style function.

Reference information on WordPress functions/hooks:

• wp_enqueue_style()
• plugins_url()
• wp_enqueue_scripts()

Comments Welcome

I concede that my mu-plugins approach for customizing CSS swims against the tide of conventional wisdom on the plugin vs. functions.php debate.

I welcome your comments. How do you handle customizations for Web sites based on vendor-built child themes?