I’m going to be upgrading the /extend/themes bbPress install to bring it up to the same level of bbPress where the ideas and plugins and support forums are. This is to allow the login cookies to integrate properly across the whole site.
This means that parts of the themes directory will be non-functional or broken for short periods of time as I track down issues with it. These times should be short and as minimal as possible.
Theme pages now have a little “Theme SVN” link in their FYI box. This just gives a link to the theme’s SVN, for people that want to use it.
This is something several of the theme reviewers asked for, and it fits with the long term goal of allowing some theme authors the ability to directly update themes via SVN instead of using the ZIP file uploader. Encouraging SVN use is a good thing, I think.
That just lists all the versions, ala the ‘Other Versions »’ link on plugin pages. Shame it can’t be WordPress.org-ified rather than a simple listing though.
That’s what it’s supposed to do. The theme SVN isn’t organized like the plugin SVN, with trunk and tags and such. It just has one directory for each theme version.
So it could be pulled into a WordPress themed page then…
Rich: Given it’s a SVN repo, I’m not really sure it’s possible to style it like WordPress.org. That aside, as it’s a SVN repo, it’s not designed to look like WordPress.org 
On a site such as WordPress.org having unstyled pages like that is very un-professional. I still think the data could be pulled into a themed page, and even if it can’t I have seen better web front ends for SVN.
You can style the SVN web interface but I wouldn’t want to be the person writing the XSLT to do it – it’s not fun and you won’t make it look much better – I don’t see why it needs styling at all.
If you want to look at a pretty version of the code, then use the plugins Trac instead of browsing the directory via SVN. Or even better just use a proper SVN client.
The SVN repository isn’t really meant for browsing with your browser.
I think it would be worth a little XSLT to just put a note at the top, like “This is blah blah blah for the plugin’s page please see LINK or visit WordPress.org.”
This is welcome addition,
but I do think “trunk” folder should be given, that will be helpful when author modify theme code in response to theme-users support request.
Could we get the same thing for Plugins?
Plugins have had the SVN links in their Admin sections forever. Not sure it’s worth exposing them on the public side of things.
Not everyone has access to the admin section of every plugin.
I personally see SVN access for Plugins as more useful than for Themes. Every task is common between them however (Other than Theme review team stuff, but thats a not a normal front end task anyway). Allowing easier access to the SVN repo from the plugins page will help people who are not aware of SVN get into it at well, encourage them to use svn..
One of the first thing I do, and I’d hope other Plugin developers do, is open the plugins SVN repo and take a glance at the code, it’s what tells me if I’m going to atttempt to use it or not. That’d be my main use for it for Plugins (as well as for Themes).
erm plugins already have a link to the Development log in the FYI box. This was what I was referring to when I thought that the themes should match it.
Slightly off topic, but… It just occurred to me that the default vote for compatibility was for 3.1 at a time where it was not released. As much as I like the idea that one can vote on works/broken for the latest beta/RC, it seems to me that the vote should apply to the latest and greatest *released* WP version by default. (Or maybe it already is the case, in which case it’s not clear at all…)
i’m meaning for plugins, btw. But since you’re also worrying about that and I can only assume the same logic applies for themes, I figured I’d raise it here.
The theme uploader tool now performs a much more extensive scan of uploaded themes and gives the results back in a list format to the uploader. Hopefully this will allow theme developers to more easily fix problems with their themes and reduce some of the load on the theme review team.
Example of the resulting output (truncated). Note that I intentionally used a failed theme here, to show an example of what that looks like.
And so on. This is an improvement over the previous method, which just stopped at the first error found and didn’t give a whole lot of useful output. While that old system is still in place (for now), this one is there in addition to it and will give all the results for any theme uploaded.
Lol. Are you guys actually receiving “I created a new theme” spam? 
Not exactly, but the process for getting a theme approved was rather frustrating. The uploader checked for a number of basic conditions, but then only reported the first error. This made it hard to use because it became a process of upload, fix the problem, repeat until it goes through. And even then, the theme review requirements are somewhat more stringent. So I made this checker code to hit all the major points and provide a sort of feedback system, to allow theme authors to fix up their themes before uploading them. I wasn’t the first to do so, Pross had a fairly extensive checker system in place which I used parts of.
Could this be turned into a plugin for theme developers?
Great idea Otto. Being a theme developer, it will be nice to have a dev plugin to test all this before rolling out a new theme. Will Pross announce the plugin here once it’s available?
If he don’t, I will.
It’s actually available for use now. The Theme Reviewers make extensive use of it. As for if/when Pross plans to release the plugin, I don’t know. But, we actively encourage all Theme developers to make use of it!
Hopefully I’ll have something uploaded today
First version has been uploaded.
http://wordpress.org/extend/plugins/theme-check/
The output page is still pretty basic, but all the checks are run.
excellent, thanks for that.
While this is awesome, the screenshot you’ve attached shows wp_specialchars() and attribute_escape() being used in a backwards compatibility file.
Does this mean that themes are unable to use functions like this for backwards compatibility? (e.g. I can see a case where the theme author checks if esc_html() exists, and if not, maps to to wp_specialchars() )
Why support ancient insecure versions of WordPress?
Bingo!
Right now, we would (probably) make an exception for a Theme that provides awesome, thorough, and consistent backward-compatibility for a given WordPress version. Of course, I’ve yet to see such a Theme. Usually, it’s a one-off compatibility check.
This check system doesn’t currently prevent the upload from succeeding (although all the previous checks are still in place). I expect to make changes before making a “pass” on this a requirement. Discussion must ensue, and such.
I don’t think I’ve seen a theme that’s actually backwards compatible. Many will have a function_exists() check for things added in WP 2.3 then no compatibility check for something in 3.0.
These auto-search type scripts are ridiculous. I have a theme in review for weeks because of them.
I understand the deprecated function search, but why on earth are you blacklisting php functions like “base64_encode/decode”, fopen, and force use of comment-reply script? At least mark them as suspicious and make the theme reviewer check them manually for improper use, because some themes might actually have a good reason to use them.
This new tool doesn’t currently block anything from being uploaded. Feel free to discuss your concerns on the theme-reviewers mailing list: http://lists.wordpress.org/mailman/listinfo/theme-reviewers
Is the new theme uploader/reviewer available to download at all? It would be very helpful for themes that aren’t going to be uploaded to wordpress.org.
Are you going to improve the same way the plugin uploader. E.g.
a) screenshot page with no screenshots
b) recommended usage of all pages
c) using of deprecated functions (php or WP)
d) using of direct sql and not wp_query
e) not commenting functions
f) not using objects
g) using non translantable strings and not allowing translations at all
h) using very often problematic things like <?= in place of <?php echo
… and many other problems if they can be easily detected
No, there’s no plans to do plugin reviews in any way.
FYI, Daisy Olsen is going to head up the theme developer handbook. She’s started working on an initial outline/TOC. Anyone want to volunteer in advance to help with it?
I’ll volunteer in advance to be a sounding board for it.
I’ll volunteer to help with writing/editing or anything needs to be done.
I’m interested in helping.
I’ll volunteer to help Jane. My voice will be from a theme developer’s standpoint. Just let me know when and where.
I’m looking forward to seeing this project take shape. I look forward to working with you all
I would be more than happy to help. I would be happy to contribute anything that I can, and am also interested in ensuring that the handbook and the Theme Repository review guidelines are consistent with the handbook, and vice versa. But in any case, I’ll help in any way I can.
I can help, too. Editing, writing, etc. (I tried to post this comment yesterday – hope it didn’t end up in spam).
I would also be interested in helping – writing and/or editing. Please don’t hesitate to contact me.
I’ve been looking for a way to contribute. Please add me to the list of volunteers.
Count me in too. I can assist with writing/editing on anything theme related!
Theme filter searching now has an all/any selection box, for people who didn’t like it being exclusively boolean AND. See it here: http://wordpress.org/extend/themes/tag-filter/
This was in response to this tweet:
You’re my heroes Thanks so much for doing this. It will make theme searches so much easier and even more fun in some ways.
Next time either of you are in Portland, Oregon I owe you a beer (or three).
In preparation for 3.0, themes should wrap calls to next_post_link() and previous_post_link() in is_singular() conditionals if those functions are being used on index.php/archive views.
See #10867 .
Two big patches for 2.9 just went in.
[12025] by Andy Peatling allows themes to use register_theme_directory() to specify a wp-content-relative path containing theme directories. WP will additionally scan that. Primary use case is BuddyPress adding its themes without requiring copying.
[12023] by Viper007Bond enables smart embeds along with oEmbed support. For instance, to embed a YouTube or Vimeo video, just paste the URL in your browser on a blank line. It’ll grab the correct embed code for you. Much easier than wrangling with embed code vomit or remembering special shortcodes.
Writing up a post for my blog right now that goes more into depth on the new embeds feature, how to use it, how plugins can interact with it, etc.
Here’s the long post: http://v007.me/1a5
Nice article! Good to see the functionality of this in action
Sweet baby Jebus! I am just now finding out about oEmbed. Brilliant. Never would have occurred to me to look for such a thing.
Upgrading to trunk now.
Hat Alex for the built-in oEmbed.
We need to find someone to pick up the theme update and install work. The hookups to api.wp.org are already in. Much of the job can be done with a cut-and-paste of the plugin update and install code. Any takers?
If you need “little hands for little works”, I’ll be happy to give some help (with this or any other task you need)
Um, me? Ah crap, you also mean diff file changes and the like. That would be both challenging and a lot of fun. I’ll think about it after this week. If no one else jumps at it, then I’ll be riding that pony. It will be different from what I usually do with patching WordPress.
Joseph landed the first part of the themes update API.
wordpress.com style theme preview is in trunk
DH-Shredder are discussing. 
Denis, 
Jacob Santos, and 
DH-Shredder 5:59 pm on April 14, 2011 Permalink | Log in to Reply
Since this is work on bbPress specifically, it should only affect the front-end of the directory, and not the SVN repo, correct?
Otto 6:34 pm on April 14, 2011 Permalink | Log in to Reply
The display and search capabilities of /extend/themes and the API calls from core will be temporarily affected until I can make the proper adjustments to them. Access to the SVN will not be affected.
DH-Shredder 7:05 pm on April 14, 2011 Permalink | Log in to Reply
Cool, thanks much.
Otto 8:24 pm on April 14, 2011 Permalink | Log in to Reply
This update is complete. Let me know if any bugs are spotted and I’ll correct them.