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

  • Jose Castaneda 12:39 pm on August 31, 2015 Permalink |  

    Meeting Agenda: September 1 

    Topics for discussion

    • Twenty Sixteen. Get it, test it, break it!
    • New and shiny for 4.3 ( favicons, singular.php, customizer )

    If you would like to add please comment below.

     

     
    • Justin Tadlock 1:57 pm on August 31, 2015 Permalink | Log in to Reply

      Discuss: Whether we should change our policy of 2 versions of back-compatibility to 3 versions. With the current pace of development, 2 versions is not even a year’s time.

      • Chip Bennett 3:04 pm on August 31, 2015 Permalink | Log in to Reply

        2 versions will generally be, at a minimum, 6 months – not including the pre-release period of the version that adds the functionality necessitating back-compat. I think that, for the vast majority of the cases, that should be sufficient time to update.

        I realize, though, that the real issue is end-user update lapses. I don’t think we should facilitate bad end user practices, either.

        My initial take is that we leave the policy as-is, and allow for one-off exceptions, as necessary.

    • Rami Yushuvaev 7:16 pm on August 31, 2015 Permalink | Log in to Reply

  • Justin Tadlock 12:17 am on August 28, 2015 Permalink |  

    Backward-compatible favicons/icons 

    As of WordPress 4.3, core includes a new site icon feature, which covers favicons and a few other icons. Now that it’s in core, it’s time to start phasing this feature out of themes.

    One of our guidelines is that themes should use core functionality where possible. Because this is now core functionality, new themes shouldn’t be adding this feature in.

    Providing back compatibility

    If you already have a theme that supports favicons, you’ll want to update your code in a way that doesn’t make users’ old favicons suddenly disappear, making for a smooth transition.

    The easiest method of doing this is first checking if the has_site_icon() function exists. This will let you know that the user is on WP 4.3 and has the site icon feature available.

    To make it even smoother, you can also check that the user has set up a new icon using the core WP feature. has_site_icon() is a conditional tag and will return TRUE or FALSE.

    Here’s a bit of example code to handle the check:

    if ( ! function_exists( 'has_site_icon' ) || ! has_site_icon() ) {
    
        // Output old, custom favicon feature.
    }

    Then, when WP 4.5 or so rolls around, you’ll be able remove the feature completely.

     
  • mantismamita 1:43 pm on August 27, 2015 Permalink |  

    4.3 Changes for Theme Authors and Reviewers 

    WordPress 4.3, “Billie”, was released last week, and includes some changes and improvements that will impact Theme development and review.

    New Template singular.php

    As of 4.3 there is a new template file available that will allow theme authors to use a common template for any singular post type. This specifically includes all custom post types including posts and pages. It follows the rules of is_singular() and comes after single-{post-type}.php, single-post.php, single.php, and page.php.

    Template hierarchy for singular post types, including the singular.php template file added in WordPress 4.3

    Template hierarchy for singular post types, including the singular.php template file added in WordPress 4.3

    Changes in the Customizer API

    Improvements to the Customizer API are continuing since 4.2. Most importantly, WordPress 4.3 adds Customizer PanelsFor further details see Nick Hasley’s article Changes to Customizer Panels and Sections in 4.3. Another notable change is  WP_Customize_Cropped_Image_Controlwhich allows images to be cropped to specific dimensions making it particularly suitable for logos. It uses the same functionality as the header image control.

    Please note that per the previously announced changes to the Theme review requirements, new themes must use the Customizer API for theme modifications rather than a settings or options page, and that existing Themes submitted for updates after October of this year must be ported to use of the Customizer API.

    Site Icon (Favicon) Configuration Added to Core

    WordPress 4.3 has added core user-configuration of Favicons (site icons). Previously, we allowed Themes to include Favicon functionality, provided that they were user-configurable, and disabled by default. Now, however, Favicons (site icons) are part of core, and fall under the requirement that Themes support core-implementation of core features. Therefore, new Themes will no longer be allowed to include custom Favicon options, and existing Themes that have Favicon configuration must move to support the core implementation when they are updated.

     
  • Justin Tadlock 6:49 pm on August 25, 2015 Permalink |  

    Title tag support now required 

    As of today’s team meeting, title-tag support is now required for all themes. We keep a back-compatibility policy of two versions, and the title tag feature was added in WordPress 4.1. So, we’re at that point.

    The team has put up a ticket to get this added to the Theme Check plugin, so it should be an automatic check with no need for manual checking from reviewers once it gets rolled in.

    This post is primarily a heads up for theme authors.

    Do I have to change my code?

    It depends. I think most new themes are already adding support. If not, you simply need to add a single line within your theme setup function, which would look something like the following.

    add_action( 'after_setup_theme', 'theme_slug_setup' );
    
    function theme_slug_setup() {
    
    	add_theme_support( 'title-tag' );
    }

    Removing back-compat code

    If you previously had code to handle pre-4.1 installs, you can simply remove it. That code would look something like this:

    if ( ! function_exists( '_wp_render_title_tag' ) ) {
    	function theme_slug_render_title() {
    ?>
    <title><?php wp_title( '|', true, 'right' ); ?></title>
    <?php
    	}
    	add_action( 'wp_head', 'theme_slug_render_title' );
    }

    Also, make sure the following is not in your header.php template:

    <title><?php wp_title( '|', true, 'right' ); ?></title>
     
  • Tammie 10:58 am on August 24, 2015 Permalink |  

    Weekly meeting agenda

    Our weekly meeting is on Tuesday at 18:00 UTC in #themereview. What shall we talk about?

    It’s good to every now and then have an open meeting so we can talk about anything that people want to. Lets do that this week. There is no set agenda so please add what you’d like to talk about in the comments.

     
    • Maria Antonietta Perna 12:38 pm on August 24, 2015 Permalink | Log in to Reply

      I’m not sure if this is an appropriate topic for a meeting, but I’d like to talk about the way themes abandoned by reviewers can be handled. As far as I understand, at the moment it’s up to a reviewer to pick a theme without any specific order. It’s possible themes stay there for months while themes added later but never abandoned by a reviewer could make it to the approved or even live themes list much sooner. This system seems to inadvertently penalize theme authors for someone else’ s actions (the reviewer’s). I’m aware it’s a difficult issue and perhaps one that will disappear once the new automated system of uploading themes is in place, but it’s affected me and a few people, so I mention it in case anyone else would like to discuss it too.

    • Nilambar Sharma 3:23 pm on August 24, 2015 Permalink | Log in to Reply

      Can we have a better `approved but not live` queue so that reviewer can give that link to developer after theme is approved? I believe Report 24 has some issues. Even after commenting or mentioning it in Slack queue order is changes which is not the expected behavior. Thanks.

      • Chip Bennett 4:37 pm on August 24, 2015 Permalink | Log in to Reply

        @Otto42 is there a way to display the timestamp of the state-change, either from “reviewing” to “approved”, or else from “open” to “closed”? I think we’d need a custom SQL query to generate a “closetime” parameter. But if we can do that, we can add it to Report 24, and sort by closetime. That would prevent the queue from changing due to new comments being added to closed tickets.

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