Child Theme Inclusion in the WordPress Directory

Before you get too excited, child themes aren’t yet in the theme directory. That’s what this post is aimed at achieving though.

For those unfamiliar with child themes, just take a look at this explanation of why and how to use them.

Just this week I released two child themes for Hybrid. Obviously this is my motivation for promoting the inclusion of child themes in the official WordPress theme directory. Though, I think this idea can greatly benefit the entire community. Today you won’t find any child themes in the directory because it doesn’t support theme yet.

Back in April, Justin Tadlock wrote a similar post that proposed several changes to the directory. Joseph Scott took some time to reply and address some of the issues facing his proposed upgrades.

Child themes pose an interesting challenge. In part because they can, at their own option, replace portions of the parent theme which makes automated testing harder. But perhaps the most difficult part to that puzzle is providing an easy experience for end users when they want to use a child theme. A number of people find it challenging to install a regular theme, adding another layer of issues for them to be aware of isn’t likely to help.

I’d like to expound on the problems and propose some specific solutions.

Problem: Testing and Approval

One of the problems brought up is that automated testing of child themes would be harder. I can’t really speak to this specifically since I’m not familiar with the automated testing that goes on behind the scenes, but here’s what I know is included in the automated testing:

  • Verification of certain style sheet requirements (i.e. theme name, version, tags)
  • Checks for the existence of a screen shot
  • Checks for the uniqueness of the theme name and directory name

Perhaps it checks for the existence of certain templates, but in the case of a child theme the automated checker could ignore that rule.

Other than that, I can’t come up with anything more that might be included in the automated testing. From my limited knowledge, those wouldn’t present any problems in the automated testing. The rest of the theme development checklist includes things that would need to be manually checked.

So, with a couple of minor tweaks (checking if the style sheet signifies a parent theme and possibly ignoring the existence of certain templates) I think the automated testing could easily be achieved.

Manual Approval

After a theme makes it through the automated process it moves onto manual approval. This process wouldn’t be any different than the existing process. In fact, child themes would probably present fewer problems than standard themes because they would likely adhere to most of the templates established by their parent.

Problem: User Experience

“perhaps the most difficult part to that puzzle is providing an easy experience for end users when they want to use a child theme”
–Joseph Scott

Indeed, this is a hard part. Especially since another point Joesph made was that lots of users still have a hard enough time understanding how to use themes in general. So let’s keep that in mind while I present some options to integrate child themes into the directory.

Redesigning the Theme Page

We’ll start with the parent theme and we’ll use Hybrid as an example. Essentially, we need to make Hybrid the primary theme and avoid the child themes dominating any of the UI. Since the theme pages already use tabs I figured we could add a “Child Themes” tab if any child themes exist.

Parent Theme

Clicking on the theme title or the screen shot would take you to the child theme’s unique page.

I think child themes should have their own pages. They would need their own page because they too would have their own “Stats” tab, ratings, and what “others are saying” section.

Child Theme

Of course a reference to the parent theme is necessary so a simple information box should suffice.

This is where the user experience complications begin.

Notice the “Download” button has a note that the parent theme will be included in the download. This prevents anyone from downloading a child theme, uploading it and being confused as it why it doesn’t work. There’s one foreseeable dilemma here. If someone downloads a child theme, uploads the child and the contained parent theme and unknowingly overwrites an older version of the parent theme there may be compatibility issues. I don’t see any way around this, but I wouldn’t say its a deal breaker. More on this in the next section…

Automatic Installer

Installing from within WordPress presents another issue. The installer would need to check if the parent theme exists. That should be easy enough. If the theme exists then skip installing it, however, what do we do if an older version exists? Do you prompt the user with an option to upgrade the parent?


  • User installs the child, upgrades the parent, but the child theme isn’t compatible with the current parent version
  • User installs the child, skips upgrading the parent, but the child theme is dependent upon the latest version

I’m actually stumped on this one. I could really use some ideas here.

Summing it Up

The inclusion of child themes in the official WordPress Themes directory is good idea because it gives themes greater flexibility and makes theme management easier for users. There’s a few problems to overcome before allowing child theme submissions into the directory, but nothing a little more brainstorming can’t resolve. I think with enough support from the community we could get this implemented rather quickly (who can even know what that means though?).

Update: Vote for this idea on

31 replies on “Child Theme Inclusion in the WordPress Directory”

