Child Theme Support
I have just added a draft section to the Theme Review Guidelines, to cover requirements for Child Theme support/facilitation for hosted Themes:
- Themes are required to facilitate the use of Child Themes. A “basic” Child Theme (i.e. a style.css with Template header tag and @import() of the Template style.css), when activated, should function exactly as the Theme itself functions.
- Themes are required to include functional and resource files in a manner that facilitates the use of Child Themes:
- Use get_template_directory_uri() to include functional files, or resources that are not intended to be included in/over-ridden the Child Theme.
- Use get_stylesheet_directory_uri() to include resources that are intended to be included in/over-ridden by the Child Theme.
Based on discussion on the mail-list, consensus appears to be that facilitating end user use of Child Themes is beneficial, so this discussion is the first step in incorporating Child Theme support into the Guidelines.
Please discuss. Do you agree/disagree that Child Theme support should be added to the Guidelines? Are the above Guidelines sufficient? What should be added/removed/changed? What about pluggable/filterable functions?
Srikanth 3:31 pm on February 15, 2013 Permalink |
I would agree with the above as required and anything else optional. Don’t want a lot of additional burden.
Chip Bennett 3:34 pm on February 15, 2013 Permalink |
Agreed. We don’t want to add onerous burden. We simply want to ensure that developers are accounting for Child Themes, which primarily boils down to proper use of
get_template_directory_uri()vsget_stylesheet_directory_uri().Srikanth 3:38 pm on February 15, 2013 Permalink |
Yes, Beginners like me would be happy to cater to new bloggers and leave the complicated stuff to heavy hitters
nofearinc 3:34 pm on February 15, 2013 Permalink |
Looks good to me. Maybe there should be an option for very large themes with ‘fat’ frameworks to explicitly warn people that due to theme options or anything else child themes are not supported, but the rule should be required as defined above.
Chip Bennett 3:38 pm on February 15, 2013 Permalink |
Do you foresee particular issues with Child Theme support with Themes that incorporate framework (i.e. code library) code? Is there any particular reason that such Themes should be exempted from this guideline? My initial reaction is that I don’t see any reason to allow for such an exemption, but I am always looking for unintended consequences.
nofearinc 3:51 pm on February 15, 2013 Permalink |
I’m just trying to be safe when a large framework (similar to PageLines) is getting ready to be released for free and reach hundreds of thousands of downloads and is self-sufficient (theoretically). It’s not 100% required, but sometimes the changes could take a significant time for a product that’s ready and working without a further need of files being changed.
Edward Caissie 4:04 pm on February 15, 2013 Permalink |
Within reason, if a “large framework” is being released and the Theme Author thinks its Child-Theme friendliness may be in question then perhaps it should be the recommendation to have some sort of documentation included / referenced to help alleviate any pain points.
I do not see any requirements for “exemptions” as the Theme Author (hopefully) knew what they were doing when they created and chose to release their “large framework” and within reason should have taken into account Child-Themes by default.
nofearinc 4:16 pm on February 15, 2013 Permalink
your ‘documentation’ was my ‘explicitly warn people’ idea. I don’t say it must be a rule, I’m raising the question for discussion as I’ve personally encountered themes that are not child theme compatible, working properly and switching between get_template_directory_uri/get_stylesheet_directory_uri is not enough. We could just drop that option and discuss again in the mailing list IF any theme falls in that scenario.
Chip Bennett 4:19 pm on February 15, 2013 Permalink
My concern there is: is this truly a special case, or did the framework developer simply fail to account for Child Themes? Is there some extenuating circumstance about the Theme that would preclude the use of Child Themes?
nofearinc 4:23 pm on February 15, 2013 Permalink
the simple case in point is:
1. a theme has already been built with numerous options
2. every popular option that most child themes cover (logo type/position, footer, credits, whatever) is covered by theme options
3. switching to get_stylesheet_directory_uri() is breaking the current design in a way that it’s not trivial to convert it (might take like a couple of days, or 2 weeks, for full compatibility).
Probably an edge case, but since usability and UX are trendy and more and more themes incorporate option frameworks, that doesn’t sound that absurd to me.
Chip Bennett 4:26 pm on February 15, 2013 Permalink
The part I’m struggling to grasp is: how does switching from
get_stylesheet_directory_uri()toget_template_directory_uri()cause breakage for a stand-alone (i.e. Parent, i.e. Template) Theme? For a stand-alone Theme (i.e. not a Child Theme), both functions return the same URL.So, any potential breakage would have to derive from some other development element/criterion on the Theme.
nofearinc 5:48 pm on February 15, 2013 Permalink
Chip, it’s not that it’s breaking the theme if you do the switch. There are just random stylesheets applied after the so called style.css where the child theme can’t take over the restyling or there is a router responsible for managing the template generation.
With that said, point 1 contradicts point 2, or rather executing point 2 won’t lead to a child theme support.
Again, it might be an edge case, there are just too many ways implemented in themes and frameworks out there for styling and template generation that are not fully compatible. We might reject all of them for that ‘freestyle’, the question is should we do it if it’s unlikely for people to ‘inherit’ it with a child theme.
Justin Tadlock 6:05 pm on February 15, 2013 Permalink
The only thing that we’d need to worry about is if the child theme’s
style.cssis loaded. The other stylesheets are irrelevant in terms of this discussion. They’re a part of the theme design. Nowhere is it required nor should it be that a child theme must be able to overwrite all elements of a parent theme.As long as the template are using the proper template-loading functions, I don’t see a problem here.
nofearinc 6:09 pm on February 15, 2013 Permalink
Justin, I do agree with you, but most people expect that a child theme could override everything.
We should leave all doubt out of the door and either set strict rules, or just elaborate on what could a child theme do. Does that make sense?
Chip Bennett 6:27 pm on February 15, 2013 Permalink
But we also require that all stylesheets other than
style.cssbe enqueued, rather than hard-coded. So, a Child Theme can always dequeue any subordinate stylesheets (or dynamic CSS functions, or scripts, for that matter).Justin Tadlock 6:38 pm on February 15, 2013 Permalink
Most of my users don’t expect a child theme to be able to override everything. I’ve been doing child themes a lot longer than most people here, and I can count on one hand the number of users who have asked about something like that.
1) A child theme must be able to overwrite any parent theme template (not any file, just templates).
2) A child theme’s
style.cssfile must be loaded using theget_stylesheet_uri()function.Both of these things are already covered under the Theme Review requirements, so we already have the rules in place.
nofearinc 6:42 pm on February 15, 2013 Permalink
I do agree with both last statements by Chip and Justin. The child theme can indeed dequeue if needed.
ZaMoose 3:39 pm on February 15, 2013 Permalink |
We should create aliases within the code for `get_parent_theme_uri()` and `get_child_theme_uri()` to adhere to the WordPress-should-be-read-as-close-to-English-as-possible goal.
Edward Caissie 4:05 pm on February 15, 2013 Permalink |
Just grabbing my mailing list reply …
@mercime 5:48 pm on February 15, 2013 Permalink |
You got my YES vote
Thanks Chip.
Justin Tadlock 5:57 pm on February 15, 2013 Permalink |
As far as I’m concerned, the guidelines already require and have required for a long time that themes be child-theme ready. We already require all functions and hooks to be used properly.
The only four functions you must worry about are:
get_template_directory()get_template_directory_uri()get_stylesheet_directory()get_stylesheet_directory_uri()If you’re using a
stylesheetfunction in your theme, you’re probably doing it wrong and shouldn’t pass the current guidelines. Of course, that’s a generalization, but it’s usually a good rule of thumb to go by.Chip Bennett 6:28 pm on February 15, 2013 Permalink |
I agree ,and I’ve made related comments in Theme reviews. Most of the time, the developer just didn’t know why one should be used rather than the other, and was happy to make the change.
This discussion is mainly an effort to formalize what you and I (and probably others) have interpreted from existing guidelines.