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 Guidelines, 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 are also weekly mentor meeting hours every Thursday at 18:00 UTC in #themereview

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Tammie 8:25 pm on April 18, 2015 Permalink |  

    Queue focus event

    A long time ago, we used to have as a team a day where people would get together on IRC and really tackle the queues. This was a great opportunity for people to really focus. We’re going to be bringing this back. This time, we want to really focus what people are doing.

    On Saturday April 25th, at some point pop onto Slack and focus your efforts on the queues. If you are a key reviewer or admin, your focus will be on the admin approval queue. This queue really needs our attention and to get that to zero would be amazing. Normal reviewers are welcome to join in this push, you will be focusing on same queues you always do.

    I am going to take a screenshot of the number in each queue before the push, we can then look on the next day and see what impact we had.

    You don’t have to do the entire day, doing it for 3-4hours would really make a difference. Think of it like a remote contribution day session.

    I look forward to seeing everyone in Slack and those queues getting down.

  • Jose Castaneda 7:49 pm on April 14, 2015 Permalink |  

    Handbook Examples: Templates 

    Templates are a great way to make a theme unique and special. Making sure you are using the right one can tricky. This week let us focus on templates.

    Required: If used in theme, standard template files are required to be called using the correct template tag:

    File Template tag
    header.php get_header()
    footer.php get_footer()
    sidebar.php get_sidebar()
    searchform.php get_search_form()
    comments.php comments_template()

    If you have more examples, post them, share them.

    • Edward Caissie 1:30 am on April 15, 2015 Permalink | Log in to Reply

      Some nice template play to also keep in mind:

      get_sidebar( 'footer' ); will call sidebar-footer.php
      get_sidebar( 'header' ); will call sidebar-header.php
      get_header( 'single' ); will call header-single.php

      • Jose Castaneda 8:06 am on April 15, 2015 Permalink | Log in to Reply

        Yes! I almost forgot that you can also use a different location for the comments.php as well by using comments_template( '/inc/comments.php' )

    • Justin Tadlock 3:21 pm on April 15, 2015 Permalink | Log in to Reply

      There’s get_template_part() and locate_template().

       // loop-category.php, loop.php
      get_template_part( 'loop', 'category' );
      // loop-category.php, loop-archive.php, loop.php
      locate_template( array( 'loop-category.php', 'loop-archive.php', 'loop.php' ), true, false );

      I also wrote an extensive tutorial that we used to link to. I don’t think we have it linked anymore.

    • Justin Tadlock 3:25 pm on April 15, 2015 Permalink | Log in to Reply

      get_search_form() is a special case. It specifically outputs a search form generated by WordPress. A searchform.php template will overwrite that. And, a filter on the get_search_form hook will overwrite everything.

  • Tammie 5:26 pm on April 13, 2015 Permalink |  

    Weekly meeting agenda

    This week we’ve got our usual meeting at 18:00 UTC Tuesday (tomorrow) in #themereview. Our topic this week is:

    • Code examples. What can we do to make reviewing easier and clearer with regards to documentation?

    @jcastaneda hopefully you can make it as be great to have you update us as to what is going on with that. Alternatively, can you update us here in the comments.

  • Tammie 6:17 pm on April 7, 2015 Permalink |  

    Theme review team weekly notes

    The logs are here:

    We had a really short meeting as there was no topic. This is an issue we’ve had previously and was solved by getting topics. Lets do that again. I’m going to leave the comments here for people to add topics and issues they’d like to see brought up in meetings. In the past we’ve had a lot of success with this, but as a community we should all decide the direction so feel free to add your suggestions.

    Here are my suggestions:

    • Sub project status. What is going on with the doing_it_wrong theme? What is going on with the multilingual push?
    • Contribution days. We have the contribution pack up, but what now? How can we get it used beyond those of us in the community here so more days can have theme reviews?
    • Mentoring. We don’t have a solution. What can we do? Lets have actions, we all know it works so lets make strides to get that working.
    • Design emphasis. What was successful from our design challenge weekend (what wasn’t) and what can we do to push on with the focus on design?
    • Accessibility challenge. What is going on about building bridges between the two teams? How can we get more reviewers trained up to do accessibility reviews? Should we have a challenge weekend?
    • Learn-ups. We had some success with them during the design challenge weekend. Could we do more on different topics?
    • On-boarding reviewers easier. What can we do to make the first steps easier? Could we have hangouts? Could we have videos? What materials and things could we produce to make the journey easier?
    • Code examples. This is happening slowly, how can we form a group of people to really hit this and make sure we get a good example base?

    Ideally we’d also be looking for people to spearhead any initiative we mention. This is a chance for you to really take on a project and make an impact for the future of theme reviewing. Several people have done this and I’d love to see more take on projects and call them their own.

  • Jose Castaneda 9:26 pm on March 31, 2015 Permalink |  

    Handbook Examples: Stylesheets and Scripts 

    Let us continue with making some examples, shall we?

    This one will focus on scripts and stylesheets.

    No hard coding of scripts, styles and Favicons unless a browser workaround script. Everything should be enqueued.

    This does include the main stylesheet. I’ll start with a few:


    All stylesheets must be enqueued.

    add_action( 'wp_enqueue_scripts', 'my_parent_theme_css' );
    function my_parent_theme_css() {
        wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
        wp_enqueue_style( 'child-style', get_stylesheet_uri(), array( 'parent-style' ) );


    No hard-coding of scripts.

    <script type="text/javascript" src="<?php echo get_template_directory_uri(); ?>/js/theme-slider.js"></script>
    jQuery( document ).ready( function( $ ){
        $( '.slider' ).fancySlider({
            'autoplay': <?php echo get_theme_mod( 'slider-autoplay', true ); ?>,
            'navStyle': '<?php echo get_theme_mod( 'nav-style', 'circles' ); ?>',

    In the functions file:

    add_action( 'wp_enqueue_scripts', 'my_theme_slider_options' );
    function my_theme_slider_options(){
        wp_enqueue_script( 'theme-slider', get_template_directory_uri() . '/js/theme-slider.js', array( 'jquery' ) );
        wp_enqueue_script( 'theme-slider-init', get_template_directory_uri() . '/js/init.js', array( 'jquery', 'theme-slider' ) );
        // get user options
        $options = array();
        $options['autoplay'] = get_theme_mod( 'slider-autoplay', true );
        $options['navigation_style'] = get_theme_mod( 'nav-style', 'circles' );
        wp_localize_script( 'theme-slider-init', 'themeSliderOptions', $options );

    In the JavaScript file:

    jQuery( document ).ready( function( $ ){
        $( '.slider' ).fancySlider({
            'autoplay': themeSliderOptions.autoplay,
            'navStyle': themeSliderOptions.navigation_style,

    So, let’s share more examples and fill that handbook!

    • Frumph 10:27 pm on March 31, 2015 Permalink | Log in to Reply

      There’s a reason for hardcoded stylesheet’s to be placed first (ref: get_stylesheet_uri() – because you cannot specify placement in the enqueue’ing of scripts and CSS is a top down execution order interpreter. Without the ability to properly specify what comes first then you will never know if one thing is going to override the other.

      • Ulrich 7:22 pm on April 1, 2015 Permalink | Log in to Reply

        You can define the order of the scripts by defining the priority in which you run the action.

        This will run before most other styles: add_action( 'wp_enqueue_scripts', 'my_theme_slider_options', 9 );
        This will run after most other styles: add_action( 'wp_enqueue_scripts', 'my_theme_slider_options', 10 );

    • ArnaudBan 7:07 am on April 1, 2015 Permalink | Log in to Reply

      The third parameter of wp_enqueue_style() is a dependencies array :
      “Array of handles of any stylesheet that this stylesheet depends on; stylesheets that must be loaded before this stylesheet. false if there are no dependencies.”

    • Justin Tadlock 5:24 pm on April 1, 2015 Permalink | Log in to Reply

      The “no hard-coding of scripts” is partially incorrect. This is the part we don’t allow:

      <script type="text/javascript" src="<?php echo get_template_directory_uri(); ?>/js/theme-slider.js"></script>

      This is perfectly OK:

      jQuery( document ).ready( function( $ ){
          $( '.slider' ).fancySlider({
              'autoplay': true,
              'navStyle': 'circles',
      • Jose Castaneda 8:41 am on April 4, 2015 Permalink | Log in to Reply

        True, I was using a super simplified example. There are times when it requires more than, say, 30 lines.

        • Justin Tadlock 7:19 pm on April 5, 2015 Permalink | Log in to Reply

          No problem. I just want to make sure we’re not causing any unnecessary confusion.

          • kevinhaig 10:23 pm on April 14, 2015 Permalink | Log in to Reply

            Why is the top one not allowed and the bottom one allowed?

            • kevinhaig 10:26 pm on April 14, 2015 Permalink

              I thought it also applied to in line scripts (if that is the term)

            • Jose Castaneda 10:28 pm on April 14, 2015 Permalink

              Can remove it via hook.

            • kevinhaig 10:33 pm on April 14, 2015 Permalink

              Yep enqueue’ing is definitely the way to go.
              I know your slider example is just an example but it would make sense to me to enqueue that script as well because it would allow it to be removed if the user wanted a different slider(as an example).

            • Jose Castaneda 10:38 pm on April 14, 2015 Permalink

              it would make sense to me to enqueue that script as well

              And I wholeheartedly would agree with that. There are times when it makes more sense to hard code because it may be faster. A simple example is Twenty Fifteen:

              (function(html){html.className = html.className.replace(/\bno-js\b/,'js')})(document.documentElement);
            • Justin Tadlock 3:38 pm on April 15, 2015 Permalink

              The top one is not allowed because you must enqueue all script files via wp_enqueue_script(). This is so that they can be properly deregistered/dequeued or re-registered.

              The bottom one is merely some inline code. It should be hooked to wp_head or wp_footer in most cases. My reply above should’ve mentioned that.

              You wouldn’t want to add that small bit of code to an additional external file and enqueue it. That’d actually slow page load time with an extra HTTP request. It’s far better to just add it.

              What’s not OK with either is just dropping them in header.php.

      • Jami Gibbs 4:45 pm on April 15, 2015 Permalink | Log in to Reply

        Re: No hard-coding of scripts. What about IE conditional JS? For example:


        <script src="/js/html5.js”>


        Although maybe this won’t be an issue for long with work being done on JS IE conditional comments:


    • Mckilem 7:42 pm on April 8, 2015 Permalink | Log in to Reply

      “Don’t include any plugins. A theme can recommend plugins but not include those plugins in the theme code.”

      Does it mean that I can’t do something like:

      And then use something like “TGM Plugin Activation” to recommend PageNavi?

      • Jose Castaneda 7:48 pm on April 8, 2015 Permalink | Log in to Reply

        Keep in mind this doesn’t really pertain to the topic ( scripts and stylesheets ) but there are other ways of recommending plugins. TGM is an exception but the recommended plugins have to enhance the theme. You wouldn’t recommend a moving truck for grocery shopping, right?

        • Mckilem 8:13 pm on April 8, 2015 Permalink | Log in to Reply

          I know it doesn’t, but wasn’t able to find a topic where my reply would be more appropriate. Well, can I conclude by your answer that I can add pagenavi, since that would enhance the theme (better pagination)?

  • Tammie 7:19 pm on March 30, 2015 Permalink |  

    Weekly meeting agenda

    This week we’ve got our usual weekly meeting. I’d like to talk about mentoring in the meeting. Why it’s important and how can we make it so more of you join us mentoring?

    • Aaron Jorbin 4:00 pm on March 31, 2015 Permalink | Log in to Reply

      I think the decision to only require .screen-reader-text if a theme has the accessibility-ready tag should be revisited. [31388] makes the default output of comments_popup_link include this class. As this is now a core outputted class, having it be REQUIRED makes sense to me since we already require a number of WordPress-generated CSS classes be styled.

  • Tammie 6:04 pm on March 26, 2015 Permalink |  

    Theme review team weekly notes

    The logs are here:

    We talked about when a plugin should or shouldn’t use TGM. It should at least relate to the theme. But as usual, when in doubt cc one of the admins or ask someone in #themereview.

    @grapplerulrich is going to get the recommended tags up in the handbook – woohoo!

    WordCamp London happened and was a great success, join me in saying hi to all the new theme reviewers from the weekend. You are all amazing! I’ve tried to find you all, but if I missed anyone out please shout out in the comments. Looking at the assignment button (some others may get picked up) for Friday a big hello to:
    @carol-hayes, @BinaryMoon, @aloisia, @designituk
    A big thanks to all the existing reviewers that turned up and those that helped mentor the 26+ people in the room.
    @wcorner is going to spearhead a new incentive to make the handbooks English language make more sense. This will be covering all aspects of the handbook. I’m really excited as this means we get someone to review it and improve what we already do!

    If you’ve got a contribution day with theme reviews coming up just let me know and we can make sure to give it a shout out.

  • Tammie 3:48 pm on March 24, 2015 Permalink |  

    This week’s meeting will be at 18:00 UTC today. Let us know if you’ve got a topic you’d like covered.

    • Maria Antonietta Perna 3:56 pm on March 24, 2015 Permalink | Log in to Reply

      One topic I’ve got a couple of questions about is about the 7 days deadline, but perhaps it’s not suitable for a meeting, just a simple reply by the admins: is the deadline automatically enforced or is the reviewer supposed to close the ticket if it’s gone unanswered for too long by an author by closing the ticket? Do tickets left open for more than 7 days have an impact on queues? Thanks!

      • Tammie 3:57 pm on March 24, 2015 Permalink | Log in to Reply

        Reviewers should never close tickets, but you can notify admins.

        • Maria Antonietta Perna 2:53 pm on March 25, 2015 Permalink | Log in to Reply

          Hi Tammie,
          Thanks for your reply. I guess I can notify you. The ticket number is 23160 and it’s gone unanswered for weeks now. The author must know about the 7-day policy because he/she is not new to submitting themes to the WP.org repo. On the other hand, if the author decides to reply during a time when I won’t be able to follow up on my review, there will likely be one more orphaned ticket for the team, which wouldn’t be all that nice.

        • Arya Prakasa 6:19 pm on March 26, 2015 Permalink | Log in to Reply

          Whoops … I did that twice without notify admins :(

  • Tammie 3:56 pm on March 18, 2015 Permalink |  

    Join me in welcoming new key reviewers

    We all appreciate the great work everyone does with reviews. The admin team would like to today call out a few people specifically and say thanks by making them key reviewers.

    The role of key reviewer is given to people who have shown they consistently do amazing reviews. These are people who have proven over time they can be counted on as always delivering and have been consistent with their contributions.

    From the handbook:
    “People who are key reviewers are allowed to make themes live. These are an important piece to the theme review process, they make sure that the queues are kept low. In addition, you can guarantee they are a great source of reviewing knowledge as long standing reviewers.”

    We’d like to invite the following people to become Key Reviewers:

    Please join me in congratulating and welcoming these brilliant people to their new role.

  • Jose Castaneda 5:54 am on March 18, 2015 Permalink |  

    Handbook Examples: Language 

    Another round of examples, shall we? This one will focus on language examples.

    I’ll start it off:

    Required: load_theme_textdomain()

    add_action( 'after_setup_theme', 'my_theme_setup' );
    function my_theme_setup(){
        load_theme_textdomain( 'slug-text-domain', get_template_directory() . '/languages' );
    // if child theme
    add_action( 'after_setup_theme', 'my_child_domain', 11 );
    function my_child_domain(){
        load_child_theme_textdomain( 'child-text-domain', get_stylesheet_directory() . '/languages'
compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc