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

  • 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.

  • Justin Tadlock 9:44 pm on August 22, 2015 Permalink |
    Tags:   

    Using theme mod defaults 

    As more and more theme authors begin to make the move to the customizer, many are also making the switch to storing theme options as theme mods rather than rolling a custom database option. This is awesome because theme mods have a bit more to offer.

    One of the common mistakes I’m seeing is not making use of the $default parameter of get_theme_mod():

    get_theme_mod( $name, $default )

    That second parameter is pretty important as you’ll see below.

    Common usage

    The following is some common code I see in themes.

    $example = get_theme_mod( 'example' );
    
    if ( $example ) {
    
    	echo $example;
    
    } else {
    
    	echo 'Some default';
    }

    While that’s not technically broken, it’s kind of clunky and can be handled so much more elegantly as shown in this next bit of code.

    echo get_theme_mod( 'example', 'Some default' );

    Yep, we just cut that down to a single line. No need for an if/else check or anything like that. You can let WP handle the logic behind the scenes.

    Basically, that tells WP to output the example mod. If that mod hasn’t been saved yet, output our pre-defined default.

     
    • HooThemes 1:09 am on August 23, 2015 Permalink | Log in to Reply

      Hi, I’m using options framework 1.9.1 : https://github.com/devinsays/options-framework-theme, before uploading my theme, I have used Theme Check Plugin tested it, it passed, but when uploading it to WordPress.org, It throws the error
      `
      Results of Automated Theme Scanning: Fail

      REQUIRED: class-options-framework-admin.php. Themes should use add_theme_page() for adding admin pages.
      Line 34: add_action( ‘admin_menu’, array( $this, ‘add_custom_options_page’ ) );
      Line 110: function add_custom_options_page() {
      `
      It looks the ‘add_theme_page()’ have been used correctly, but it can not be uploaded to WordPress.org.

      Please advice.

      • Chip Bennett 2:00 pm on August 23, 2015 Permalink | Log in to Reply

        As of a few months ago, you must use the Customizer (Customize API), rather than a Theme settings page (Settings API/`add_theme_page()`), for new Themes.

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