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?