The WordPress theme directory was opened last July. It currently houses 700 themes and has surpassed 4 million downloads. For anyone that’s wondering, those are good numbers to be looking at if you’re a part of the WordPress community.
Now that the project has seen some success, it’s time to give the directory a much-needed upgrade.
When the theme directory launched, Joseph Scott wrote:
With the success of the plugins directory, we’ve wanted to have those same benefits in a theme directory.
But, the theme directory is missing some key components of the plugin directory.
What needs to be added to the theme directory
Uploading a theme right now is easy, but there’s a barrier that we don’t have with the plugin repository. With plugins, you simply type the name of your plugin, description, and optional URL. Once that’s done, you’re given access to the Subversion repository (usually within a day). You can upload and/or update your plugin at any time within 15 minutes.
With themes, you must upload a zip file and wait for someone to approve it within a day or so. This is done on the first upload and every update.
What happens if you made a mistake and want to fix it? You can’t update it in 15 minutes on the repository. You have to repeat the upload process and wait for it to be approved again.
Another useful thing missing is the ability to add custom sections to the theme’s page through the readme.txt file, which is also a plugin repository feature. Imagine how beneficial it would be to users if theme authors could add installation instructions and a FAQ to each theme’s page.
Quality control and Subversion
Subversion access allows us to quickly and easily update plugins. Plus, it helps us keep track of different versions. Judging by Scott’s post, I’m not sure Subversion access has ever been planned for themes.
We’ve gone through great lengths to make this as painless as possible for theme authors. You don’t need to know anything about Subversion.
To be perfectly honest, I’d rather not use a theme created by someone that couldn’t figure out how to use the Subversion repository. And, this sounds like a bit of a cop-out.
It seems they’re really telling us that they want to control the flow of themes through the site. They want to make sure themes carry that GPL license. Make sure they have all the suitable CSS classes and other such things that themes require.
There’s nothing wrong with a bit of quality control on the theme directory. In fact, I expect it.
Maybe the missing link is trust
There are better ways to control the quality of themes being shown on the site. For example, we could allow users to flag themes (plugins too) as breaking the rules or as not being good enough for the directory.
Theme authors have gotten a bit of a bad rep over the years. We first had the sponsored links predicament back in 2007 and the more recent purging of over 200 themes from the directory.
Basically, themes have been used to game the system.
One would think we’d be past that point. Allow the community to deal with the things that shouldn’t belong. Things of the past are hurting those of us trying to play by the rules now.
I really just want Subversion access
I’m not sure of the real reasoning behind the differences of the plugin and theme directory. I suspect it’s either that theme authors are seen as being too dumb to use Subversion or there’s no trust. If the former, I am deeply offended. If the latter, we need a better system.
It just feels like I’m stepping back into the Dark Ages anytime I need to update my theme on the repository.
What are your thoughts? Should theme authors be given the same access as plugin developers? Or, should the system stay the same? Are there any specific features you’d like to see added?
Also, has anyone heard any news on whether child themes are/will be allowed?
I’ve never used the new theme directory, so I’m really just going on what you’re saying here – it all makes sense, except for one piece:
Theme developers are not always the same people as plugin developers. The amount of technical knowledge required to put a theme together is relatively low – with the amount of free information out there on the topic, you can copy-paste yourself together a pretty respectable theme. Many theme designers are just that – designers. The value of a designer learning to use subversion is far lower than a coder learning to use subversion.
It sounds to me like subversion access is definitely necessary – if it works for the plugin directory, it should work for the theme directory – but I’m not sure requiring it is the right choice.
As for the community policing themes – that is right on. What good is open source software if they don’t grab every opportunity to use the community every way they can?
Peter — Never said it had to be a “requirement”. Just having the access would be a plus. I think the ability to simply upload a zip file is great for people that are just designers.
I’d really like to see some policing abilities for the community though. This needs to be something that’s not only for themes but site-wide. We can use the
modlooktag on the forums, but most people don’t even know about that.Control — those who have it, rarely want to give it up … especially to people they do not respect. And, like it or not, theme designers are on the low end of respect among the higher-ups of the WordPress Community.
Though, like you mentioned, theme designers have done enough in the past to earn a little of that distrust. I can’t say I blame anyone for putting us on a shorter leash.
I’m sure that many users would be happy if they just brought back browsing themes by tags/categories.
You’ve made some great points and I wanted to address some of them:
I think we clearly needed to come up with a different submission process for themes than for plugins. Requiring theme authors to use subversion would have made for a lot of unhappy theme developers.
Expanded sections for theme info is a good idea, likely using the same readme format that the plugin directory uses.
Requiring themes to have some level of review before being added to the directory is a fact of life at this point. Even with this process in place the number of themes submitted with spam links or with non-GPL compatible licenses is disappointingly high.
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.
That said I think the theme browser support that will be in 2.8 could go a long way in helping. Because the install process is hands free we could add the necessary information to ensure that both child theme and the parent theme get installed.
Nathan Rice — Yep, we’ve earned some distrust. According to Joseph’s comment, there seems to still be a high number submissions not following the guidelines now.
Robert — We can already browse by tags. Unfortunately, access to the page isn’t evident while on the theme directory.
Joseph Scott — Thanks for stopping by and addressing these points. I’m really hoping you all can implement the expanded sections for theme info. That would go a long way in helping out users.
I’m sorry to hear that you’re still getting a lot of themes submitted with spam links and such. I still stand by my point on giving the community more moderation tools for all parts of the site.
Glad to see some thought going into child themes. Nearly all of my themes are child themes, and I can see this growing even more in the next year in the community, especially with the backing of the theme directory.
I think the theme directory needs an upgrade altogether – backend and frontend. I think Justin raises good issues here, but they’re basically mute points.
I say this because if someone wants quality themes, they don’t go (or shouldn’t, at least) to the Wordpress Themes Directory. It’s hard to browse and navigate and isn’t categorized appropriately. Two-columns versus three-columns isn’t good enough, when you have 700 themes to go through.
If one wants really nice, quality themes they join a reasonably priced or free theme club like themehybrid.com
Once upon a time, there was an official subversion-based theme repository and it was a miserable failure, partly because the majority of theme developers (including myself, at the time) weren’t comfortable with the command line. While svn access would obviously be a godsend for serious developers, having two different upload methods could be very confusing for those who just want to share their Kubrick mods with the world. You may not have a problem with excluding those people, but the list of available themes would be substantially shorter without them.
The main problem with community moderation of themes is the potential for abuse. With the malicious flagging and downrating of themes that took place on wordpress.net, I’m not surprised Automattic are wary of allowing the community to police itself. Mainly, though, I don’t think they expect their users to be as vigilant about licensing and sponsorship as they are. Lots of people do use non-GPL and sponsored themes, after all; if they didn’t, nobody would bother making them.
Thanks for the interesting post. I have never created a WordPress theme or a plugin however, if I did I would not want to do it unless I had SVN access. I’m a designer and figured out how to use SVN on my own. It seems that anyone who is really serious about this business would be interested in all that SVN has to offer.
“Theme authors have gotten a bit of a bad rep over the years. We first had the sponsored links predicament back in 2007 and the more recent purging of over 200 themes from the directory.
Basically, themes have been used to game the system.”
Justin, I think you must be forgetting something here.
There is no way the second incident (purgin of 200 themes) can be said to reflect on theme developers. 
Matthew — Yeah, it needs an overhaul. I can’t really imagine being a user looking for a theme and trying to wade through 700 themes to find one I like.
James McWhorter — Glad to have some feedback from someone that’s just a designer. SVN isn’t really that hard. You don’t have to know the command line at all. I use Tigris myself. It’s basically point and click. Maybe if they hadn’t spoiled me with the ease of updating my plugins, I wouldn’t care to much about it.
demetris — Nope, I’m not forgetting anything. I meant exactly what I wrote.
If your smilies are meant to convey sarcasm (it’s hard to tell on the Net sometimes), disregard my reply.
[...] Tadlock, a notable theme developer in the WordPress community recently published his thoughts on why the WordPress theme repository is in need of an upgrade. Among his arguments is that the [...]
[...] The WordPress theme directory needs an upgrade – Justin Tadlock is unhappy with the last theme directory “upgrade” and asks for subversion access, which would provide better quality control within the theme directory instead of the lengthy submit-and-approve method. Good one. [Link] [...]
[...] The WordPress theme directory needs an upgrade – Justin Tadlock is unhappy with the last theme directory “upgrade” and asks for subversion access, which would provide better quality control within the theme directory instead of the lengthy submit-and-approve method. Good one. [Link] [...]
i like collect themes.
Perhaps I should have excluded the word “tags” in my previous comment. If someone searches for, for example, “1 column” and a theme is tagged “one column”… well, you get the picture. BTW, I did a test search for “one column” and the first 3 results were three and four column themes.
I really liked the drill-down search that was available a few years ago (columns, colors, fluid/fixed, etc.)
Well, in the latest nightly build of WordPress (Bleeding version of 2.8) You can search the theme repository by term, tag, or author. You also have a bunch of checkboxes which is reminiscent of the way you used to search for themes on the old repository. So, they are in a way, coming back.
[...] The WordPress theme directory needs an upgrade – Justin Tadlock is unhappy with the last theme directory “upgrade” and asks for subversion access, which would provide better quality control within the theme directory instead of the lengthy submit-and-approve method. Good one. [Link] [...]
Justin, you hit the nail on the head when you spoke of trust. Let the community determine what should stay and what should go by a voting system. Once a theme or plugin reaches a certain threshold of negative votes, it should be flagged for human review or simply removed. A more precise voting system could accomplish this rather easily assigning a scoring system to the negative vote received. For example, errors could cost 5 points while an unappealing design would cost 1 point.
“Also, has anyone heard any news on whether child themes are/will be allowed?”
I just recently updated two of my themes, both of which have a child theme included in a sub-folder. Both themes were approved with the child theme sub-folder included as is.
http://core.trac.wordpress.org/ticket/10626#comment:1
Redesigning org should also lead to changes in theme respiratory.
I think that all themes must have drop down menu installed and compatible plugin. i found just some themes with this feature.
A user-experience doesn’t seem too hard to think up for supporting child themes.
Child themes could be listed in the directory just like all themes, but the theme page would signify it as a child of X theme. Installing the child theme would work the same way as well. The only difference is that it would automatically install the parent theme as well (if it doesn’t already exist or upgrade it if it does).
I don’t even foresee see a QA problem. It would be the same for child themes as it would be for parent themes.
So the only thing the theme directory needs to change is automated checking of the style sheet to see if it has the `template` signification. In the case that it does, it attaches it to the existing parent theme. Then the theme pages need to have a section added to list child themes.
[...] in April, Justin Tadlock wrote a similar post that proposed several changes to the directory. Joseph Scott took some time to reply and address [...]