WordPress.org

Ready to get started?Download WordPress

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 12:19 am on February 27, 2015 Permalink |  

    This week’s (a little late) meeting notes

    We met on Tuesday for our weekly meeting. This is every week at 18:00 UTC. You can find this week’s archive here:
    https://wordpress.slack.com/archives/themereview/p1424800773003737

    Notes:

    • @obenland came into talk about the theme directory which is being worked on over the next few days. It’s going to be exciting to see when done.
    • @davidakennedy came into talk about the accessibility pattern library. He’ll be doing a write up on this and we’ll post it here as a link too.
    • @greenshady whilst wasn’t there brought to our attention how important checking the history of a theme you’re reviewing is.
    • @ryelle brought up the important talking point of design feedback. We had a good discussion hearing a lot of opinions and reviewing what has and hasn’t worked of us in the past. We all agreed it was important and a long path, but we needed to start on that long path. @melchoyce will be starting us off with filling out the design section of our recommendations: https://make.wordpress.org/themes/handbook/review/recommended/design/. After that, we can look at next steps and keep this as a topic we come back to and keep important.

    Contribution days with theme review:

    This weekend will be a contribution day at Brighton and Hove, UK. There will be a theme review section there. http://www.meetup.com/WordUp-Brighton/events/218684194/
    Are you planning on holding a theme review session at a contribution day or a session on it’s own? Let us know and we can tell everyone about it.

     
  • Tammie 5:17 pm on February 23, 2015 Permalink |  

    Agenda for this week’s meeting

    We’re going to have a meeting this week at 18:00 UTC on Tuesday in #themereview on Slack.

    We have one topic so far:

    • Accessibility snippet library

    Add your topic below and we’ll try and get to it, however if we have to many we’re going to have to spread them over a few weeks.

     
    • Kelly Dwan 8:55 pm on February 23, 2015 Permalink | Log in to Reply

      • Expectations for commenting on tickets you aren’t “reviewer” on. From this twitter thread, I think we should be more explicit about how this is encouraged – for example, add a note somewhere on the handbook suggesting partial reviews for people with less time, or who aren’t comfortable doing a full code review.
      • Design standards for the review handbook’s recommended design page (could easily be a meeting on its own, i’m sure)
      • Tammie 9:00 pm on February 23, 2015 Permalink | Log in to Reply

        Good points – lets add those to the agenda and get some time on them. Thanks for bringing them up.

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

      Point of discussion: Reviewers need to be checking the previous ticket on theme update reviews for notes from the previous reviewer or admin. There have been several times where I’ve left notes for the theme author and next reviewer only to find out that the next reviewer didn’t check this.

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

      I’ll have to miss out on the meeting today. Have fun!

  • Jose Castaneda 10:01 pm on February 17, 2015 Permalink |  

    Handbook Examples: Functionality and Features 

    Last week we began with the code section of the handbook. This week let’s get some momentum and tackle: Core functionality and features.

    Functionality and Features examples:

    Example:
    There is no need to use
    add_theme_support( 'menus' );
    because register_nav_menu() does it behind the scenes.

    Example:
    Use core defined functions when possible
    So rather than using your own functions:

    function my_custom_cats(){
    	$categories = get_the_category();
    	$catOut = '';
    	$separator = ', ';
    	$catOutput = '';
    	if($categories){
    		foreach($categories as $category) {
    			$catOutput .= '<a href="'.get_category_link( $category->term_id ).'" title="' . esc_attr( sprintf( __( "View all posts in %s", 'text-domain' ), $category->name ) ) . '">'.$category->cat_name.'</a>'.$separator;
    		}
    		$catOut = 'Categories: '.trim($catOutput, $separator);
    	}
    	return $catOut;
    }
    

    Use a core function like the_category()

     
    • Justin Tadlock 10:35 pm on February 23, 2015 Permalink | Log in to Reply

      Use get_template_directory() rather than TEMPLATEPATH to return the template path.

      require_once( trailingslashit( get_template_directory() ) . 'inc/example.php' );

      Use get_stylesheet_directory() rather than STYLESHEETPATH to return the stylesheet path.

      require_once( trailingslashit( get_stylesheet_directory() ) . 'inc/example.php' );

      This example should come with an additional warning to check if the file exists first if not used in a child theme.

      Include comments_template().

      comments_template();

      Should be called in at least all singular views.

  • Jose Castaneda 7:30 pm on February 17, 2015 Permalink |  

    Chat Notes 

    Slack Archives: https://wordpress.slack.com/archives/themereview/p1424196039002725

    Topics:

    Queue

    • some improvement in last 5/6 months
    • button assigning

    Frameworks

    • can take long time
    • ‘sos’ checkbox ( looking at you #meta team )
    • education ( tuts and stuff )

    Child theme plugins

    • add support for plugin but not styling
    • not allowed
     
  • Jose Castaneda 8:38 pm on February 16, 2015 Permalink |  

    Chat Agenda

    Topic: Frameworks

    If you have any other topics you would like to discuss please post them here.

    Looking forward to seeing you there! Same time and place: Slack #themereview 1800UTC

     
  • Justin Tadlock 9:19 pm on February 10, 2015 Permalink |  

    Handbook Examples: Code Section 

    Beginning today, we will be discussing examples for the handbook requirements. Ultimately, these examples will end up on the Explanations and Examples page in the handbook.

    Each week, we’ll focus on various sections. This week’s section is the Code section. What we need from everyone is to provide examples in the below comments. The admins will round up the examples and add them to the handbook.

    Code section examples

    I’ll get us started with a couple of examples just to get the ball rolling.

    Required: Have a valid DOCTYPE declaration and include language_attributes.

    <!DOCTYPE html>
    <html <?php language_attributes(); ?>>

    Required: No shortcodes are allowed.

    The use of the add_shortcode() function is not allowed in themes as shown below:

    add_shortcode( 'shortcode_name', 'shortcode_callback_func' );
     
  • Justin Tadlock 8:57 pm on February 10, 2015 Permalink |  

    Custom CSS boxes in themes 

    Recently, we’ve had a big discussion over whether themes could allow users to enter CSS into arbitrary text boxes (custom CSS). There was some confusion over what was allowed and, if allowed, what would be the proper method of handling it. After much debate, we’ve come to the following conclusion:

    • It’s preferred that theme authors leave this feature to plugins.
    • However, it is allowed if handled safely.
    • The edit_theme_options capability is required (like all theme options).
    • The wp_filter_nohtml_kses(), wp_strip_all_tags(), or equivalent function must be used to sanitize the data before it’s saved into the database.

    Why leave to plugins?

    There are cases where it makes sense for custom CSS to be applied globally and to be applied on a per-theme basis. Generally-speaking, that’s a decision that’s best left up to the user, which they can decide based on the various plugins available for handling this.

    Validating CSS. Our guidelines are not going to require that theme authors validate the CSS. Our guidelines are only concerned with making sure the data is safe. That means that users could add in arbitrary code that’s not valid CSS. This means it’d be on you, the theme author, to handle the inevitable support requests.

    You are, of course, welcome to use a library such as CSSTidy to tidy the CSS up, but that’s a large library and probably best left in plugins. Just realize that the more complex your theme code is the harder it is to review and the longer it’ll take us.

    Edit: Another good reason to leave this out of themes is multisite. There are many instances where a site owner wouldn’t want everyone with a blog on their site to have this sort of CSS editing capability. Adding this option will most likely mean that a good number of multisite installs will never use your theme.

    Edit #2: To add to the multisite scenario, it might be worth considering using the edit_themes capability instead of edit_theme_options.

    How to do it correctly?

    I’m going to share an example of handling this correctly based on the comments from our recent discussion. This is only going to focus on the Customizer because it’s our recommended way to handle theme options.

    The following is example code to start from:

    <?php 
    
    add_action( 'customize_register', 'prefix_theme_customize_register' );
    
    function prefix_theme_customize_register( $wp_customize ) {
    
    	$wp_customize->add_section(
    		'prefix_section_1',
    		array(
    			'title'       => __( 'Section 1', 'prefix' ),
    			'description' => __( 'Section 1 description.', 'prefix' ),
    			'priority'    => 30
    		)
    	);
    
    	$wp_customize->add_setting(
    		'example_css',
    		array(
    			'default'              => '',
    			'capability'           => 'edit_theme_options',
    			'sanitize_callback'    => 'wp_filter_nohtml_kses',
    			'sanitize_js_callback' => 'wp_filter_nohtml_kses'
    		)
    	);
    
    	$wp_customize->add_control(
    		'prefix_example_css_control',
    		array(
    			'label'    => __( 'Custom CSS', 'prefix' ),
    			'section'  => 'prefix_section_1',
    			'settings' => 'example_css',
    			'type'     => 'textarea'
    		)
    	);
    }
     
    • Ryan Hellyer 9:03 pm on February 10, 2015 Permalink | Log in to Reply

      For anyone looking for an example of correctly handling CSS, I recommend checking out the Safe CSS plugin from Automattic …
      https://wordpress.org/plugins/safecss/

      It handles both CSS validation and sanitization. As Justin points out above, this does result in a rather large code base.

      • Ryan Hellyer 9:04 pm on February 10, 2015 Permalink | Log in to Reply

        I am referring here to how the data is handled BTW, not the UI which is best handled the way Justin described above.

        • Zane Matthew 12:47 am on February 28, 2015 Permalink | Log in to Reply

          So your saying the best way to store CSS is a custom post type? I’ve never thought of that approach, and would love to here what others have to say.

          • Justin Tadlock 12:22 am on March 1, 2015 Permalink | Log in to Reply

            I’d probably use a CPT myself if building this sort of plugin. It makes pretty good sense to me.

            Ryan is specifically talking about how the data is sanitized/validated from what I understand. How the data is stored is actually a separate matter.

    • Zulfikar Nore 12:48 am on February 11, 2015 Permalink | Log in to Reply

      Thanks for the example code Justin.

      Question: What would be the best method to escape the output?

      Zulf

      • Justin Tadlock 4:49 pm on February 11, 2015 Permalink | Log in to Reply

        Just hooking it to `wp_head()`? I’m not sure you’d want to escape it. If you’re allowing users to enter arbitrary code, you’ve given them a lot of rope to hang themselves with. Most of the escaping functions would probably break some CSS.

        I’ll give it some thought.

    • webriti 5:24 am on February 11, 2015 Permalink | Log in to Reply

      What’s the perfect implementation in case of option framework

      • Justin Tadlock 4:39 pm on February 11, 2015 Permalink | Log in to Reply

        The Customizer has been around for two years or so. It’s time to move on to using the core-supported standard for theme options. That’s my official recommendation.

        It’d really depend on which option framework you’re using, but you’d have to use the required capability check and one of the functions mentioned above to sanitize.

        • KProvance 12:08 am on February 20, 2015 Permalink | Log in to Reply

          Why? It’s sucks, and I’m not just saying that out of bias. It’s kludgy and incredibly difficult to code for. I get that the core devs think it’s the bee’s knees…and in some ways (live preview) it is, but as far as dev friendly, and easier for the user to understand. No. And I’ve been designing software for decades, so I know just a bit of where I speak.

          • Justin Tadlock 3:01 am on February 20, 2015 Permalink | Log in to Reply

            Standardization is probably the best answer as to why. I imagine TRT will one day require this for all theme settings. That’s the general direction we’re heading.

            If you think it’s not good enough yet, get involved. Create tickets on Trac. Post wireframes. Discussion on the TRT blog isn’t going to help. Involvement with core might.

    • nikeo 8:21 am on February 11, 2015 Permalink | Log in to Reply

      Thanks for sharing this @greenshady

    • nvartolomei 8:55 am on February 11, 2015 Permalink | Log in to Reply

      Why not leave this for children themes? If user knows what css is and what to do with it i think he can manage to understand what children theme is and how to customize it.

      Why do you need this in customizer?

      • Justin Tadlock 4:35 pm on February 11, 2015 Permalink | Log in to Reply

        I agree with that. Plus, a user could install a plugin if they really didn’t want to do a child theme.

        I also think there’s a case to be made for users who are just “getting their feet wet” and trying out CSS for the first time.

    • Stanko Metodiev 11:53 am on February 11, 2015 Permalink | Log in to Reply

      I’m glad that you’ve decided to not to restrict this option to the plugin territory. I my opinion if the user is administrator he/she can break his/her site in several other ways, so he/she should be able to add Custom CSS. Thanks for the code example, too! :)

    • Dovy Paukstys 10:25 pm on February 19, 2015 Permalink | Log in to Reply

      Disappointing I did all this work to modify my framework when you hadn’t reached a decision. Please don’t post on framework issue trackers before you decide your requirements. Reverting to what we had before so we can pass theme-check again.

      • Justin Tadlock 3:13 am on February 20, 2015 Permalink | Log in to Reply

        You were contacted after TRT had reached a decision. We just happened to later change that decision because I personally brought it back up for discussion on behalf of you and others with similar theme options. You were also given an opportunity to discuss this at the time here on the previous post.

        If you don’t want TRT to post on your issue tracker, you should not have it open to the public or allow people from our team to post on it. We will always take any steps we feel necessary to help theme authors and users, particularly when there’s a question of security involved.

  • Jose Castaneda 7:38 pm on February 10, 2015 Permalink |  

    Weekly Chat notes 

    Slack link: https://wordpress.slack.com/archives/themereview/p1423591238002102

    Topic: quality

    • example comments post ( @jcastaneda )
    • handbook examples

    Sub-topic: child themes

    • Thinking ahead:
      • Parent theme updated in 2 years
      • when to suggest fork

    Re: Custom CSS

    • theme territory, security is key
    • use proper capability check and sanitize
    • CSSTidy for validation
    • SECURITY
     
  • Jose Castaneda 10:40 pm on February 9, 2015 Permalink |
    Tags:   

    Chat Agenda

    Topic: Review Quality

    • brought up by @emiluzelac: https://wordpress.slack.com/archives/themereview/p1422989633001347
    • comments are valuable!

    Sub-topic: Child themes

    • brought up by @cais: https://wordpress.slack.com/archives/themereview/p1422989532001337
    • missing rules/requirements

    Looking forward to seeing ya’ll there! I’ll do a little housekeeping about ten minutes prior to the scheduled time. Same Slack channel ( #themereview ) and time 1800UTC.

     
    • Edward Caissie 2:13 am on February 10, 2015 Permalink | Log in to Reply

      I expect the usual schedule conflict(s) but will try to be at least available for the Child-Themes discussion.

    • Ulrich 6:00 am on February 10, 2015 Permalink | Log in to Reply

      I would love to have some input “How to review complex Themes and frameworks?”

      I have two themes that I am helping review/reviewing that are quite complex with a numerous classes and files. There are some complex settings frameworks too.

      With the large number of code it takes longer to do the review and it is more difficult. One needs to spend time understanding the logic of the code. What gets to me is that it takes a lot longer to do the review and then I am still a bit unsure if I have missed something.

      The goal of the discussion is to come up with a few suggestions how to review large chunk of code.

      • Carolina Nymark 11:16 am on February 10, 2015 Permalink | Log in to Reply

        I’m bitter atm hehe but “don’t submit code you don’t understand” should be a requirement…

        • Ulrich 12:12 pm on February 10, 2015 Permalink | Log in to Reply

          I understand, the two themes that I mentioned were most likely built from scratch and the theme author understands the code.

          Can we really restrict the complexity of the themes as we are unable to review them?

          How many hours should we spend reviewing a theme?

      • Jose Castaneda 1:03 am on February 14, 2015 Permalink | Log in to Reply

        I like it. The 17th is our next meeting. Can we get a list of frameworks to see how many there are. That way we can at least get an idea of what options theme authors have and see how we and others can tackle such frameworks.

        • Justin Tadlock 5:58 pm on February 14, 2015 Permalink | Log in to Reply

          I tend to think settings-page type frameworks are the most complex because they’re an additional layer on top of two existing core APIs that, while not perfect, get the job done and are fairly easy to use. Part of me really wishes that we’d force all theme authors to simply build their options via the customizer. Or, require PHPDoc and inline comments. :)

          I think a lot of the problem is that some theme authors never learn the WordPress core way of doing things. Instead, they learn the framework first. Most frameworks are created to solve some sort of problem, but without a true understanding of the problem, theme authors cannot figure out whether the framework actually does things that are suitable for a particular theme.

          I see this a lot with my own framework. People try to learn how to utilize it without understanding the issues that it fixes. Truth be told, many of them don’t need it for a particular project.

          If you can’t tell me how a particular setting you’ve created is being sanitized, for example, you probably need to spend some time learning the core APIs first. I see this all the time.

          Sorry, that turned into a mini rant somehow. All I really came here to do was list some of those frameworks. Here’s three off the top of my head:

          • Hybrid Core (this one’s mine)
          • Options Framework
          • Redux
          • Jose Castaneda 6:09 am on February 15, 2015 Permalink | Log in to Reply

            If you can’t tell me how a particular setting you’ve created is being sanitized, for example, you probably need to spend some time learning the core APIs first.

            Very well stated and I fully agree with that.

            A few I’ve seen:

            Keeping in mind that was also a quick search. I’ve seen one Option tree in the repo but can’t recall what theme used it.

          • Courtney Ivey 9:02 pm on February 16, 2015 Permalink | Log in to Reply

            > Or, require PHPDoc and inline comments.

            This. Right here.

    • Ulrich 12:19 pm on February 10, 2015 Permalink | Log in to Reply

      In the last meeting we came to the decision that we require themes to sanitize the CSS correctly and recommend them not to add the Custom CSS option.

      There are still a few open questions on the implementation. Justin gave a few suggestions: https://make.wordpress.org/themes/2015/02/03/theme-review-chat-notes/#comment-40876

      I tried to create a summary of all of the information.

      Sanitization – Require CSSTidy
      Escaping – What do we require here? Jetpack creates a file to display the CSS so
      Capability – Require use of `edit_themes`

      Possible Plugins:
      https://wordpress.org/plugins/reaktiv-css-builder/
      https://wordpress.org/plugins/jp-custom-css/
      https://github.com/jocastaneda/custom-csstidy

      Possible Frameworks:
      https://github.com/ReduxFramework/wp-custom-css-validation

    • Ulrich 1:52 pm on February 12, 2015 Permalink | Log in to Reply

      What do you think about creating a report for all of the themes that need a new reviewer?

      It should be possible to add a tag “needs-reviewer” manually. Here is a screenshot how it can be done.

      We could create a report with all the theme listed with the tag “needs-reviewer”.

      • Sakin Shrestha 7:35 am on February 19, 2015 Permalink | Log in to Reply

        @Ulrich: We need this soon

      • Tammie 11:15 am on February 19, 2015 Permalink | Log in to Reply

        I’m kind of not for this. Why? Because we already have queues and having another queue that simply says ‘needs reviewer’ when we already have a lot of tags and queues.. it’s adding to what we’re already trying to reduce. We got rid of the multi-queues because they didn’t work. It was a horrible first user experience and didn’t even really work for most longer term users.

        I first think rather than throwing a report we need to think what are we trying to solve that our existing reports don’t meet. I don’t see how this fulfills anything our existing ones can’t or don’t do. Another tag is another hurdle, another thing to do – we need less not more things. We already can shout out in Slack. Having a way that themers can shout ‘look at me’ and get above in the queue – that’s not awesome.

        If the intention (and the intention is a little foggy) is to flag that something needs attention.. well we already have that in slack. A report that has ability to shout more, well it’s just going to have more shouting.

        I’d be strongly against this report. To me, it is just another way of adding complication, of adding a way to shout more. Of adding something that we don’t need and a complexity that doesn’t solve the problem, just adds to it.

        Now, in strongly disagreeing with this I also recognise that there is an issue of ticket abandonment. There is also an issue of tickets being left without reviews. I think looking to solve those without adding yet another shouting mechanism or report is key.

      • Ulrich 9:11 pm on February 23, 2015 Permalink | Log in to Reply

    • Emil Uzelac 9:23 pm on February 23, 2015 Permalink | Log in to Reply

      The intention behind this is great, however it doesn’t solve the issue itself.

      Reassigning is actually lack of free time, that’s all.

      What could work and I am not sure if this can be done or not is to have some logic behind the button, where if there is no response from the reviewer within 7 days it can be automatically reassigned to anyone that requests a ticket from the button.

      I believe that this way we could solve a bunch with a single click ;)

  • Emil Uzelac 9:52 pm on February 7, 2015 Permalink |
    Tags:   

    New TRT Admin: Ulrich Pogson 

    Welcome Ulrich Pogson (@grapplerulrich ) to Team Review Admins!

    Ulrich started with WordPress back in 2011. He is a student, sportsman and WordPress developer with interests in responsive design and internationalization and that is not all: he is also Meetup Bern organizer and WordCamp Switzerland co-organizer.

    Thank you for your dedication Ulrich.

     
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