WordPress.org

Ready to get started?Download WordPress

Review WordPress Themes

Tagged: Child-Theme Toggle Comment Threads | Keyboard Shortcuts

  • Chip Bennett 3:26 pm on February 15, 2013 Permalink | Log in to leave a Comment
    Tags: Child-Theme, ,   

    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:

     

    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 | Log in to Reply

      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 | Log in to Reply

        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() vs get_stylesheet_directory_uri().

        • Srikanth 3:38 pm on February 15, 2013 Permalink | Log in to Reply

          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 | Log in to Reply

      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 | Log in to Reply

        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 | Log in to Reply

          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 | Log in to Reply

            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() to get_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

              There are just random stylesheets applied after the so called style.css where the child theme can’t take over the restyling

              The only thing that we’d need to worry about is if the child theme’s style.css is 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.

              or there is a router responsible for managing the template generation.

              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.css be 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

              Justin, I do agree with you, but most people expect that a child theme could override everything.

              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.

              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?

              1) A child theme must be able to overwrite any parent theme template (not any file, just templates).

              2) A child theme’s style.css file must be loaded using the get_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 | Log in to Reply

      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 | Log in to Reply

      Just grabbing my mailing list reply …

      Those guidelines look fine.
      I like the idea of how a “basic” Child-Theme is spelled out, and I think you covered the use of the the `template` versus `stylesheet` usage.

    • @mercime 5:48 pm on February 15, 2013 Permalink | Log in to Reply

      You got my YES vote :-)
      Thanks Chip.

    • Justin Tadlock 5:57 pm on February 15, 2013 Permalink | Log in to Reply

      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 stylesheet function 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 | Log in to Reply

        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.

  • Edward Caissie 3:00 pm on April 9, 2011 Permalink
    Tags: Child-Theme, ,   

    Child-Themes will now be considered for inclusion into the WordPress Extend Themes repository.

    Note: Child Themes are not currently being considered for inclusion in WordPress Extend.

    Please be sure to read the Theme Review process and guidelines; also, please note the additional Child-Theme guidelines before submitting a Child-Theme for consideration.

    Please note, although at the time of this writing the upload script may note the Child-Theme “fails” as the criteria used for Child-Themes is slightly different. If the Child-Theme did actually pass you would see at the bottom of the upload acknowledgement page a reference to the new Themes Trac ticket as well as receiving an email referencing the ticket as well.

    You will also be able to check the open status of the Child-Theme in this Trac report: http://themes.trac.wordpress.org/report/6

     
    • Andrew Nacin 11:23 pm on April 9, 2011 Permalink

      Please consider icing this proposal until further discussion.

      I don’t recall formal rules on this. This post was submitted for discussion only, and some of the points there had some extensive discussion in the comments. Some of those proposals shouldn’t make it into the guidelines.

      I’ve mentioned previously that we shouldn’t support child themes officially, until core supports them. Otherwise we’re going to confuse users. I’ve asked other members of the core team to weigh in further, as I’m pretty sure we’re in agreement on this.

      • Andrew Nacin 11:23 pm on April 9, 2011 Permalink

        until core supports them.

        Which, by the way, will likely possibly be 3.2. This can wait.

    • jane wells 11:24 pm on April 9, 2011 Permalink

      Hi guys. Actually, it’s pretty important from a ux perspective for us to wait on this until we have support for child themes in core (matching to parent, checking dependencies, etc). Please hold off on this, and bring it up at the next dev chat.

    • Otto 11:43 pm on April 9, 2011 Permalink

      Just weighing in to say that from the viewpoint of the themes directory code itself, it’s ready to go. We’ve tested it and the child-theme support there works. There may be a few tweaks, but no major changes are required. The only remaining question is regarding the support for dependency checking and such in the core.

      • Edward Caissie 12:00 am on April 10, 2011 Permalink

        This is the reasoning I relied on to go forward with Child-Themes in the repository; as well as the premise Child-Themes themselves should be as readily accessible in Extend as their respective current Parent-Themes are.

        • Emil 10:29 pm on April 12, 2011 Permalink

          So is this yey or nay for Children?

  • Frumph 9:10 am on January 24, 2011 Permalink
    Tags: Child-Theme, ,   

    Discussion – Child Themes on the Repository – Guidelines 

    1) Parent themes of child themes that are developed need to be made child-theme ready; proper use of where to find files with get_template_part, get_stylesheet_ and get_template_ functions.
    2) http://codex.wordpress.org/Child_Themes documentation is applied as part of the theme review process when checking child themes, all information is to be considered good practice and required, with addition to the theme review representation of license information.
    3) Parent themes of child themes submitted must have passed the current theme review guidelines for the current revision of WordPress, not if they have passed before, but specifically with the current revision of WordPress.
    4) Child themes are reviewed with the parent theme; must pass current theme review guidelines and associated child theme documentation.
    5) Recommendation to use the parent themes repository slug as the prefix to the child theme’s name. ex. easel-highsociety, atahualpa-wired, this is only the name of the theme & directory name of theme in the zip, not where to find the theme; even as found in the http://codex.wordpress.org/Child_Themes being part of the review process, this naming convention will stay a recommendation; however, declared best-practice.
    6) Description in the style.css must clearly state that it is a child theme example: “This is a child theme for the Easel theme.” – This is for redundancy of recognition that it is a child theme, even though other things will be noted on the repository that it is a child theme, this is for the wp-admin -> themes page for the end user.

    Additional For Developers:
    1) It is the responsibility of the developer of child themes to keep their child themes up to date with the current revision of their theme that is updated. If a developer make changes to the parent theme, it is the developers responsibility to keep the child themes updated as well.

    Changes, word usage, additional guidelines and protocols, as well as information regarding use of child-theme tag requested as part of this discussion.

     
    • Chris 10:33 am on January 24, 2011 Permalink

      Child Themes should / must use filters, hooks, and override functionality provided by the parent theme to change or extend the presentation of the blog content. Overriding the standard templates should only be allowed, if there is no other way to change or extend the presentation of the blog content.

      • Chip Bennett 2:07 pm on January 24, 2011 Permalink

        I think this should be *recommended* only.

      • Chip Bennett 2:37 pm on January 24, 2011 Permalink

        And along these same lines, we’ve batted around the idea of establishing some form of positive reinforcement/encouragement for Stand-Alone Themes that are designed with Child Themes in mind (making as much pluggable/hookable as possible) – not as a requirement, but as some form of recognition (e.g. a tag or other notice in Extend/Themes) that a Theme is “Child-Theme ready”.

    • Peter Westwood 12:16 pm on January 24, 2011 Permalink

      Question: How are updates to Parent Themes going to be reviewed?

      Ideally an update to a Parent Theme needs checking to ensure that is doesn’t break any of the child themes in the repository.

      • Chris 1:14 pm on January 24, 2011 Permalink

        I don’t think that the Review Team is able to handle this request. In addition, imagine a parent theme author embeds a needed change that breaks some or all child themes.

        I suggest to implement an additional version number to the child theme’s readme.txt similar to the ones used for plugins. This would declare that the child theme is compatible with a certain version of the parent theme.

        • Edward Caissie 1:39 pm on January 24, 2011 Permalink

          I’m liking this idea … add a header tag to work with “Template” such as “Template Version” representing the parent theme for which the child theme was developed.

        • Chip Bennett 2:26 pm on January 24, 2011 Permalink

          Great idea! A “Template Version:” header tag.

          What about something akin to the “Requires:” and “Tested Up To:” header tags, such as:

          “Template Required Version:”
          “Template Tested Up To Version:”

          • Peter Westwood 6:21 pm on January 24, 2011 Permalink

            This is an interesting idea – whatever is done though needs to go full circle through a review with the core team to ensure that it will fit in with improvements with the theme installer in core to support child themes.

            We don’t want to end up with too complex a dependency situation to resolve with core/theme/child theme versions.

            • Chip Bennett 8:16 pm on January 24, 2011 Permalink

              On one hand, those potential dependency issues are *going* to exist, if/when Child Themes are added to the Repository.

              On the other hand, I think it should be a given that Child Themes must adopt the *WordPress* “Requires:” and “Tested Up To:” versions listed in the declared Template Version.

              We certainly don’t want a Stand-Alone Theme tested up to WP 3.0.4 serving as a Parent Theme of a Child Theme that Requires WP 3.1. There’s definitely potential for breakage there.

            • Chip Bennett 8:27 pm on January 24, 2011 Permalink

              Westi, would it be possible to get some Mozilla-like enhancements to Extend? With Firefox extensions, the download link changes based on the FF version/Plugin version dependency, in order to make it obvious/more difficult to install a Plugin that is incompatible with the user’s version of Firefox.

              A similar model could work quite well for Plugin/Theme Extend.

        • Lance Willett 9:29 pm on January 27, 2011 Permalink

          Keeping it simple is the key: if it can be done with just “Template Version” that’d be best. If the version number in the child theme stylesheet doesn’t match the parent theme’s version, you know you have a problem. :)

      • Edward Caissie 1:44 pm on January 24, 2011 Permalink

        I would expect Child-Theme authors to “respect their elders” and be prepared to correct their works if a Parent-Theme creates an issue where their Child-Theme “breaks”.

      • Chip Bennett 2:10 pm on January 24, 2011 Permalink

        This request assumes that only the Stand-Alone Theme developer has also developed all Child Themes, which will almost certainly NOT be the case, since *any* Stand-Alone Theme can serve as a Parent Theme.

        It is unreasonable to expect a Stand-Alone Theme developer to be responsible for the maintenance/update of code that he does not own or control.

      • Lance Willett 9:27 pm on January 27, 2011 Permalink

        I agree that the burden of updating the child themes should be on the child theme developer. When submitting a child theme to Extend you assume responsibility to keep up with the changes in the parent. It *should* be as easy as following on RSS feed from Trac for the log of the parent theme (though adding a quick link to that feed from the Extend page might help).

    • Edward Caissie 1:51 pm on January 24, 2011 Permalink

      Other notes to consider for “Developers”:
      1) If a Child-Theme is not updated on a regular basis in conjunction with a Parent-Theme it may be subject to additional administrative actions; time-line to be established.
      2) If a Parent-Theme (for whatever reason) is required to be suspended, it can be expected all related Child-Themes to be, at a minimum, temporarily suspended.

      • Chip Bennett 2:12 pm on January 24, 2011 Permalink

        Bear in mind: a Child Theme may *never* need to be updated, especially if the Child Theme is merely a “skin” (CSS-only modifications).

        • Lance Willett 9:24 pm on January 27, 2011 Permalink

          CSS-only child themes could need updates just like any other theme as HTML structure changes in the parent or HTML elements are added or removed there.

    • Jonnya 7:09 pm on January 24, 2011 Permalink

      The popularity of parent/child theme construction is growing – and has many advantages over traditional custom theme design.

      In an ideal world theme developers would keep their parent and child themes up-to-date with each other. However this becomes an issue when you have third-party developers developing child themes – keeping version compatibility in sync becomes an problem.

      I guess the best way to drive this is putting in structure to handle the updates via the official theme repository – but one big thing to consider is minimum and ‘recommended’ versions when using child/parent themes. Recommended version would be updated by the designer (hopefully) soon after the framework update.

      Another suggestion would be to simply have additional information in style.css – this is the most logical place for users it as there is already the theme version held here, ie:

      Theme Name: My theme
      Theme URI: http://mytheme.com/
      Description: Description here
      Author: My name
      Version: 1.0
      Template: parent-theme
      Template minimum version: 2.32
      Template recommended version: 2.39
      Tags: tag1, tag2
      License: GNU General Public License v2.0
      License URI: http://www.gnu.org/licenses/gpl-2.0.html

      A final way is to set the values in the child theme’s functions.php – not so keen on that one for end users (and hey, very child themes may not even HAVE a functions.php!)

      I am actually creating something similar for a free, open source project I’m working on – once I have completed some functionality worth submitting I’ll certainly be posting up on the Trac. To me this is essential functionality if you want users to really use nice, simple child themes, with a great framework (sorry, child theme!) behind it that gets updated easily.

    • Emil 10:32 pm on January 24, 2011 Permalink

      This is pretty nice, however I would like to recommend that we do some kind of guideline, where the Parent Theme functionality is not changed, extended yes, but not unregistered via Child Theme functions.php. One of the reasons for this is, let’s say user likes everything on TwentyTen, but wants different look only. Maybe TwentyTen wasn’t the perfect example, but you got my point. This will also prevent major updates on children as well. (is not like they should be updated anyways).

      How about this too. Prevent Child Theme updates as far as the design goes? If parents are updated and children need some updates as well that’s fine, however let’s keep the same look. This will be better for users and knowing that the look they chose will not be changed in the future. If author wants new look, one more Child Theme is directory will not hurt anyone.

      What do you think?

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel