Theme repository reviews

[greenshady]

I've been thinking of pulling my current theme from the WP theme repository and not adding future themes to it. The "must do" and "must not do" parts of the guidelines are starting to get ridiculous. And, I either have to tell the theme review team how to fix something with the broken uploader or go through a long and grueling process just to get a theme updated every single time I upload a new version of my theme. I'm not exaggerating either. Every time.

Don't get me wrong. I understand why guidelines exist, but it always seems that theme developers have to jump through hoops to please people. A plugin update on the repo takes no more than 15 minutes (there is no "plugin review team"). A theme update takes 1 - 2 weeks for me.

I don't want to seem like I'm "above" anyone else, but it would seem like some people that've been around the community a while and have proven their trustworthiness should, at the very least, have Subversion access to their themes. Of course, I was basically told at one point that theme developers aren't smart enough to use Subversion, which is why they use a zip file upload system.

Have any of you had similar experiences with uploading a theme? Or, is it just me?

Also, do any of you guys/gals know how to build in an upgrade system from a separate site?

[JLeuze]

I can understand why they would want to make the easier for theme developers to upload themes, and have more safety measures in place since the learning curve is lower for themes than plugins.

But theme developers should definitely have SVN access if they want it. I don't even really think you should have to prove yourself, having your theme vetted the first time should be good enough, just like plugins. Makes sense not to give access automatically if most of the developers won't know how to use it. But if they take the time to learn how to use SVN, and ask for access, that should be enough of a barrier for entry.

I haven't contributed any themes to the repository yet, but now that I have sucked it up and figured out SVN to contribute a plugin, I know I'll have a hard time making the switch to the theme system.

As much as it is realistic, I'd like to see themes and plugins treated the same.

[chipbennett]

I appreciate your frustration; it is only natural, with such a drastic change has has been implemented with the new Theme Review guidelines. The Theme Review team has been open since, what, June? We've been ironing out the Theme Review guidelines since that time, and continue to refine them.

If you have issues with specific Review guidelines, please bring those issues up with the Team. We're only human, and only doing the best we can. There are only three or four of us who are really active with keeping the Review Team activities rolling.

We're also open to feedback and constructive criticism. So, what specific guidelines do you consider to be ridiculous, and why? Maybe I can help explain why a particular guideline exists, or maybe you can convince us to revise the Guidelines.

[dstrojny]

Thanks for bringing this up Justin, I have been experiencing similar issues since the switch to the new theme review process. It has been very frustrating to say the least.

I submitted a minor theme update and it took nearly 3 weeks to get reviewed. A little long, but I knew the system was new, so no big deal. The update was rejected, and fixes were outlined by the reviewer.

We made the required fixes, re-submitted, and waited another 2 weeks. To my surprise, the update was rejected again for different unrelated reasons that weren't even brought up in the first review. This was really frustrating, as we weren't aware of these issues until the second review. Not to mention some of the issues raised weren't in the official published guidelines. I think there needs to be a better system, maybe keeping the original ticket open so the next reviewer can see that the original problems were fixed?

At this point I haven't submitted any new theme updates to the repository because I don't want to deal with the back and forth hassle of getting the theme reviewed and accepted. I completely agree that there has to be an easier way and providing SVN access for updates would certainly help speed up the process.

[chipbennett]

I can understand why they would want to make the easier for theme developers to upload themes, and have more safety measures in place since the learning curve is lower for themes than plugins.

But theme developers should definitely have SVN access if they want it. I don't even really think you should have to prove yourself, having your theme vetted the first time should be good enough, just like plugins. Makes sense not to give access automatically if most of the developers won't know how to use it. But if they take the time to learn how to use SVN, and ask for access, that should be enough of a barrier for entry.

I haven't contributed any themes to the repository yet, but now that I have sucked it up and figured out SVN to contribute a plugin, I know I'll have a hard time making the switch to the theme system.

As much as it is realistic, I'd like to see themes and plugins treated the same.

I'd like to see Theme developers have SVN access also, but that's not a battle worth fighting right now. If you want to know why, take a stab at reviewing some Themes. The quality is all over the place, lots of SEO/spam links, non-GPL-compatibility, etc. I'm pretty sure that Joseph Scott has had to be the gatekeeper for so long, against so much undesirable Theme content, that it's not even worth trying to fight the SVN-access battle any time soon.

Ironically, the new Theme Review process could actually help. If enough Theme authors understand the expected quality standard, and begin submitting enough Themes that meet that standard, maybe the powers-that-be would be more amenable to softening their stance.

[chipbennett]

[double post]

[chipbennett]

Thanks for bringing this up Justin, I have been experiencing similar issues since the switch to the new theme review process. It has been very frustrating to say the least.

I submitted a minor theme update and it took nearly 3 weeks to get reviewed. A little long, but I knew the system was new, so no big deal.

