WordPress.org

Theme Review Team

Welcome to the Theme Review team.

We are a group of volunteers who review and approve themes submitted to be included in the official WordPress Theme directory.

The Theme Review team maintains the official Theme Review Requirements, the Theme Unit Test Data, and the Theme Check Plugin.

We also engage and educate the WordPress Theme community regarding best practices for themes.

Interested in joining the Theme Reviewers team?

Great! The team is open to anyone who wants to help out, and the process is simple. To find out more just visit the Join The Team page.

Want to know more? There is a more information in the Theme Review Team’s Handbook and the Review itself.

Once you get a theme to review, you will also get a mentor to help you on the road to becoming a theme reviewer.

Weekly meetings

We use Slack for real-time communication. As contributors live all over the world, there are discussions happening at all hours of the day.

We have a project meeting every Tuesday at 18:00 UTC in the #themereview channel on Slack.

There is also a second meeting temporarily on Thursday at 18:00 UTC in #themereview

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Tammie 6:44 pm on July 28, 2015 Permalink |  

    Theme review team weekly meeting notes

    The logs are here:
    https://wordpress.slack.com/archives/themereview/p1438106411001431

    • We have voted to allow themes to require temporarily the REST API plugin. If you want to make a theme that needs this, you can now do this and we will allow it in the repo. This is a one off exception as this is going into core.
    • @greenshady is working on tags and filters first for the directory.
    • This weekend is a queue push weekend. Key reviewers and admins lets get those admin approval queues down. Anyone else is welcome to dive into the review queues.
    • @jcastaneda is going to look at what theme check needs to auto approve new themes. What checks should be in there as a minimum?
    • Child themes came up and how to tell when something is ok or not to be one. We are all keen to not add more requirements at this time of change. As a result we will continue using judgement and cc’ing in admins. The ticket brought up is going to be updated by @greenshady.
     
    • CotswoldPhoto 8:45 pm on July 30, 2015 Permalink | Log in to Reply

      “This is a one off exception as this is going into core.” I am unsure whether such a bold statement has thus far been made. All previous comments have been more vague. Still, this still does not say when. Or am I wrong? Pointless thought. In core ASAP gets my vote. And this idea gets my vote x 10.

      • Tammie 8:59 pm on July 30, 2015 Permalink | Log in to Reply

        Not sure it’s bold really, we’re making an exception in this case. Could we have other exceptions at some point? I’m personally not against that but we’d have to have a team vote again. I also think it’s an exception, case by case thing for now.

    • Thomas Griffin 11:39 am on July 31, 2015 Permalink | Log in to Reply

      In regards to #1, I know there is a planned roadmap for TGM Plugin Activation as a feature plugin for core, and it does exactly the thing that you mention here. :-)

      https://github.com/TGMPA/TGM-Plugin-Activation/issues/447

      • Samuel Sidler 1:07 pm on July 31, 2015 Permalink | Log in to Reply

        While I know that it’s been proposed, there isn’t a “planned roadmap” from the core team for inclusion, just general discussion about dependencies.

    • Chip Bennett 2:18 pm on July 31, 2015 Permalink | Log in to Reply

      I missed the meeting, and I know the decision was unanimous, but I would like to late-register my vote AGAINST making an exception for the REST API plugin. I do not see the benefit of facilitating the use of an immature core API. I present a few examples:

      1. Post Formats UI (added during development of WordPress 3.6, but yanked at the last minute, at the Release Candidate stage – causing no small headache for Theme developers who were preparing to support the API in the final release of WordPress 3.6).

      2. Shortcodes API (never properly documented, leaving a wide-open implementation, that eventually resulted in some very upset users and plugin developers recently, when what was formerly a perfectly valid use/implementation was overnight deemed to be inappropriate, due to the security risks inherent in the implementation).

      3. Admin Pointers API (we still don’t allow Theme developers to use this API, because core has never formally opened it to “public” usage, and has not defined/documented its proper usage).

      I simply don’t think it is in our best interests – and more importantly, I don’t think it is end users’ best interests – to facilitate usage of an API that has not been matured in core. The API being mature and safe enough to reside in core should be a minimum standard.

  • Justin Tadlock 9:37 pm on July 27, 2015 Permalink |  

    Theme Directory: Tags/Filters 

    One of TRT’s new goals is focusing on improving the theme directory in a way that’s beneficial for users and theme authors. There’s going to be a bit of overlap between the directory and the review queue, but our primary focus here is on improvements to the directory itself.

    Because directory improvements are such a big undertaking, I thought I’d break things down into a few different posts. Today’s focus is going to be on the tags/filter system. Improving this would be an easy and major win for all.

    Based on the survey results, people tend to use the tag filter feature the most often to find themes in the directory.

    But, as we all know and what seems to be evident from the survey, tags need some major work. So, let’s make them better!

    Color tags

    The first order of business is probably dropping the “Colors” tags. These don’t seem to be used much.

    Based on the survey and an earlier discussion, it’s probably time to let go of these.

    Subject tags

    This is probably the biggest point we need to focus on. No one is using these tags to find themes, but I believe it’s because our subject tags leave a lot to be desired. Currently, we have three tags:

    • Photoblogging
    • Holiday
    • Seasonal

    There’s a lot of room for improvement there. I’d love to put together a solid list of subject tags. Take a look at what other theme directories outside of .ORG are doing. What can we learn?

    Other tags/filters

    Now is the time to offer up any ideas on tags/filters. I’ve only posted what I think is relevant from the survey about tags. If you have other ideas, let’s hear them.

    Other improvements

    I’m the point person on directory improvements. So, feel free to get in touch on Slack (@greenshady) about other things you want me to bring up for discussion.

     
    • Tammie 9:49 pm on July 27, 2015 Permalink | Log in to Reply

      Awesome to see this starting to happen. I’m excited about us making the directory really useful for people.

    • kevinhaig 10:44 pm on July 27, 2015 Permalink | Log in to Reply

      I agree on the colors. I don’t think Fluid Layout is required anymore, as themes seem to be fixed width or responsive. I also wonder if translation-ready is required as it is now in all themes. If I put on a user hat, I think some of the Feature items are hard to figure out. Flexible Header, Featured Image header, Threaded Comments, are a few examples. I wonder how much they are being used?

      Under Subject, I think Magazine Style, Corporate (or Business), Blog Focus would be good theme styles to add.

      • Justin Tadlock 12:03 am on July 28, 2015 Permalink | Log in to Reply

        There’s actually a bit of variety with layouts:

        • Fixed
        • Fluid
        • Fixed + Responsive
        • Fluid + Responsive

        Fixed does not necessarily mean non-responsive. I wonder if the average theme user understands the differences though. I started to bring this up in my post because, based on the survey, I’m assuming most users are looking for a “responsive” layout, even when they search for a “fluid” layout. Fluid layouts aren’t necessarily responsive layouts but they can be. Fixed/Fluid are pretty old terms that I don’t really think apply as much these days.

        I imagine it’s all a bit confusing and think we could make these tags a bit clearer for the layperson.

        • MRWweb 12:24 am on July 28, 2015 Permalink | Log in to Reply

          I agree that most users probably won’t get that. That said, as I reference in my comment below, it’s at least worth considering the “child themer” user group’s needs. Maybe there needs to be a “Technical Details” or “Advanced” section that would include things like Fluid, WP API, Microformats, and others we haven’t thought of yet.

    • MRWweb 10:55 pm on July 27, 2015 Permalink | Log in to Reply

      Some unrelated thoughts.

      1) I wonder if “Grid” is a new layout tag worth adding. I doubt it would apply to every template of a theme, but it’s definitely a frequent “look” to sites (home pages, blog pages, etc.) that people look for. “Single Page” might be another “faux-layout” tag worth adding.

      2) As a themer who is sometimes a user looking for well-built, easily-modifiable themes, I often find myself using some of the more obscure features as proxies for “detail-oriented” and “follows standards,” particularly Accessibility Ready, Editor Style, and Translation Read.

      3) I wonder if renaming “Subject” to “Niche” would be more useful. I feel like that’s the most common name for what I *think* the directory is going for.

    • Sakin Shrestha 2:57 am on July 28, 2015 Permalink | Log in to Reply

      Thanks Justin.

      It will be nice if we add more subject tags like:
      Blog, Magazine, Corporate, E-commerce, Photography, Portfolio

    • Torsten Landsiedel 8:06 am on July 28, 2015 Permalink | Log in to Reply

      There is a really long list for theme subjects on wordpress.com (just click on “Find a theme”:
      https://theme.wordpress.com/

      Feature tags should have some infobox (e.g. the question mark on the wordpress.com page) to explain the tags.

      And I would like to add a “no child themes” option.

    • NateWr 10:24 am on July 28, 2015 Permalink | Log in to Reply

      I threw together a quick Google doc with 4 spreadsheets that list search filters. They include Subjects/Niches/Categories, Features, Compatible With and Styles spreadsheet data for four large theme markets: WordPress.com, ThemeForest, MojoThemes, TemplateMonster.

      https://docs.google.com/spreadsheets/d/1GpJK6pMqVXXrKe66NMFjxyY9nwsHmuhm7IDrb6BtMjM/edit?usp=sharing

      If anyone from the TRT wants editing access just let me know via Twitter @NateWr.

      It might be worth reaching out to see if these marketplaces have and are willing to share data on which filters are most commonly used. WordPress.com is the only one that would probably be willing to share, but it’s worth a shot.

      I am particularly interested in whether ThemeForest’s “Compatible With” filters are commonly used. As I set out in a previous comment, I think the .org theme repository has loads of unique potential in its ability to link themes to plugins in the plugin repository, and vice-versa. That comment is here:

      https://make.wordpress.org/themes/2015/05/29/proposal-curated-theme-directory/#comment-41851

    • Carolina Nymark 12:45 pm on July 28, 2015 Permalink | Log in to Reply

      Are we set on sticking with ‘tags’? Are we set on sticking with ‘reviewable’ tags? During the brainstorming, one suggestion was to let theme authors add any ‘keywords’ they want.

      • Users love simplicity, do we need a list of checkboxes like today? I suggest keeping the number down in that case, or include them in an advanced search option.
      • I’m hoping for an improvement regarding the search.
      • Omaar Osmaan 3:23 pm on July 28, 2015 Permalink | Log in to Reply

        +1. There should be a ‘Filter’ list for features (limited, reviewable) and ‘Tags’ which authors are free to enter for theme keywords.

      • Justin Tadlock 5:15 pm on July 28, 2015 Permalink | Log in to Reply

        I think a set of standard tags is preferred. If not, we’ll end up with the mess in the plugin repo. I feel like we have a far superior filter system for themes because of the limitations.

        • Omaar Osmaan 3:42 pm on July 29, 2015 Permalink | Log in to Reply

          I agree about the ‘standard tags’, which I’ve refereed as ‘Filter’- a taxonomy for features (the existing tags system) that really helps to find themes with desired features. (Let’s call it ‘category’ of features, it should be limited and curated by admins)

          On addition to that, I think it’ll be great to have a author provided keywords per theme- which allows them to indicate the topic/niche and other ‘keywords’ as they see fit for the theme. (Let’s call it ‘tags’, authors are free to add any words for the tags).

          That two taxonomy system would be really helpful- one helps with finding desired features, another helps to define subjects, niche or whatever.

          The search system could also allows to combine both category and tags to refine searches. For example, I want a theme with ‘custom-header’ and ‘custom-background’ features for ‘travel’ or ‘magazine’ niche themes.

          The best part is that, there wont be needing much coding for this to implement- isn’t it? :)

          I think it would be awesome way to explore themes repo, really.

    • chriscct7 7:30 am on July 29, 2015 Permalink | Log in to Reply

      Personally I think the color tags could be useful, its just the way they are on the directory right now makes them useless. Let’s say I have a charity whose logo color is a particular shade of red and I want a theme that matches it. So right now I go to the theme directory and I pick red. That doesn’t help because there are so many shades of red the odds are I won’t find a color that matches mine.

      Here’s how it could be made way better. Instead of the color tags being attached to a theme by a person use one of this source libraries that feed the auto generated theme thumbnail into it and get a calculated color profile with the top 3 colors and their percents. Then you could implement a colorpicker on the theme directory page, perhaps via a select a color (or two) and then radix search through the themes listing themes with the highest percentage of the exact same shade followed by ones of a few shades.

      Now if I wanted to find a theme that matches my logo color I just pick the color from the colorpicker and boom, the perfect shaded (and relevant) themes first. No more searching through 10,000 shades of red.

    • Ulrich 8:43 pm on July 31, 2015 Permalink | Log in to Reply

      I would like to request we remove “blavatar”.

      We also have the “buddypress” tag. It would be great if we could allow themes to add the plugin slug as a tag to show that the theme supports that plugin e.g “easy-digital-downloads”

  • Tammie 4:08 pm on July 27, 2015 Permalink |  

    Agenda for this week

    We have a team chat at 18:00 UTC in #themereview tomorrow. Lets talk about the Roadmap parts 2 and 3. Lets all try and be there and really start thinking about the directory and new themes queue.

    To recap here are those parts:

    New upload flow:
    This new workflow would occur:
    Agree to terms/license (expanded content highlighting good citizen behaviour)
    Upload theme
    Automated theme check to reject or approve
    Approve and trac ticket made but theme gets made live
    Report button added to directory to allow user reporting
    A live ticket queue to be checked by reviewers
    A reported ticket high priority queue
    Ability to suspend themes from directory and remove completely
    Note: there is a lot in the above for all teams to be involved in. We should be adding checks to this workflow to report. That way we can add fixes and review what we are doing.

    Directory:
    Note: I am not saying design but focusing on functionality at least now. This should include better filtering, re-considering of tags, ways to highlight the best we have to offer, report button and anything else we can gleam from surveys is good for part one.

    https://make.wordpress.org/themes/2015/07/07/roadmap-for-phase-one/

     
    • Tammie 8:29 pm on July 27, 2015 Permalink | Log in to Reply

      We also need to talk about the REST API. I would like to suggest we make an exception until it’s merged into core that we allow themes in the directory to require it as a plugin. This would only be temporary and only for a case where something like this is going to merge into core.

    • Justin Tadlock 9:41 pm on July 27, 2015 Permalink | Log in to Reply

      I’ve started the discussion with tags/filters for directory improvements. That’s an area with some easy wins. I’m sure we’ll have a bit of feedback before the meeting.

    • Nilambar Sharma 3:02 am on July 28, 2015 Permalink | Log in to Reply

      It would be great if we could allocate some time in meeting for discussing about Child Theme. I am referring to this ticket. https://themes.trac.wordpress.org/ticket/25689 As we dont have clear guideline regarding child theme, it would be great if create a Make post or new section in our guideline. It would help reviewer in reviewing child themes.

    • Sakin Shrestha 3:09 am on July 28, 2015 Permalink | Log in to Reply

      This looks nice and I will be happy if theme gets live automated. So, that we don’t have to wait for months and months. But I don’t know how are we going to handle it all through automated checks. Here are some of the lists:
      1. Theme URL
      2. Author URL
      3. License Issues
      4. Accessibility
      5. Proper theme tags
      6. Tacking codes
      7. Not using appropriate data validation and sanitization

    • Emil Uzelac 5:15 am on July 28, 2015 Permalink | Log in to Reply

      Sorry, unfortunately I have a Dentist appointment tomorrow and won’t be able to attend the meeting.

      I did however went over my part as the point person for Reviews and queues (not making a post because @karmatosed and I didn’t think one was needed).

      This seems to be the most problematic and it’s divided into 3 related areas:

      1. Timeframe before the ticket is assigned
      2. Timeframe after the ticket is assigned
      3. Timeframe after the ticket is approved

      Second one can be reduced if we can do a complete instead of preliminary (partial) reviews and be as detailed as we can.

      One thing I don’t see enough is for us to include links to documentation (Codex) or examples, which can be extremely helpful. Folks tend to copy+paste Theme Check reports and leave under the impression that this will be enough.

      I personally use Underscores https://github.com/automattic/_s every time I need to reference something or to show proper examples.

      This will definitely speed up the process, eliminate the need of jumping back and forth on Slack and ask for further help.

      • Jose Castaneda 9:23 am on July 28, 2015 Permalink | Log in to Reply

        include links to documentation

        So much this!! When possible I think we should be linking to the developer docs as well. Codex could be a secondary option as well.

  • Jose Castaneda 11:19 pm on July 23, 2015 Permalink |  

    Theme Review Tools 

    From theme check to test data and beyond, we need to ensure our tools and future tools are the best they can be. This team could also begin looking at what future tools we need and could bring. It might do a lot of experimenting. This should also include the doing_it_wrong theme and any plugins that we may want to recommend in the future. SVN access would come under tools as this is tools for reviewers and those being reviewed.

    Currently recommended plugins:

    Doing it wrong theme:

    Currently recommended unit test:

    Environments:

    Editors:

    I’ve listed some editors because some of these are very WordPress friendly when it comes to development and debugging. Some offer the ability to do regex searches to make finding things a little easier and have support for WordPress functions, filters, and hooks.

    One thing I would like to see is the addition of some videos on the resources page. I think accessibility videos would be a great addition as well. I know the doingitwrong theme needs to be updated as well as the theme unit tests. If you would like to add, amend, please do so in the comments!

     
    • Emil Uzelac 11:31 pm on July 23, 2015 Permalink | Log in to Reply

      VVV ( highly recommended ) Why is that?

      • Justin Tadlock 11:37 pm on July 23, 2015 Permalink | Log in to Reply

        I’ve always used XAMPP. It’s easy to set up. Loads of step-by-step tutorials for beginners. Heck, you can download an .exe file and simply follow the setup wizard.

        No idea why VVV is highly recommend for theme reviewers. It goes from “Download this” to “WTF?” in like two steps.

      • Jose Castaneda 11:39 pm on July 23, 2015 Permalink | Log in to Reply

        Taken from the page. I use both VVV and XAMPP. :)

      • Omaar Osmaan 12:42 am on July 24, 2015 Permalink | Log in to Reply

        Never used VVV, looks like I should try it-

        I use Nginx/MySQL/PHP, I download latest versions and use custom config. It’s been ~5 years I guess. :)

        Recently found WT-NMP, I’m yet to test it but they made the process simpler. If you love Nginx, you may love it, too (for windows).

      • Tammie 8:59 am on July 24, 2015 Permalink | Log in to Reply

        VVV is listed as the recommendation because we have an excellent tutorial on it in the handbook from a contribution day. It’s often at contribution days the easier option – it really is. WCEU had it on a usb stick. Also, in a lot of getting started session it’s used as the example. I say this having done a lot of contribution days and setting up with people. We need to suggest the one but also show others – which we do. It’s by far the easiest thanks to that tutorial and it’s configuration to do in most situations we need.

        Ultimately, everyone will have their favourite. What is something you may use when further along isn’t something that suits someone at the start, and so on. We need to not confuse at the beginning of people’s journeys.

    • Justin Tadlock 11:31 pm on July 23, 2015 Permalink | Log in to Reply

      Here’s a language testing plugin I use. It can be useful when testing RTL languages as well.

  • Tammie 2:28 pm on July 20, 2015 Permalink |  

    Weekly chat agenda

    We’ve got a weekly chat tomorrow, Tuesday 18:00 UTC in #themereview on Slack. Lets talk about the roadmap.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel