As with all industries, WordPress theming has it’s fair share of trends, flowing in and out of popularity as the WordPress product and community evolve. Through these trends, needs for supplementary resources evolve, where users aim to enhance trends via additional products or services. A trend that has been growing in popularity in recent years is that of “Theme Frameworks” or “Advanced Parent Themes”. These themes, while bundling in large amounts of valuable code, can become confusing to modify and upgrade for the end user. This, following the flow of trends, grew the awareness and need for the use of child themes.
Child theming has been around in WordPress for a considerable amount of time, allowing users to create a smaller theme that piggybacks off of a larger theme, with it’s own CSS and customised PHP functions. A perfect fit with “Advanced Parent Themes”, yes? So why are some users apprehensive about it? Fear of the unknown.
To many WordPress users, child theming is an “advanced concept”, which is standing in the way of setting up their website and getting them blogging. It doesn’t have to be that way. In addition to this, once a child theme has been created (essentially a folder with two virtually empty files in it), what has the user actually achieved? They’ve added no custom CSS and no custom PHP functionality. The child theme now either looks empty or looks like the parent theme (if the parent theme’s stylesheet was imported, which is another step).
With this in mind, I sat down the other night and sought to make this process easier for users. Easier to not only get their child theme created, but also to get some base code into the files to assist the user in customising their child theme. Within a few hours, I’d created a tool that, with a few clicks, could create a child theme with some basic starter functions (provided by the parent theme) to get the user started with customising their child theme.
At WooThemes, we like to observe and give back to the WordPress community (see Appearance -> Menus in your WordPress Dashboard). With the rise in “Theme Frameworks” and “Advanced Parent Themes”, we feel that this tool could benefit the community at large. Therefore, with the addition of one or two small text fields to any WordPress theme, it would be able to setup starter code within child themes created of it.
So, what child themes have you created today?
About
Great work! I can see this being particularly useful in a multi site environment.
Definitely should help speed up the process if you’ve tried child themes before. 🙂
I use a child theme with virtually every woothemes (or other) site I build as I find it makes it easier to update the original theme and keep a track of what I’ve modified / added.
I think once you’ve tried it a couple of times it’s not too hard to get your head round, but this is great functionality – very easy, and very fast for everyone to get going very quickly
Personally, I think the biggest problem with mid / heavy modification of parent themes via child themes is the ability to ‘remove’ options. So for example when I want to remove the standard navigation function or post meta functions in canvas I’ve got to know where those functions are and how to remove via filters etc. I don’t think you could approach a solution to that in the same way, but further documentation of theme (and framework) functions might help those of us doing heavier modifications.
Or what about removing / hiding unwanted theme options from a parent theme via a child *without* creating a whole new theme-options.php file? That would be very useful!
Michael, I agree with your statement here.
It’s something we have started with the WooCodex, but definitely think that that section can be expanded upon. We just need to find our devs some time to do so. 🙂
For multi-site or a ‘network’ of sites (something like Envato, for example), child themes are really a must-do.
But for one-offs, I just don’t see the point. It’s not that they’re too advanced, it’s that they’re simply unecessary. Any custom PHP that you want to persist in the event that you want to overhaul your theme can be done with a plugin. Changing the look of a site often involves adding and removing sections, changing section purpose and intent, as well as updating the CSS. Ie. modifications beyond what a child theme is intended to provide.
This is a case where the tool should be right for the job. Don’t just use it simply because it’s available. You’re designing a site with no anticipation of needing variations on the site, there’s no need to bother with child themes. During that site’s life cycle, updating CSS and the core theme files is a perfectly valid approach.
We do take both approaches Greg, and agree with finding the right tool for the job.
Purely modifying CSS is what the custom.css file is for, but if you do major structural changes and child theme may come in handy. 🙂
I tried working on a child theme for simplicity when it came out but I didn’t get the slider to function.
I should try again as I wasn’t very serious about it and I am more interested now.
This looks like it would be an amazing start to a child theme for sure!
Would love to use it
I have been reluctant to try child themes because it feels like code bloat to me. I already don’t feel right doing css on top of css on top of css just to undo. and redo the base stylesheets. Now I feel like it’s just too many layers to do child theme on top of theme on top of framework on top of wordpress. I guess I would really just like a way to keep this simple. I don’t even like the header css from canvas … I use it during development but then go back and consolidate it all in custom.css before eliminating from the output. I am always looking for ways to make it cleaner while also reducing the amount of code and keeping it updatable. (From my phone sorry for any typos)
You don’t have to import the parent theme’s stylesheet. You can work from nothing if you want to.
But if you are, say, using Canvas and starting with the base 2-col layout, you generally start from the original canvas stylesheet and go from there.
There is a lot of work yet to be accomplished in regards to WordPress theme standardization and I really hope efforts like this get adopted into the core.
Obviously, every theme doesn’t need to reinvent the wheel so when someone gets the solution right, we should capture that and move on to the next issue.
I think the difficulty in child themes lies in that you simply can’t avoid learning a certain level of programming to be successful with it. When working with child themes, it’s not enough to be able to create code, you have to be able to code the /differences/ between what already exists and whatever it is you want; this means a fair amount of spelunking through the parent theme to see what does what and how best to alter it. This is why solid documentation is so helpful, as Michael mentioned above (sooo looking forward to the next Canvas version with sporty new documentation 🙂
I also appreciate Nikole’s comments, and feel the same way about pile on top of pile. But child themes (and these piles on piles) make it possible for WordPress or Woo to make continual improvements to “my” theme without anything breaking – invaluable for security updates, stability and other things my clients deserve, but that I just don’t have the time (nor desire) to keep up with.
Doesn’t that just create another layer of updates though? I have to update WP, then the framework, then the theme, then all the plugins, then …
Hi Nikole,
Using a child theme would make the theme updates easier, as kwight mentioned above. It means you can update the parent theme without worry that your changes/modifications/additions will be lost, as they’re all in the child theme. 🙂
Cheers,
Matty.
But you’re still updating one more thing. You’d be updating the WP, the framework, the theme .. I would rather just see some of this combined. For example, if Canvas and the Woo Framework was combined into one package, and the themes became child themes on top of that – then yeah, I’ll go for it. Then I just have the framework and WP to update, not 3 things.
It just seems that, in my head, I want things to be more lightweight, and they are becoming the exact opposite. Sure, that makes it easier to update … but is easier our entire goal? I can take a theme and spend my time writing a child theme that undoes the original code and replaces it with mine, but my goal is quality, not “ease”. (If easy was my concern, I wouldn’t be eliminating the header output in Canvas.) To that end, I would rather go through and compare files on a file by file basis to avoid further theme bloat than make something that is all about one-click updating. It doesn’t seem like very clean design to create a situation where one section of the site is controlled by 5 different files.
There just has to be some better way of doing this …
This is an awesome tool for new users. When will it be available?
Kudos on pushing the envelope again Woo. All of WordPress benefits from WooMenus.
I’m feeling Nikole’s pain here, for Canvas in particular. I know that the theory is that if you create a child theme and then keep all your mods in the child theme, you can update the framework and parent theme without worry. I’ve not found that to be true.
Often Framework and Canvas updates break something on heavily modified sites with child themes. Or an update will add a feature you were not aware of (like a new comment area) and then you see it appear later and must go back and hide it, remove it or style it appropriately. I don’t update a heavily modified Canvas theme with child theme or the Framework once a site is deployed live for these reasons. So, I’m beginning to question the usefulness of child themes when doing heavy Canvas customization–which is the whole point of Canvas to begin with.
Interestingly, with the Framework in the update box it says “We recommend backing up your theme files before updating. Only upgrade the WooFramework if necessary.” Eh? That means to me the Framework update may screw something up even if you’re running child themes.
I agree with Nikole, there are too many piles on piles now to be updated:
– WordPress
– Plugins
– WooFramework
– Theme
– Child theme
I don’t have answers, but better documentation of Canvas would be a bonus. Michael’s comment about the depth of knowledge required to remove/add options through the functions and filters in the parent theme is spot on. I feel like making Canvas more “Headway” like in the Theme Options panel would be beneficial and allow for quicker design. The ability to add/remove more options through the theme options panel would be great.
I’m not sure of the usefulness of the Child Theme creator’s multiple tag options (colors, columns, etc.)as most of those options one can control through CSS/Woo layouts via the parent theme. Might be useful as you say to the larger WordPress community. I do like the ability to quickly create a child theme portion though.
Hi Frank,
To clarify, the tagging feature is intended for use with the “Feature Filter” in the “Appearance -> Themes” page’s search functionality. 🙂
Regarding the removal of hooked functionality via a child theme, this shouldn’t be necessary as the child theme can hook on after the parent theme’s hook has already been executed. This allows for the focus to remain on the enhancements created by the child theme, rather than removing non-required features from the parent theme.
Thanks for your feedback regarding customising Canvas in particular via a child theme. 🙂
Cheers,
Matty.
I’d describe my apprehension more like, “Fear of what doesn’t always work that well”
For example, the last time I tried to child theme Canvas it was a nightmare of stylesheet problems. Mostly due to the “in-line” styles that the theme inserts from the admin area.
I like child themes when they save me time and make my life easier, but depending on the parent theme, that is not always the case.
You guys have some butt-kicking themes going on. Man, and I thought OP was cool… I’m definitely going to have to invest in a Woo Theme for my next site. The functionality is simply unmatched. No wonder so many high level marketers are using your stuff. Glad to see you’re constantly striving to raise the bar.
Best,
Brad