Great writeup. To me, the things in the article aren’t the biggest obstacles. The biggest is to just get someone working on the project, making decisions, and moving everything forward. This post presents a step in the right direction.

I have to agree with Justin. Someone has to take care of this… But since should be community driven (or at least that’s the theory 🙂 — check wptavern’s latest post about this) — we should be able to do something about this.

I have 5 Child Themes released for Thematic and I would really make my day if they were included in the repository!

So with this in mind I’ve created this idea in the Ideas category:

So let’s twitt and blog about it!

Don’t forget to vote!

I agree that child themes should be included in the directory. Some of the best coded themes available are parent/child themes.

It should be easy enough for the brainiacs at Automattic to figure a way of checking existing version installed and prompting the end user to upgrade both if needed.

A quick compatibility check like they have when installing plugins that warn you if the plugin isn’t compatible with your current WP version. That script could be converted to check parent/child themes compatibility.

Make some noise I would love to see this added.

In a trac ticket about 2 months ago Jane Wells replies:

We’re just beginning an assessment of the .org site with the intention of redesigning to make it a more useful resource, including making access to themes and plugins much more prevalent and friendly. Will be setting up ways for community to submit suggestions and feedback once we’ve put together a short proposal on a re-org of the site.

Theres also some dicussion on child themes in this ticket:

Maybe its time for a child theme ticket for ?

An interesting topic for discussion, but something I did not read in this discussion is the testing for the parent theme’s existence / availability.

In its simplest terms, IMHO, a child theme simply imports another themes “templates” and carries forward. Therefore, any theme could be a “parent” not just the more well known “frameworks” such as Hybrid, Thesis, etc.

Now, for instance, what happens if a “parent” theme is suspended? Whose responsibility will it be to address all the child themes in the theme repository associated with it?

Just a thought …

You’re right, testing for the existence of the declared parent theme would be required. If one doesn’t exist then the child theme can’t be approved.

My guess at what would happen in the case of a suspended parent theme is that all child themes would be suspended as well, simple as that. More administrative functions would need to be added to the repository as well. If the parent theme is suspended it would be nice for the author, as well as all child theme authors, to get an email that the parent theme was suspended.

Good to see some ideas on what this process might look like. Aside from the theme directory side of things there are some issues for WordPress itself to improve (as you’ve pointed out) as well.

Only slightly related to this, child themes have a generation problem. You’ve got the standard parent/child theme relationship, what happens when people start doing grand-child themes (a child theme of a child theme)? It sounds funny but I can see people creating grand-child themes in order to preserve their changes to an existing (child) theme.

The grandchild discussion has been had in plenty already in fact. There’s certainly some validity to using a grandchild theme, but WP doesn’t need to officially support them in the repository.

Child themes were a great new feature of 2.7, and several versions later there’s not a whole lot being done with them. I say give child themes their chance and don’t even think about the grandchild theme “problem”.

I wonder if the WordPress core should be revamped. The idea of having to edit a theme is a troublesome one to begin with. We’re taught to never touch the source, but WordPress, without the concept of a Child Theme, forces it. Further, without carefully written themes and widgets like Hybrid Hook, folks are forced to learn PHP and edit themes all the time.

Wouldn’t an alternative solution be to redo the WordPress core to present the Header, Body, Loop, Sidebars, Footer, etc. with hooks already in them? Then allow a place, like the wonderful plugin mycss and a unique function template for people to write their own code.

Theme builders would actually write conglomerations of widgets with a default css template which the user would affect with their own unique codes. The widgets themselves could either replace WordPress core modules (like the terrible menu) or act as add-ons.

That’s really where Justin Tadlock and others are going with child themes. Maybe it would be more efficient if the WordPress core presented it.

The benefits to worrying about updates would then begin to go away as well.

[…] prediction is that before long the majority of new themes will be child themes. That is, once the WordPress theme repository supports child themes I think they will catch on quickly with developers and gradually gain users. The reason is simple. […]

I am willing to work for restructuring the theme repository of wordpress this year in GSOC, i really like your idea and am willing to implement it with some modifications.I’ll be really grateful if you could provide me with some more suggestions..:)

Yeah, I checked it out and I think its awesome. I don’t know any other ideas besides the ones I’ve written here though. I’m also going to do what I can to promote your proposal.

Leave a Reply

Your email address will not be published. Required fields are marked *