I’m regretting not getting started my series on WordPress 3.0 and custom content types; a big chunk remains to be explained, but that has to wait till after a few days of vacation.
But there was something Jim Groom mentioned that I was going to tackle later, but can inset now; it’s a powerful piece that’s been there quietly, that I used on the MIDEA site– Child Themes.
In all of my WordPress work I find a theme I like, download it, and then start ripping it to shreds. This makes it near impossible to update if the theme later changes.
Children take care of that.
What happens is that you download the Perfect Uber Theme and install it. But rather than start tinkering, you make another directory in the theme directory, call it something memorably like “Child of Bava” (mine is called “midea”). Inside at a minimum you create a style.css file and put at the top the standard comment block that defines a WP theme. Identify as a theme the directory name of the “parent” theme, in my case it is “modularity”. Then we use some CSS to slurp in all the existing styles of the main theme:
Theme Name: MIDEA
Theme URI: http://graphpaperpress.com
Description: A child theme, yo!
Author: Alan Levine
Author URI: http://cogdogblog.com
Then in my WordPress dashboard, I select MIDEA as my new theme, and it recognizes it as a “Child of Modularity”:
So here is what I can do; I can use all the style that the Modularity theme provides, but in my MIDEA style.css, I can add new CSS that maybe I decide I need or… even better, I can over-ride something in Modularity to customize ion my child theme. So the CSS is additive or on top of the Modularity CSS.
One of the reasons to do this is to keep my modifications separate from the original theme, so if there is an update to Modularity, I can install that, and my mods are still riding atop.
But what is even better; is I want to create a different sidebar.php template, or make the archive.php template work differently, I just create a version of it in my child theme, and it supersedes what is in the original parent theme theme. Again, it is keeping my customizations from mixing with the original theme.
And one more key thing, that we will get to in the rest of the WordPress 3.0 Customization code posts I hope I can get posted before too long–, the all important functions.php file, the one that allows me, you to add logic and custom code to your template, is additive like style.css. So as I develop specific functions I need for my variation on Modularity, I code them into a functions.php file that is in my child theme directory.
Besides being a more logical way to organize theme customizations, child themes offer some interesting potential. Let’s say we have a course where students or groups are set up in their own WordPress space. The “parent” theme might be the one for the class, but then we might have a series of different child themes of each student, with each its own customization (e.g. banner graphic, color themes, anything you can toss into a style), its own sidebar template, etc.
Child themes offer a sound structure for creating many variations of a core theme. I’ll never dive in and twist apart a theme again; I’ll just spawn children and design from there.
For more on Child Theming in WordPress see:
- Theme Shaper’s Child Theme Basics and How I used a WordPress Child Theme To Redesign My Blog
- Lorelle’s Parent/Child Themes in WordPress: The Future of WordPress Themes
- WordPress Codex entry for Child Theme
- Themelets a gallery of Child Themes
Let the kids out! Continuing in this series of WordPress 3.0 Hackery…
- Overview WordPress 3.0 Content Types– my plans to dive in
- Creating the content types. The easiest part
- Leveraging child themes– my newly discovered best practice for chopping apart themes.
- Adding the meta data field editing boxes (add_post_meta). Hacking the Editing fields.
- Modifying templates to display the content, Hacking the templates.
You can find all the posts in this series at http://cogdogblog.com/2010/07/23/roundup-wp3/