In fact, the issue was the backlog. The Review queue was about 100 Themes, with about 10 per day being submitted. It was a huge hole to dig out of. (Thanks mainly to the heroic efforts of one reviewer, we're mostly back on top of things. But, even now, we have only 3-4 active reviewers.)

The update was rejected, and fixes were outlined by the reviewer.

We made the required fixes, re-submitted, and waited another 2 weeks. To my surprise, the update was rejected again for different unrelated reasons that weren't even brought up in the first review. This was really frustrating, as we weren't aware of these issues until the second review.

The Guidelines are in pretty decent shape now. They weren't terribly easy to follow, but we put a lot of work in late last week and over the weekend, making the Theme Review Codex page more straightforward.

One thing we're trying to make clear, though, is that it is the Theme developer's responsibility to ensure the Theme complies with the Guidelines, whether or not a Theme reviewer points out all of the issues. (In fact, most reviewers will fail a Theme once it has failed a minimum number of criteria (usually 5).

The reason that we have to take this stance is that FAR too many Theme developers are obviously using the Theme Review process to perform the quality control on their Themes that they are unable or unwilling to do - and that is a big part of why the review queue gets backed up.

Not to mention some of the issues raised weren't in the official published guidelines. I think there needs to be a better system, maybe keeping the original ticket open so the next reviewer can see that the original problems were fixed?

If you had a Theme failed for a criterion not in the Guidelines, please leave a comment on the Ticket, or email the Theme Review team, and we'll work it out. Again, the reviewers are only human, and subject to making mistakes.

I can't speak for all reviewers, but I *do* look at all previous Trac tickets for a particular Theme, when I begin a review. All tickets are available, and linked within any given ticket for any given Theme.

At this point I haven't submitted any new theme updates to the repository because I don't want to deal with the back and forth hassle of getting the theme reviewed and accepted. I completely agree that there has to be an easier way and providing SVN access for updates would certainly help speed up the process.

The fastest way to get a Theme approved is to make sure it meets all of the Guidelines, and to run it through the Theme Unit Tests, using the latest Theme Unit Test data. If you believe you are dealing with undue back-and-forth, please email the Theme Review team, and bring up the issues. We're happy to help.

Or, if you prefer, email me personally, or bring up your issues here. I'll do everything I can to help facilitate the process.

And thanks, again, for your patience. Reviewing Themes is a bigger job than most people probably realize.

[Jeffro]

A plugin update on the repo takes no more than 15 minutes (there is no "plugin review team").

Not yet at least:

http://lists.automattic.com/pipermai...st/034146.html

Who knows if that will ever happen. I like the Amazon review system for theme reviews as well. I no longer support the idea of having any teams that are dedicated to reviewing stuff that goes into the repositories. Leave it as open and get as many people involved as possible without assigning roles or what have you.

If review teams end up being brick walls, what good does that do anyone?

[greenshady]

My biggest gripe is that theme developers seem to be treated as second-class citizens when compared to plugin developers. I've actually developed more plugins than themes, so it's extremely easy to see how each group is treated differently. To be perfectly honest, if I wanted to screw around with your site or inject SEO spam links, I'd do it with a plugin before I would a theme. It's much easier to get away with.

If themes are such a huge problem, why isn't there a way for the community of users to get involved? Why not a "report as spam" button? Why not a "works / doesn't work" system like with plugins?

If the SVN battle isn't worth fighting at this point, I guess there's not much I can say about it. It would be nice if theme authors got access once their theme was initially approved.

I did sign up for the theme reviewers mailing list today. I'm not sure if I'll have time to participate but will try whenever I have free time.

Theme Review page

Most things here are treated as requirements as opposed to recommendations. I agree that most themes should follow these guidelines completely. However, there are some themes that simply do things a little differently because they extend WordPress even more than the norm. Trying to fit everything into this square box sometimes stifles innovation.

Some notes:

body_class() – (inside <body> tag)

My theme had a custom function for handling this long before WordPress did. Changing this could potentially break many sites. However, I have integrated the "body_class" hook into the theme function.

wp_nav_menu() - (replacing wp_list_pages, wp_list_categories, wp_page_menu, etc. as a menubar system where applicable)

Let theme authors choose how to build their menus. I agree the wp_nav_menu() is the better choice, but allow some freedom here.

get_header()

Consider themes with custom template hierarchies.

add_theme_support('automatic-feed-links’)

I agree this *should* be a standard but some themes may have a reason not to include it.

add_theme_support('post-thumbnails’) - (if the Theme currently uses a post thumbnail like feature, otherwise optional)

Consider themes with custom image systems.

get_sidebar()

Consider themes with custom template hierarchies.

post_class()

The same thing as body_class() above. My theme had a system for this long before WordPress did.

include( TEMPLATEPATH . '/file.php' ) - (use get_template_part() instead)

get_template_part() may not always be the best solution. Why would I need a wrapper for a wrapper for a wrapper of require()/include()? Why not just use locate_template()? In some situations get_template_part() just doesn't make sense.

Submitted theme must not include files named like the following:
* page-foobar.php
* category-foobar.php
* tag-foobar.php
* taxonomy-foobar.php

If I changed some of these things that have been a part of the theme before WP bulked up the template hierarchy, I'd literally break 1,000s of sites with a theme update.

Anything template-related also assumes themes don't implement custom template hierarchies.

Theme Obsolescence

If themes are in danger of this, we really need to take a look at the 10,000+ plugins.

[anmari]

@greenshady

Have you seen this post on providing updates for themes and plugins hosted outside wordpress ?
http://konstruktors.com/blog/wordpress/2538-automatic-updates-for-plugins-and-themes-hosted-outside-wordpress-extend/

I have not tried it yet but am considering.....

Be nice to know who whether many are doing this yet. I did see one crowd whose name I forget who clearly had an auto upgrade plugin for their premium plugins.