WordPress.org

Ready to get started?Download WordPress

Review WordPress Themes

Updates from Chip Bennett Toggle Comment Threads | Keyboard Shortcuts

  • Chip Bennett 1:22 am on July 9, 2014 Permalink | Log in to leave a Comment
    Tags: , sane defaults, , Theme Mods API   

    Using Sane Defaults in Themes 

    With the release of WordPress 3.9, one of the changes to the Theme Review Guidelines is that Themes must use sane defaults. That means that Themes must not write default setting values to the database. For many Themes, this may seem like a major change; but it doesn’t have to be. This post will step through a few ways to implement sane defaults.

    Portability/DRY

    To make this method easier, put all of your defaults inside a function:

    function themeslug_get_option_defaults() {
    	$defaults = array(
    		'option_1' => 'value_1',
    		'option_2' => 'value_2',
    		'option_3' => 'value_3'
    	);
    	return apply_filters( 'themeslug_option_defaults', $defaults );
    }
    

    (Note: by making the return valuable filterable, the Theme defaults can be easily overridden by a Child Theme or Plugin.)

    We’ll make use of this function later.

    Options API

    Most Themes use the Options API, and will use get_option() to put Theme settings into a global:

    $themeslug_options = get_option( 'theme_themeslug_options' );
    

    Knowing that this get_option() caall will return FALSE if the option has not yet been saved to the database, Theme developers have taken to saving default values to the database as part of Theme initialization, like so:

    if ( false == get_option( 'theme_themeslug_options' ) ) {
    	update_option( 'theme_themeslug_options', themeslug_get_option_defaults() );
    }
    $themeslug_options = get_option( 'theme_themeslug_options' );
    

    But this is entirely unnecessary. And everything needed to implement a better solution already exists.

    As a first step, consider that get_option() includes a second parameter, which specifies the default value to return, if nothing is returned from the database:

    get_option( $name, $default );
    

    So, the simplest solution is merely to tell get_option() to return the defaults, using the function we previously defined:

    $themeslug_options = get_option( 'theme_themeslug_options', themeslug_get_option_defaults() );
    

    This works, but isn’t perfect. It will return the Theme-defined defaults if the user hasn’t saved settings to the databse. But if later versions of the Theme add, remove, or change options, this might break, since the return value is either/or: either the database-saved setting, or else the defaults. So, if the user saves settings, and then a new setting is added in a later Theme version, the new setting value won’t be included in $themeslug_options unless/until the user saves settings again.

    The solution is to merge the arrays, rather than to return one or the other. WordPress has a core function specifically for this purpose: wp_parse_args(), which will use the settings array, and “fill in the blanks” with the defaults array:

    wp_parse_args( $settings, $defaults );

    Caveat: bearing in mind that wp_parse_args() expects both parameters to be arrays, and knowing that get_option() returns FALSE by default, be sure to specify get_option() returns an empty array by default: get_option( ‘theme_themeslug_options’, array() ); otherwise, wp_parse_args() will (might – see note below) choke if the user hasn’t saved settings to the database.

    The construct will look something like this:

    $themeslug_options = wp_parse_args( 
        get_option( 'theme_themeslug_options', array() ), 
        themeslug_get_option_defaults() 
    );
    

    This is perhaps the simplest, most elegant way to implement sane defaults.

    (Note: according to Otto, passing an empty arrayy() as the second parameter to get_option() isn’t necessary. In his words: “The wp_parse_args() function checks for the first parameter to be an object or an array. If it’s neither, then it calls wp_parse_str on it, because it can take a GET URL-like array of parameters too. The wp_parse_str() function calls PHP’s parse_str on it, and does a deep strip_slashes if magic quotes is on, then filters the result. So, because false maps to the empty string, parse_str will return an empty array for it, so passing false to wp_parse_args should be A-OK and probably has been like that for a very long time. Doesn’t hurt to add the empty array(), but doesn’t really change anything.” YMMV.)

    Theme Modification API

    Using the Theme Modification API (get_theme_mod()/get_theme_mods()) is fairly similar.

    An individual setting can be called via:

    get_theme_mod( $name, $default );
    

    But perhaps more useful, all settings can be called via:

    $themeslug_options = get_theme_mods();
    

    Since get_theme_mods() returns an array, you can use the same technique as with Options API settings:

    $themeslug_options = wp_parse_args( 
        get_theme_mods(), 
        themeslug_get_option_defaults() 
    );
    

    Portability/DRY (Part 2)

    To be able to use this method throughout the Theme, wrap the wp_parse_args() call inside a function:

    function themeslug_get_options() {
        // Options API
        return wp_parse_args( 
            get_option( 'theme_themeslug_options', array() ), 
            themeslug_get_option_defaults() 
        );
        // Theme Mods API:
        /*
        return wp_parse_args( 
            get_theme_mods(), 
            themeslug_get_option_defaults() 
        );
        */
    }
    

    Then, wherever you need access to Theme options:

    $themeslug_options = themeslug_get_options();
    

    From there, you can globalize $themeslug_options, or cache/transient it, etc. When you need to add a new option, simply add the new option default to the defaults array, and the Theme will handle it automatically.

     
    • Justin Tadlock 2:05 am on July 9, 2014 Permalink | Log in to Reply

      No need for the custom filter hook there on the defaults. Child theme authors can simply filter 'default_option_' . $option if they need to overwrite this.

      • Chip Bennett 12:32 pm on July 9, 2014 Permalink | Log in to Reply

        But that only works if the option is not yet set in the database, right? In which case, it’s a bit more fragile, and wouldn’t work in the case of a Theme (or Child Theme) adding a new option in a later version of the Theme.

  • Chip Bennett 12:07 am on July 8, 2014 Permalink | Log in to leave a Comment
    Tags: copyright,   

    Proper Copyright/License Attribution for Themes 

    There seems to be a great deal of confusion/misunderstanding regarding what constitutes proper copyright/license attribution for Themes, and several Themes are being approved without proper copyright/license attribution.

    There are four primary types of attribution: the Theme itself, derivative-work, incorporated code, and bundled resources. For works licensed under (or compatibly with) GPL, this attribution is important, because it ensures that end users know their rights regarding modification and distribution of the copyrighted work. The “copyleft” nature of GPL ensures that those same rights are preserved in downstream distributions of a copyrighted work, or works derived from that work – which is why it is imperative that correct copyright/license attribution be included in GPL-compatible works.

    Theme Copyright Attribution

    Fred WordPress Theme, Copyright 2012 Joe Smith
    Fred is distributed under the terms of the GNU GPL
    

    The Theme itself is a copyrighted work, and requires copyright attribution. According to GNU (the maintainer of the GPL):

    Whichever license you plan to use, the process involves adding two elements to each source file of your program: a copyright notice (such as “Copyright 1999 Terry Jones”), and a statement of copying permission, saying that the program is distributed under the terms of the GNU General Public License (or the Lesser GPL).

    The copyright notice:

    The copyright notice should include the year in which you finished preparing the release (so if you finished it in 1998 but didn’t post it until 1999, use 1998). You should add the proper year for each release; for example, “Copyright 1998, 1999 Terry Jones” if some versions were finished in 1998 and some were finished in 1999. If several people helped write the code, use all their names.

    The statement of copying permission:

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program. If not, see < http://www.gnu.org/licenses/ >.

    Derivative Themes and Incorporated Code Copyright Attribution

    Themes that are derived from other Themes (such as Twenty Twelve or Underscores) must declare that they are derived from another work, and include the original copyright notice from that work. For derivative works, the declaration would follow the Theme’s own copyright notice, and would take a form similar to the following:

    Ginger WordPress Theme is derived from Fred WordPress Theme, Copyright 2012 Joe Smith
    Fred WordPress Theme is distributed under the terms of the GNU GPL
    

    Incorporated Code Copyright Attribution

    Themes that incorporate code from other Themes (or Plugins) must declare that they incorporate code from another Theme/Plugin. The difference between a derivative work and incorporated code is, generally, a matter of extent. If you use a Theme as a “starter” or a base (such as Underscores), then you have created a derivative work. If you use one or more functions from another Theme, then you have incorporated code from that Theme.

    For incorporated code, the declaration should be added to the header comments for the files and/or the doc blocks for the incorporated functions, including copyright, license, and a source link, using appropriate syntax (such as phpDoc for incorporated PHP code). The Theme readme (or license) file should include a declaration of incorporated code:

    Ginger WordPress Theme incorporates code from Fred WordPress Theme, Copyright 2012 Joe Smith
    Fred WordPress Theme is distributed under the terms of the GNU GPL
    

    Bundled Resource Copyright Attribution

    Themes that bundle third-party resources (such as script libraries, PHP or CSS frameworks, images, fonts, etc.) must declare that they bundle those resources. For bundled resources, the original copyright notice (normally found in file headers, or a license file) should be retained if it exists. Additionally, the Theme readme (or license) file should include a declaration of bundled resources, including copyright, license, and a source link.

    Ginger WordPress Theme bundles the following third-party resources:
    
    Genericons icon font, Copyright 2013 Automattic
    Genericons are licensed under the terms of the GNU GPL, Version 2 (or later)
    Source: http://www.genericons.com
    
    Cycle2 jQuery library, Copyright 2012 M. Alsup
    Cycle2 is dual-licensed under the terms of the GNU GPL, Version 2, and the MIT license
    Source: http://jquery.malsup.com/cycle2/
    

    Requiring this information to be listed in the readme when it is available in file headers is a bit redundant; but it is a matter of ensuring that the Theme developer has considered/verified that the licenses for all bundled resources are GPL-compatible, and that end users (and reviewers) have a known location to find this information. Note that, because binary files (such as images) do not have human-readable file headers, the inclusion of copyright, license, and source link in the readme is critical, since otherwise the end user will have no way to know how to find this information.

    Putting it All Together

    Here is an example of a complete copyright/license attribution section in a Theme readme (or license) file:

    Ginger WordPress Theme, Copyright 2012 Joe Smith
    Ginger is distributed under the terms of the GNU GPL
    
    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.
    
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
    
    You should have received a copy of the GNU General Public License
    along with this program.  If not, see .
    
    Ginger WordPress Theme is derived from Underscores WordPress Theme, Copyright 2013 Automattic, Inc.
    Underscores WordPress Theme is distributed under the terms of the GNU GPL
    
    Ginger WordPress Theme incorporates code from Fred WordPress Theme, Copyright 2012 Joe Smith
    Fred WordPress Theme is distributed under the terms of the GNU GPL
    
    Ginger WordPress Theme bundles the following third-party resources:
    
    Genericons icon font, Copyright 2013 Automattic
    Genericons are licensed under the terms of the GNU GPL, Version 2 (or later)
    Source: http://www.genericons.com
    
    Cycle2 jQuery library, Copyright 2012 M. Alsup
    Cycle2 is dual-licensed under the terms of the GNU GPL, Version 2, and the MIT license
    Source: http://jquery.malsup.com/cycle2/
    

    Hopefully this post helps clarify the requirements for proper copyright/license attribution, and will help ensure that review of license requirements is more consistent. As a reminder: under the current guidelines, these copyright statements must be included in the Theme readme (or license) file. The examples given above are intended to describe required content, and not necessarily a required format for that content.

     
    • Joan Boluda 6:38 am on July 8, 2014 Permalink | Log in to Reply

      Great resource. Very useful to the TRT. Thanks for clarifying, Chip.

    • Team Vivacity 10:18 am on July 8, 2014 Permalink | Log in to Reply

      Thanks Chip, The post is really helpful for the beginers and as well as experienced developers to put all necessary things in theme.

      Great work!

    • alex27 10:59 am on July 8, 2014 Permalink | Log in to Reply

      This is great! We should make those nuggets part of the guidelines, so that they are easy to find also for theme authors!

      • Chip Bennett 1:28 pm on July 8, 2014 Permalink | Log in to Reply

        We intentionally keep this level of detail out of the Guidelines. If we tried to put all this in the Guidelines (Front page settings, Copyright attribution – and more coming in the days/weeks ahead), the Guidelines would quickly become unreadable.

        Long-term, my goal is to link all of these long-form tutorials in an updated Review Guide (something else I’m working on, but it takes time), so that the information is easily accessible, and easy to follow, while conducting a review.

    • rajlaksh 5:50 am on July 12, 2014 Permalink | Log in to Reply

      Sir, Your Site is confusing. I was unable to find what i was looking. But that exists in your site.

      I was waited for it past 1 month. Thanks for deep tutorial.

  • Chip Bennett 4:57 pm on June 28, 2014 Permalink | Log in to leave a Comment
    Tags: template hierarchy   

    Correct Handling of Static Front Page and Custom Blog Posts Index Template 

    Recently, there have been several Themes submitted – and approved – that include a template-blog.php (or page-blog.php) custom page template, or that include a static front page template (front-page.php) that doesn’t properly account for the user configuration to display the blog posts index on the front page. In order to be approved, Theems must handle these correctly.

    Themes must properly support user configuration of the front page display, as configured via Settings -> Reading, Front page displays, Front page, and Page for posts.

    The “Front page displays” option correlates to get_option( ‘show_on_front’ ), and returns a value of ‘page’ (static front page) or ‘posts’ (blog posts index). Themes must account for both values, whether or not the Theme uses front-page.php. For more information, see here.

    Theme support extends beyond the “Front page displays” setting, however. Themes must also properly implement support for the “Front page” and “Page for posts” settings, as defined by the Template Hierarchy. To understand the implementation, consider the user configuration. Users set up a static front page like so:

    1. Create two static pages, which we’ll call “Front Page” and “Blog”
    2. In Settings -> Reading, set “Front page displays” to “a static page”
    3. In Settings -> Reading, set “Front page” to “Front Page”
    4. In Settings -> Reading, set “Posts page” to “Blog”

    In this scenario, using the Template Hierarchy, WordPress will determine what to display in the context of Front Page and Blog Posts Index.

    Front Page:

    • front-page.php
    • Page Template Hierarchy (custom page template, page-slug.php, page-id.php, page.php, index.php)

    Blog Post Index:

    • Home Template Hierarchy (home.php, index.php)

    That means that, according to the Template Hierarchy, the correct file to use to define a custom blog posts index is the home.php template file, and not a custom page template. In fact, when users have properly configured a static front page and assigned pages to display the site front page and the blog posts index, a custom page template is pointless. Even if the user applies the template-blog.php custom page template to the page assigned to display the blog posts index, WordPress will ignore it, because the blog posts index uses the Home template hierarchy, and not the Page template hierarchy. WordPress will look for the home.php template file, and will fall back to the index.php template file.

    So, the only possible way for the user to use a template-blog.php custom paage template would be for the Theme to instruct the user to configure the site front page and blog posts index in a way other than the way that core defines. Forcing the user into a different configuration than the one defined by core is poor UX. Users should not have to configure core WordPress features differently whenever they install a new Theme.

    So, if a Theme incorporates a custom template for the blog posts index, it must be implemented as the home.php template file, and not as a template-blog.php custom page template. If you are reviewing a Theme, please ensure that this is part of your review. If you’re a Theme developer, please ensure that you’re instructing your users to implement static front pages (and blog posts index pages) consistently with the core implementation, and that your Theme properly implements the Template Hierarchy.

    (Side note: I strongly recommend the habit of prefixing custom page templates with “template” or “tpl” or something similar, rather than “page”. Naming a custom page template ‘page-foobar.php’ will cause WordPress to use that custom page template any time the user creates a static page with the slug “foobar”. Using something else, such as ‘template-foobar.php’ or ‘tpl-foobar.php’ will prevent that from happening, and will ensure that the custom page template is only used if the user explicitly assigns the custom page template to a given static page.)

     
    • Emil Uzelac 6:44 pm on June 28, 2014 Permalink | Log in to Reply

      Great post Chip, well covered!

    • Maria Antonietta Perna 10:16 am on June 29, 2014 Permalink | Log in to Reply

      This is a great point, thank you for having brought it up in such a clear way.

    • kevinhaig 9:52 pm on June 29, 2014 Permalink | Log in to Reply

      So I guess I’m one of those using custom templates. My index.php still allows users to implement a blog page using core configuration. But my themes have a couple of custom blog templates that provide users with different blog options. For example, a blog with a slider at the top or a full width blog versus a blog with a sidebar.

      All the user has to do is create the page using the template and put the page in the menu. If the user has configured a static home (front) page and they want to use a custom blog page, they are instructed to leave the “Posts page:” to” — Select — “.

      I am struggling on why this is such a bad practice. If a user switches a theme, then they will have to set up a blog page witch is just a few clicks. Much simpler then having to reset all the sidebar widgets.

      I could program a custom home.php, setting up all the user options that are available in the two custom blog templates, but what would I do with all the existing users that are using the custom templates?

      If blog pages are to be restricted to home.php or index.php, then why are all the pages created on a site listed in a drop down list for “Posts page:” ? I realize they are ignored anyway, but why are they there?

      • Chip Bennett 10:36 pm on June 29, 2014 Permalink | Log in to Reply

        I am struggling on why this is such a bad practice. If a user switches a theme, then they will have to set up a blog page witch is just a few clicks. Much simpler then having to reset all the sidebar widgets.

        Start from the assumption that users already have properly configured their site to use a static front page. When they activate your Theme, they have to change their configuration. They shouldn’t have to do that. Likewise, if they use your Theme first, and then switch to another Theme, they again have to change their configuration. They shouldn’t have to do that. Themes – especially WPORG-hosted Themes – should support core features and configurations out-of-the-box. Anything less adversely impacts end users.

        Sidebars always have to be reconfigured when switching Themes. But that’s a different discussion for a different venue.

        I could program a custom home.php, setting up all the user options that are available in the two custom blog templates, but what would I do with all the existing users that are using the custom templates?

        Work with your Reviewer. Add in a proper home.php template file, with associated Theme options, and instructions to your users for how to make the switch. Then, in the next Theme update, remove the custom page templates. Let your reviewer know up front that you’re working on a transition path for your users, to bring the Theme into compliance. If you have any problems, CC me on the ticket and I’ll help.

        If blog pages are to be restricted to home.php or index.php, then why are all the pages created on a site listed in a drop down list for “Posts page:” ? I realize they are ignored anyway, but why are they there?

        That relates to how the Template Hierarchy works. The “Posts page” dropdown simply applies the ID of the selected page to get_option( 'page_for_posts' ). If that value is set, and a query request is made for that Page ID, WordPress recognizes it as the Posts page (view source), sets the query context to the Blog Posts Index (is_home() = true), which then causes the template loader to call the Blog Posts Index template hierarchy.

    • kevinhaig 10:49 pm on June 29, 2014 Permalink | Log in to Reply

      Thanks Chip

    • Greg Priday 9:57 am on July 2, 2014 Permalink | Log in to Reply

      I’ve used template-blog.php in some of my older themes that are live on the directory already. Would I need to remove these page templates from my existing themes or just encourage users to use the proper reading settings for the blog page?

      • Chip Bennett 2:59 pm on July 2, 2014 Permalink | Log in to Reply

        Yes, you’ll need to remove them. But as I mentioned previously: work with your reviewer, and use a transition plan. In the next revision, add in the correct templates, and provide instructions to your users. Then in the following revision, remove the incorrect, custom page templates.

        • Greg Priday 7:22 am on July 3, 2014 Permalink | Log in to Reply

          Great, I’ll get to work removing them. It does seem a lot less hackey doing it this way, so I’m all for the change.

          Would adding the following code to the top of my current template-blog.php files be a valid transition plan?

          `
          if( !get_option(‘page_for_posts’) && get_option(‘show_on_front’) == ‘page’ && get_post_status() == ‘publish’) {
          // We’re transitioning away from using the blog page template
          // Automatically update this so it uses the proper system.
          update_option( ‘page_for_posts’, get_the_ID() );
          update_post_meta( $post->ID, ‘_wp_page_template’, ‘default’ );
          }
          `

          Basically what I’m doing here is automatically setting up everything for the user and if all goes well, I’ll be able to remove template-blog.php in the following update, without much fuss.

    • vinnyj 10:34 am on July 5, 2014 Permalink | Log in to Reply

      I am a theme developer have been for about two years now. I am still learning to use a development tool for themes designed for word press. How would I get involved in the theme team to see if my themes are qualified for being used with word press. I want to know is there were I can discuss most of my concerns about making themes for word press. I have come to realize that its not that easy to make themes designed for buddy press.

    • weblizar 11:31 am on July 5, 2014 Permalink | Log in to Reply

      Very Helpful Post,Thanks Chip..

  • Chip Bennett 6:45 pm on June 20, 2014 Permalink | Log in to leave a Comment  

    Review Workflow and Closing Tickets 

    There seems to be some misunderstanding about the review workflow. A few of the newer reviewers are leaving initial review comments, and immediately closing the ticket. While that was our old workflow, it has not been our current workflow for about a year.
    Our current workflow is designed such that, as long as the ticket remains open, any subsequent Theme updates that get submitted are automatically appended to the open ticket – which allows for the review process to take place in a single ticket. This process is much easier both for the reviewers and for developers.
    Tickets should only be closed under two circumstances:
    1. The developer fails to respond within a reasonable time
    2. The submission is not legitimate (ripped theme, spam theme, etc.)
    We currently define “reasonable time” as a week. But in order to make things even easier and consistent, I am asking that reviewers not close tickets due to lack of developer response. This is something that I check for, usually daily, in order to close tickets with no response, or to request a status update.
    So:
    1. Do not close tickets due to lack of developer response. Admins will take care of such ticket closures.
    2. Do not post “bump” comments, as doing so impacts Admins’ ability to follow up on idle tickets.
    The idea is that reviewers can just focus on doing reviews, and helping developers proceed toward approval; Admins can focus on dealing with tickets without developer response and otherwise idle tickets.
     
    • Rizqy Hidayat 1:54 am on June 21, 2014 Permalink | Log in to Reply

      got it, except for “bump” comments. what kind of these?

      • Chip Bennett 12:14 pm on June 21, 2014 Permalink | Log in to Reply

        On forums, a “bump” post is one that is used just to bring a topic back to the top of the list – i.e. “bumping” the topic. In the context of Theme-Trac, a “bump” comment is one that is just an update request (e.g. “Any update on this review?” or “Any response from the developer?” – that kind of thing). Such comments actually work exactly opposite as they would in a forum, in that they “bump” the ticket to the *bottom* of the lists we Admins use (tracking assigned tickets, pushing approved Themes “Live”, etc. – which is why it is counter-productive to post “When will my Theme be live?” comments).

        For example: when tracking assigned tickets, I follow up on any ticket that is assigned, but not modified in more than 7 days. So, by posting a “bump” comment, the ticket is modified, and it drops to the bottom of the list. The same is true with pushing approved Themes “Live”: I start with the oldest “Approved” ticket, in terms of last-modified date/time. So, by posting a “bump” comment, the ticket is modified, and it drops to the bottom of the list.

    • perryb 7:27 am on July 2, 2014 Permalink | Log in to Reply

      Ah, thanks for the update. Also having your theme review shut down before you can reasonably respond is going to come across a tad rude ;)

  • Chip Bennett 5:14 pm on April 8, 2014 Permalink
    Tags: , ,   

    Selective Ticket Assignment and Ticket Hogging 

    Based on recent comments, I would like to clarify a couple points about ticket assignment.

    Selective Ticket Assignment

    First, when you assign a ticket to yourself, assign the first ticket in the queue. That means assign from tickets in Priority #1 queue, before assigning tickets from Priority queues 2, 3, or 4. Also, and more importantly: assign the first-available ticket in the queue. Do not cherry-pick tickets based on ease of review, reporter (i.e. Developer), etc.

    Selectively assigning tickets is unfair to developers who are required to wait their turn in the review queue, and is a means of gaming the incentive program. Several reviewers have alleged that this practice takes place. We have not monitored it, but we will do so – something that will take even more time, and result in further delays in getting Themes approved and live. Anyone found to be selectively assigning tickets will risk being disqualified for the incentive program.

    Ticket Hogging

    Until now, we have not set limits on the number of open/assigned tickets a reviewer can have at any one time. Several reviewers have complained that often there are no tickets available, while some reviewers have several open/assigned tickets. So, going forward: reviewers may not have more than 5 open/assigned tickets at any one time.

    In order to ensure that reviewers don’t get stuck with developer-abandoned tickets, admins will close tickets older than one week with no activity or developer response. For this reason, it is even more important not to “bump” tickets by posting comments requesting status updates.

    Also, while this will be much more difficult to monitor: reviewers should only assign themselves one ticket at a time. Assign a ticket, conduct a full review, post comments, and only then assign another ticket.

    Also, this clarification isn’t intended to introduce delays in developers getting their Themes reviewed. Any ticket that appears in the Priority #3 queue (tickets older than 2 weeks) are fair game to anyone. (But if the priority queue system is followed properly – see above – there should never be any tickets in the Priority #3 queue.)

    Please discuss in the comments below.

     
    • Rohit Tripathi 5:30 pm on April 8, 2014 Permalink

      Although, I don’t disagree with any of the above, there is one thing which I would like to say in regard to Selective Assignment.

      When, I review a ticket from a Developer say XYZ. It took me an hour, to perform a complete review and point out the mistakes. Now, another theme from the same developer is towards the bottom of the queue. I am obviously inclined to pick it up, as I have already reviewed the code. And chances are that 90% of the code is same in 2 different themes from the same developer. This will save my time, and others’ too as they won’t have to put in the same amount of effort which I had to put in on the first theme of XYZ.

      Is this still an unhealthy practice?

      • Chip Bennett 5:34 pm on April 8, 2014 Permalink

        Yes, because all those tickets in between represent developers who have also patiently waited their turn to have their Theme reviewed.

        Also, it is healthy for more reviewers to be exposed to more Theme code from more Theme developers, because it helps make us all better at reviewing.

        • Rohit Tripathi 5:39 pm on April 8, 2014 Permalink

          One more thing. Is it necessary for us to pick us from #1 first? There some reviewers dedicated towards Theme Updates like @tskk and @robin90 who aim for the incentive by reviewing updates, while others go for the new themes.

    • tskk 5:41 pm on April 8, 2014 Permalink

      If a ticket at top is way over my head, i have to wait till its picked up, tickets below have to wait unnecessarily.

      Tickets are flying off the list, there won’t be much unjust to if we skip the one’s over my head.

      • Chip Bennett 6:12 pm on April 8, 2014 Permalink

        If you always skip tickets for more difficult Themes, one, you force other developers to review the Themes that take more effort; and two, you never benefit from learning from those more difficult Themes. If you need help with a ticket, ask. Everyone on the mail-list should be willing to jump in and help another reviewer who needs help with a complex Theme (especially when tickets are getting assigned so quickly that we have none in the queue). We are a team, and the expectation is that we will act like a team, and help one another like a team.

        • tskk 6:17 pm on April 8, 2014 Permalink

          true, i did learn a lot reviewing themes. next step in learning it is….

      • Frank Klein 6:17 pm on April 8, 2014 Permalink

        I agree with Chip.

        If you go into the queue and look for small updates, you can do a huge number of tickets in a short amount of time. It’s simply not cool for the theme developers and for the other reviewers if you go in and only take the low hanging fruit, and leave the large and difficult to dissect reviews for others.

        At the same time, we should encurage developers to do smaller commits, instead of mashing together different features and bug fixes in one gigantic kitchen sink commit.

    • Emil Uzelac 5:43 pm on April 8, 2014 Permalink

      Additionally: (very much related)

      Current program is to help community and in return TRT features your Theme. This is not a race or competition.

      At the same time our program was not designed as a promotional tool from i.e. Theme Name to Theme Name Pro, but it has been used as such and we have no problems there.

    • robin90 5:48 pm on April 8, 2014 Permalink

      Thanks Chip for outlining all those. All the points that you have outlined above were already there and has been discussed many times except this one I think 5 open/assigned tickets. But reviewers seemed to neglect that and grab more tickets simultaneously. It’s sad that we have to outline each and every point. If reviewers would have been little more sensible than we wouldn’t have needed all this.

      • Emil Uzelac 6:16 pm on April 8, 2014 Permalink

        It will get better :)

        • robin90 7:51 pm on April 8, 2014 Permalink

          let’s hope so :)

          • Catch Themes 10:52 am on April 10, 2014 Permalink

            Yes lots of complain and we should remember that this is reward and we should appreciate the Admins efforts. I hope it will be better soon :)

    • ThinkUpThemes 7:29 pm on April 8, 2014 Permalink

      Thanks Chip for this! I totally agree that limiting tickets to 5 per reviewer really helps to give everyone a better chance at getting hold of a ticket and getting that valuable learning experience gained from reviewing. Quick question, if a theme is set to “approved”. Does it still count towards the 5 limit until it’s either made live / reopened / etc… by an admin?

      • Chip Bennett 7:49 pm on April 8, 2014 Permalink

        Once a ticket is “approved”, it is no longer open/assigned, it is closed/approved.

    • CyberChimps 8:23 pm on April 8, 2014 Permalink

      We are glad we’re addressing this now, but as long as the reopen ticket rule exists, the system can still easily be gamed.

      A blog post on this topic doesn’t negate the fact that this practice lead to several of this months winners winning the contest, when completely legitimate reviews were discredited for erroneous reasons.

      You guys rewarded those who cheated this month and punished legitimate reviews which disqualified two winners.

      A blog post pointing out that people cheated while still honoring those who cheated and punishing legit reviews doesn’t undue the damage caused. This isn’t a fair contest.

      • Chip Bennett 11:06 pm on April 8, 2014 Permalink

        We are glad we’re addressing this now, but as long as the reopen ticket rule exists, the system can still easily be gamed.

        How so? Unless you’re suggesting that the Admins are attempting to game the system?

        A blog post on this topic doesn’t negate the fact that this practice lead to several of this months winners winning the contest, when completely legitimate reviews were discredited for erroneous reasons.

        Untrue. And for the third time: if you have issues with tickets that you believe were unopened unfairly, the place to raise that issue is in the specific ticket.

        You guys rewarded those who cheated this month and punished legitimate reviews which disqualified two winners.

        Again untrue. There is no evidence of “cheating”, and no reviews were “punished”.

        A blog post pointing out that people cheated while still honoring those who cheated and punishing legit reviews doesn’t undue the damage caused.

        Still untrue. There is no evidence of “cheating”, and no reviews were “punished”.

        This isn’t a fair contest.

        If you think the contest isn’t fair, you’re welcome not to participate.

        • CyberChimps 12:47 am on April 9, 2014 Permalink

          If reviewers are selectively reviewing themes, and more complicated tickets are being left to the remaining reviewers the odds of the tickets being reopen is higher. Therefore the reviewers not selectively reviewing are at a greater risk of taking on tickets that may get reopened negating all of their review work. Which is exactly what just happened, and unfair.

          The tickets we had weren’t reopened unfairly, the rule of disqualifying those reviews is unfair.

          We’ve sent a list of the theme reviewers who were selectively reviewing to you personally to review as we would prefer not to present this data publicly, although it is clear upon reviewing Theme Trac who the offenders are.

          We consider disqualifying legitimate reviews as being punished because it lost us the contest this monthly unfairly, where as reviewers who selectively reviewed were rewarded and won the contest. This what we consider to be unfair.

          CyberChimps has been providing Theme Reviews for 3 years now long before the contest and will continue to contribute no matter how unfair the circumstances. We’ve sponsored many WordCamps, the Community Summit, and continue to do what we can to support the community. Our reputation in this community alone, as well as having the most popular theme on WordPress.org and in the world should be more then enough to back up our credibility on such matters.

          • tskk 6:58 am on April 9, 2014 Permalink

            So you are saying people should be punished for not following rules of future while you yourself are breaking the rules of the present? you have 13 open tickets right now and your employee’s are still assigning tickets to them self, while the current limit is 5. You should be disqualified from this month’s competition as you have more tickets than the limit.

            • CyberChimps 1:07 am on April 10, 2014 Permalink

              We took on those tickets before the new rule.

              We’re going to review all of those tickets, we could easily be doing 15-20 reviews a month. We have several new people being trained to do reviews.

              Like CyberChimps, you have been one of the few reviewers not selectively reviewing. Thank you for that.

          • tskk 9:20 am on April 9, 2014 Permalink

            I personally don’t think all these rules are unnecessary, program was working for months and certain company will complain no matter what, as long as they don’t get their theme featured.

            Not assigning next ticket without posting the full review is enough.

            All this is too much work for admins and will only result in program getting cancelled.

    • ThinkUpThemes 8:54 am on April 9, 2014 Permalink

      Hi All,

      I wanted to share some thought on the cap on open/allocated tickets and hear the thoughts of others. Although the need of a cap, of sorts, is a great idea. I worry that this new cap although will reduce the risk of ticket hogging (which affected reviewers), it will however introduce a new and greater risk of ticket churning (which will affect developers).

      Consider a scenario where a reviewer has 5 allocated tickets, all of which have been reviewed, and on which a developer response is required. Reviewers might:

      1. Rush a review to the approval stage simply to free up a slot to allocate a new review.
      2. Rush to disapprove a theme purely because it may take longer to review or require more support to be provided to the developer.

      In addition, inexperienced developers with a passion to learn may not get the support they need as reviewers simply may not be inclined to keep tickets open.

      Also the risk of selective reviews will increase, however the point at which the risk arises will simply shift to a later stage of the review cycle. Rather than being at the ticket allocation stage (which personally I don’t think happens) the selective review risk will shift to when a ticket is now allocated. Essentially reviewers will ‘cherry pick’ by choosing to decline complicated themes that may take a while to review in the hope that the next theme they choose will be more simple.

      Another worry is that the move of closing tickets after 1 week is a move to keep reviewers happy so that 1 of the valuable 5 allocations isn’t unnecessarily filled by an unresponsive developer. I feel a little uneasy about changes which shift the focus of the review process from benefiting developers to benefiting reviewers. The previous rule of admins following up on a ticket after 1 week, and them closing after 2 (if no response is received) is great for developers as it gives them a chance to take action. Disapproving tickets for lack of response after 1 week, especially if the developer hasn’t been warned, might lead to them bring disheartened with our process and discouraged from resubmitting in future.

      Just an initial thought, could there be a way to impose a cap for example, reviewers cannot allocate more than 5 tickets unless all allocated tickets have been fully reviewed. I know this makes it harder to monitor and more time for admins. So to discourage poor reviewer behaviour, I was thinking that a penalty can be imposed whereby any tickets in addition to this 5 will not count towards the incentive program if an admin feels a “good” attempt has not been made in reviewing their existing tickets. Obviously the definition of “good” here is subjective and would be purely be based on the admins view of what is considered “good”.

      Anyway, thanks so much to anyone who’s taken the time to read this. I’d love to hear your thoughts.

      Afzaal

      • Chip Bennett 1:02 pm on April 9, 2014 Permalink

        Note that both of these are counter-productive (and the latter is contrary to our current workflow):

        1. Rush a review to the approval stage simply to free up a slot to allocate a new review.
        2. Rush to disapprove a theme purely because it may take longer to review or require more support to be provided to the developer.

        Neither of these would result in a ticket being made approved and live, and so wouldn’t count toward the incentive. And premature ticket closure is contrary to our workflow.

        Another worry is that the move of closing tickets after 1 week is a move to keep reviewers happy so that 1 of the valuable 5 allocations isn’t unnecessarily filled by an unresponsive developer. I feel a little uneasy about changes which shift the focus of the review process from benefiting developers to benefiting reviewers. The previous rule of admins following up on a ticket after 1 week, and them closing after 2 (if no response is received) is great for developers as it gives them a chance to take action. Disapproving tickets for lack of response after 1 week, especially if the developer hasn’t been warned, might lead to them bring disheartened with our process and discouraged from resubmitting in future.

        This is a valid concern. I would be fine with saying “no more than 5 open/assigned tickets less than a week old“, and then Admin-closing after two weeks of no Developer response. But, I think that a week is more than enough time for a developer to provide some kind of response in-ticket. Let’s see how it goes as-is, and we’ll adjust as necessary.

        Just an initial thought, could there be a way to impose a cap for example, reviewers cannot allocate more than 5 tickets unless all allocated tickets have been fully reviewed. I know this makes it harder to monitor and more time for admins. So to discourage poor reviewer behaviour, I was thinking that a penalty can be imposed whereby any tickets in addition to this 5 will not count towards the incentive program if an admin feels a “good” attempt has not been made in reviewing their existing tickets. Obviously the definition of “good” here is subjective and would be purely be based on the admins view of what is considered “good”.

        My bigger concern – and the concern that could be the downfall of the entire incentive program – is that reviewers are performing every action and basing every decision on how those actions/decisions impact their ability to win the incentive program. If we have reached that point, then the program has, in fact, failed. If reviewers are expending more effort on gaming the incentive program than they are expending effort on contributing to WordPress via Theme reviews, then we’ve failed. If Admins are expending more effort running and managing the review incentive program than we are expending effort on final-approving Themes/pushing Themes live, finding ways to make the review process easier for developers and reviewers, and helping to educate about Theme development best practices, then we’ve failed.

        That we’re getting this much into the weeds with the incentive program is a pretty major indication that it’s becoming more of a detriment than a benefit – which is a shame, because it’s been instrumental in more than doubling the rate of new Themes being made live in the Theme Directory.

    • PageLines 9:40 am on April 10, 2014 Permalink

      Hey Chip! Thank you for the comments and additional guidelines, we’ll do our best to stick with them.

      We do have one question, though, related to the cap:

      What if we have 5 reviews, all completed, but waiting for dev answer? This means that we cannot assign any more reviews until those have been finalised, but devs often take a few days to come back and upload the new version.

      We should be able to assign further tickets as long as the review is started and posted immediately after the ticket assignment, and *before* any further tickets are assigned, right?

      Thank you for your time.

      • Chip Bennett 12:14 pm on April 10, 2014 Permalink

        What if we have 5 reviews, all completed, but waiting for dev answer? This means that we cannot assign any more reviews until those have been finalised, but devs often take a few days to come back and upload the new version.

        I’ve been informally monitoring the number of assigned tickets per reviewer for a while. It is very rare for more than a handful of reviewers to have more than 5 open/assigned tickets at any one time. It is also very rare for any reviewers to have more than 20 closed/live tickets in any one month. So, any real impact here is going to be on the extreme edges, based on current review activity.

        If the 5-ticket cap starts causing issues with the queue, we’ll revisit it.

        We should be able to assign further tickets as long as the review is started and posted immediately after the ticket assignment, and *before* any further tickets are assigned, right?

        Of course. Just make sure the first review is thorough and complete, leave review comments, and then feel free to move on to the next ticket.

        • tskk 12:25 pm on April 10, 2014 Permalink

          “Of course. Just make sure the first review is thorough and complete, leave review comments, and then feel free to move on to the next ticket.”

          He is talking about further tickets beyond the cap of 5.
          Can you consider increasing the limit to 10?

          • Chip Bennett 1:56 pm on April 10, 2014 Permalink

            Can you consider increasing the limit to 10?

            Not at this time. We’ll reevaluate as we move forward, but as I said: based on informal monitoring of assigned tickets, it is extremely rare for any one reviewer to have more than 5 tickets open/assigned at any one time.

            Also: the more tickets open/assigned, the more work it is for a given reviewer to perform follow-up actions when developers respond: actions such as responding to questions, providing guidance for resolving required issues, and reviewing submitted updates.

            I’d rather see a reviewer put more time into a single review, and do one review a day, than to race through multiple reviews a day. And the current throughput and reviewer activity level doesn’t really indicate a need for any single reviewer to have more than 5 open/assigned tickets at one time.

    • Catch Themes 10:49 am on April 10, 2014 Permalink

      Thanks Chip and the Admin Team for highlighting the points so that we have clear winner :)

    • ThinkUpThemes 1:09 pm on April 11, 2014 Permalink

      Hi Chip,

      In relation to the cap I just wanted to seek clarification on one of your points:

      I would be fine with saying “no more than 5 open/assigned tickets less than a week old“

      So am I correct in thinking that if a ticket has been open for more than 5 days then a reviewer can assign a new ticket? So essentially the 5 cap applies only to themes opened less than 7 days ago, thereby eliminating the issue of hogging?

      Thanks as always!

      • Chip Bennett 1:36 pm on April 11, 2014 Permalink

        For now, please stick to the 5-ticket cap. Admins will close tickets that have no response for longer than a week.

    • tskk 1:26 pm on April 15, 2014 Permalink

      @chipbennett how do we notify selective assignment if spotted?
      Or is that something you will take care of yourself?

      • Chip Bennett 1:28 pm on April 15, 2014 Permalink

        If you find someone selectively assigning tickets, email me directly with the details, and I’ll address it.

    • Ulrich 3:55 pm on April 18, 2014 Permalink

      This is my suggestion to the admins.

      Reward the top 10 reviewers by letting them choose a theme that will be featured. This should help reduce the amount of competition. We have ten spaces then why not use them all.

      Every theme should be reviewed by second theme reviewer. We can use the workflow keyword “2nd opinion” to mark the themes are ready to be approved but need to be reviewed by another reviewer.

      The report can be seen here.
      https://themes.trac.wordpress.org/query?keywords=~2nd-opinion&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=time&col=changetime&report=5&order=priority

      This should reduce the work for the admins and cultivate team work. This will reduce the risk of a theme not being reopened due to human error or not knowing something. This should also help standardize the theme reviews.

    • Emil Uzelac 9:53 pm on April 18, 2014 Permalink

  • Chip Bennett 8:05 pm on April 7, 2014 Permalink
    Tags: , ,   

    How To Ensure Your Ticket Passes Final Approval Audit 

    Over the past couple of months, the number of approved tickets that have been reopened due to issues found during final-approval audit has declined, but many still get reopened. As a team, we want to ensure that tickets get approved (so that new Themes get added to the directory, and into the hands of end users), and we want reviewers to be able to take advantage of the incentive program.

    So I want to step through the things I check when performing a final review audit. We’re looking for some high-level and/or high-impact things that would cause problems for end users:

    Overall File Structure

    • Does the Theme look like it is derived from a common Theme (Underscores, Twenty Ten-Fourteen, etc.)? Are there included functional files that I’ll need to check. Are there asset folders (fonts, scripts, etc.) that I’ll need to check?

    style.css

    • Check ThemeURI and AuthorURI. Are they appropriate?
    • If ThemeURI or AuthorURI reference commercial Themes, are those Themes sold as GPL-compatible?
    • If the Theme appears to be derived, does it include a proper derivative-work copyright/license attribution?

    readme.txt

    • If the Theme has bundled resources/assets, are they listed in the readme with copyright/license attribution, or will I need to check file headers?
    • Is license for all bundled resources GPL or GPL-compatible?

    header.php

    • Are Theme options properly escaped on output?
    • Is favicon, if used, disabled by default?
    • Does the TITLE tag include anything other than the call to wp_title()?
    • Does wp_nav_menu() reference theme_location, and not menu?
    • Are any stylesheet or script links output instead of being properly enqueued

    footer.php

    • Does the Theme only use one credit link? Is that credit link exactly ThemeURI or AuthorURI, with no SEO-seeding of link text, title attribute, etc.?
    • Are any footer scripts output instead of being enqueued properly?

    index.php

    • Does template markup look generally appropriate?

    Front/Home Page Templates

    • Does the Theme have front-page.php? If so, is it used properly? Does it account for both a static page and the blog posts index as site front page?
    • Does the Theme have home.php? If so, is it used properly as the default blog posts index template?
    • Does the Theme have any custom page templates intended to be used as either front-page.php or home.php?

    comments.php

    • Does the Theme properly output wp_list_comments() for the comments list?
    • Does the Theme properly output comment_form() for the comment reply form, rather than hard-coding the form?

    page.php

    • Does the page template properly call comments_template()?

    functions.php

    • Are all functions and other things in the public namespace properly prefixed?
    • Is all functional output properly wrapped in callbacks and hooked into appropriate actions?
    • Is any of the functionality Plugin territory?
    • Does any of the functionality replicate core functionality?
    • Does the Theme use Theme options? Are they handled properly (single DB entry, proper settings page, sanitized on input, etc.)?
    • Do any of the Theme options replicate core options?

    This list comprises 99% of what I look for in an audit, and accounts for the vast majority of issues encountered that require reopening tickets. So, if you verify these things before resolving the ticket as “approved”, the chances that your ticket will get reopened will go down considerably.

    (Note: @emiluzelac may have other things to add to the list, for things he checks during an audit.)

     
    • ruphel 9:16 pm on April 7, 2014 Permalink

      Thanks for the checklist Chip

    • Emil Uzelac 11:47 pm on April 7, 2014 Permalink

      My process is very similar to @chipbennett and there is nothing more to add.

      I would like to say that rushing through reviews will most definitely resolve getting your ticket reopened. Take your time and you will be golden.

      Your time and efforts are greatly appreciated!

      For some weird reason, my post got published 4 times, sorry about that.

      • Rohit Tripathi 5:35 pm on April 8, 2014 Permalink

        One thing I would like to Add on behalf of @emiluzelac

        Make sure the themes have correctly spelt “WordPress”, with W & P in captals. I have seen this as a reason in many re-opened tickets.

        :P :)

    • ThemeZee 7:28 am on April 8, 2014 Permalink

      “Does the Theme have any custom page templates intended to be used as either front-page.php or home.php?”

      Does this mean we are not allowed to use for example template-homepage.php for a custom front page template, but have to use front-page.php instead ?

      • Justin Tadlock 3:10 pm on April 9, 2014 Permalink

        home.php and front-page.php have very specific meanings in WP. They should only be used when they’re meant to be used. template-example.php, even if intended to be used on the front page, can also be used if the template can be used with any page.

        Personally, I prefer that devs make a custom page template that’s usable on any page. It offers more flexibility for users.

        • Chip Bennett 3:22 pm on April 9, 2014 Permalink

          Intent is important here. If it’s obviously intended as the site front page template, then it should be `front-page.php`. If the developer doesn’t necessarily intend for it to be the site front page, then call it a “featured content” template (or something similar), and name it `template-featured.php` (or whatever).

    • Jose Castaneda 11:25 pm on April 8, 2014 Permalink

      One of the things I often look for are hooks and filters. I’ve seen a few themes that register meta boxes and some that add post types. It just depends on how they are being used ( though post types should really be avoided in themes ).

      One thing I’ve learned is using the command line to my advantage and using grep to find all the add_action/add_filter calls a theme uses.

    • PageLines 12:30 pm on April 9, 2014 Permalink

      Thanks for the checklist guys!

  • Chip Bennett 2:53 pm on April 3, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Discussion: Theme Activation Standards 

    Currently, we are proposing a change to the Guidelines that would blanket-prohibit Themes from adding admin notices, redirects, or other similar functionality on Theme activation. The intent of the Guideline is to curtail the proliferation of nuisance/obtrusive Theme marketing in the user’s Admin.

    In the vast majority of cases, such activation functionality should not be needed. Themes are required to use add_theme_page() to add a Settings page, which ensures that end users can always find the Theme’s settings page under the Appearance admin menu. The new requirement for sane defaults will ensure that Themes will always work “out of the box”, at least at a baseline (i.e. no-broken-sites) level. The recommendation for Themes to hook settings into the Customizer will help ensure that end users can visually preview Theme settings changes via the core Customizer (Appearance -> Customize). And the Contextual Help API ensures that Theme developers can add as much rich-text setup/configuration detail as necessary.

    That said, there is still room for appropriate, standardized admin interventions on Theme activation. If we can agree on a consensus for standard admin interventions, then the Guidelines could reflect that consensus, and reviewers would have an objective standard to use when reviewing Themes.

    So, let’s discuss. What’s appropriate? What isn’t? How can we define appropriateness objectively?

     
    • Han 3:28 pm on April 3, 2014 Permalink | Log in to Reply

      How about adding admin notice about important changes of the new version? For example when we move the header and footer script, or custom css feature from theme to a plugin.

    • mudthemes 7:04 am on April 4, 2014 Permalink | Log in to Reply

      Even if the theme redirects the user after activation, the redirect must be to a page where only the documentation regarding the theme configuration is written.

      • eminozlem 5:51 pm on April 4, 2014 Permalink | Log in to Reply

        I think the extent may be defined with two rules a.) The redirected page should be theme’s page (most likely options page or documentation help page) b.) The page should be a related page and not advertising purpose page. Just like the same in many rules such as author & theme uri etc.

    • eminozlem 9:16 am on April 4, 2014 Permalink | Log in to Reply

      I don’t understand what’s the big deal with redirection on activation. It’s essential for themes with Option Framework that the options are initially saved for the theme to properly function.
      If you put your mind to it you can use anything out of its intended purposes so I think it’s not fair to punish everyone else because of the aggresive advertisers by prohibiting all kinds of redirecting / notice boxes that could otherwise prove useful.

      Semi OT: You mentioned sth. about the screenshot. I totally agree with that, screenshot guidelines shouldnt be that restrictive. After all, no theme ever really does look like the demo out-of-the-box. Screenshots should be allowed to display what theme might look like with proper modifications and / or content.
      Also I dont see any harm including other material in screenshot (like theme options). I mean some themes provide 4 theme options, others a hundred. It’d be eye-catching and easier for the user to spot the one for them if other aspects are allowed in the screenshot.

      • Chip Bennett 2:23 pm on April 4, 2014 Permalink | Log in to Reply

        Its essential for themes with Option Framework that the options are initially saved for the theme to properly function.

        This statement is untrue. Refer back to the Sane Defaults requirement. Properly implemented Theme options work out of the box, using developer-determined sane defaults, without any user configuration required. Themes that “break” if the user doesn’t configure Theme options have not properly implemented those Theme options.

        If you put your mind to it you can use anything out of its intended purposes so I think its not fair to punish everyone else because of the aggresive advertisers by prohibiting all kinds of redirecting / notice boxes that could otherwise prove useful.

        I do agree, which is why I’ve linked to a separate discussion, so that we can work out some meaningful standards/guidelines.

      • Chip Bennett 3:02 pm on April 4, 2014 Permalink | Log in to Reply

        It’s essential for themes with Option Framework that the options are initially saved for the theme to properly function.

        This statement is untrue. Refer back to the Sane Defaults requirement. Properly implemented Theme options work out of the box, using developer-determined sane defaults, without any user configuration required. Themes that “break” if the user doesn’t configure Theme options have not properly implemented those Theme options.

        If you put your mind to it you can use anything out of its intended purposes so I think it’s not fair to punish everyone else because of the aggresive advertisers by prohibiting all kinds of redirecting / notice boxes that could otherwise prove useful.

        I do agree, which is why I’ve linked to a separate discussion, so that we can work out some meaningful standards/guidelines. Please provide feedback there.

    • tskk 2:35 pm on April 4, 2014 Permalink | Log in to Reply

      I have opposed banning redirection in earlier discussion too, taking the user back to themes page after activation is meaningless, doesn’t serve any purpose, they have to click on theme options link and go select options anyway to get the best out of the theme. Wasting their time and effort is no good.

      Redirecting to theme options should be allowed.

      • Chip Bennett 3:07 pm on April 4, 2014 Permalink | Log in to Reply

        I disagree that user configuration of Theme options should be necessary. That’s partly why we’re adding a requirement for Sane Defaults. Users should know where to find the Theme Settings page should they choose to modify any of the defaults; users should not be forced to deal with settings configuration out-of-the-box.

        Theme-activation redirection UX is something that should be defined and handled by core, IMHO.

      • Frank Klein 3:21 pm on April 4, 2014 Permalink | Log in to Reply

        I disagree with this.

        When a user installs a theme, the experience should be the same, no matter what theme he just installed. Forcing the user to visit another screen without any action from his part makes the experience very confusing, especially if it doesn’t happen that way consistently.

        Imagine that you are a user. You found this great theme, installed it and activated it. The last thing you want to see is an options panel. You want to see how your site looks with this theme applied!

        Is the current theme activation experience as good as it can be? Probably not, but the Core team has been working on this, and they will continue to iterate on it. We should let Core handle this, because it is part of the core experience of WordPress.

        Themes should look good without having to configure options. Nobody likes setting up something, it is boring and often complicated.

        Also if a user can’t figure out quickly how to get a free theme to look like he wants, he’ll either post a support forum message or just download another theme. Either way that is not the outcome you want to achieve.

    • Devin Price 4:02 pm on April 4, 2014 Permalink | Log in to Reply

      I don’t think we should do a blanket-prohibition of admin notices. I am using two in the latest version of Portfolio Press if users are upgrading (so, actually, re-activation). One is a notice about important updates in the version, along with a link to a post about them. A second notifies users that they should update their Reading Settings. I think room should be left in the theme review guidelines for situations like this.

      I agree that upsell and marketing links should not be allowed on activation.

      I agree that notices about an option panel do not need to be displayed on activation. Users are becoming more aware about the “Customize” link. Good theme documentation can also help educate users.

      @eminozlem, Chip is absolutely right about defaults in Options Framework. You should pass a default when you call an option, e.g. of_get_option( ‘my-option’, ‘default’ ), if the theme requires something other than “false” as the reply if the option is not set. Does that make sense? Happy to explain more if needed: http://wptheming.com/contact

      • eminozlem 9:13 pm on April 4, 2014 Permalink | Log in to Reply

        Sure, my theme with OF does work defaults. But there are other specific reasons my implementation of the theme is better with an initial redirect (refresh) on activation.
        I agree with notices.The point is, no matter what the case is, be that notice, redirection, prompt or whatever, I think all should be allowed as long as it’s used in good faith and not in an abusive manner for marketing purposes.

    • @mercime 2:50 am on April 5, 2014 Permalink | Log in to Reply

      +1 blanket-prohibit Themes from adding admin notices, redirects, or other similar functionality on Theme activation.

    • CyberChimps 6:13 am on April 8, 2014 Permalink | Log in to Reply

      We’re strongly opposed to banning all theme activation notices.

      Some kind of default activation notice is required to alert users of a successful activation and what to do next.

      A better solution would be to have a default activation notice similar to what we’ve built into Responsive that directs users to theme options and documentation.

      In a perfect world, we’d all love if a theme just worked out of the box, but the truth is users need a help in knowing what the next step is to configure their website, and some customization will always be required, and the Customizer does not include all use cases yet.

      When .org forced us to removed redirects in our themes we saw significant increases in theme abandonment, and increased support from people who could not locate the theme options. Adding a customize button to the wp-admin bar is an illogical UI progression that most users don’t follow.

      Also, what about notices for companion plugins? Does this proposal intend to ban those as well?

      • Frank Klein 6:55 pm on April 8, 2014 Permalink | Log in to Reply

        TGM Plugin Activation notices or similar are not prohibited by this guideline.

        The Customizer has been introduced a while ago, and users definitely are getting used to it. Having to go to a separate options page to configure the front end of your website is more illogical than a contextually relevant and prominent link to the Customizer.

        I agree that there will always be users that struggle with setting up a theme, and we should help those. But I think that overly complicated themes are more to blame than the banning of admin notices or redirects.

        Instead of every theme shop rolling their own, we should use the feedback and experiences made to develop a Core proposal that will alleviate some of these pain points.

        • CyberChimps 12:21 am on April 17, 2014 Permalink | Log in to Reply

          The Customizer is fine for front end settings, but what about template configurations? Layouts?

          The Customizer is a great tool, but not an end to theme options.

          We would love standardized ways of addressing these pain points, which is why we would prefer if admin notices aren’t banned until a solution is actually in place.

      • Emil Uzelac 4:13 am on April 14, 2014 Permalink | Log in to Reply

        Companion plugins are excluded from the get-go and proposal does not affect them.

        Please note that @chipbennett was asking and not making solo decisions here, otherwise this post would not even exist.

        What is the best way to handle the activation and can we standardize?

        Emil

    • sanerdesign 10:22 am on April 8, 2014 Permalink | Log in to Reply

      I’m all for standardizing the theme activation notices rather than applying a blanket ban. I really feel that the admin notices can benefit the user if we can agree on the information that is displayed.
      This is just a suggestion, from my experience, but I think the following should be allowed in an agreed layout:

      Thank you message
      Link to developers site
      Link to the options if the developer isn’t just using customizer (optional)
      Link to that theme’s support pages

      It’s important to link to the developer in recognition of their hard work.
      A link to the theme options, I feel, is still important whilst they still exist. Theme options allow the developer to not just add options but to add a lot more information than they could on the customizer. Yes I am talking upselling (dirty word I know). Whilst we are probably all against over-the-top upselling and promotion of pro options etc we also have to accept that businesses are making money from this format and it is that money that pays for ongoing development and support of the theme. If we make it too difficult for developers to upsell we could end up with a lot of poorly supported themes that don’t get developed. I do think that this would be bad for the end user.
      The link to support pages is self explanatory but it is really important to let the user know immediately that there is somewhere to get help if they struggle with their chosen theme.

      Whilst I believe that it is the user experience that is always the most important for every action that we take we should consider the developer and their business for it will always be them that keep the WordPress themes fresh, supported and developed.

      Hugo

    • Schwarttzy 4:04 am on April 9, 2014 Permalink | Log in to Reply

      I don’t understand why after a theme gets activated that they get redirected to the page “Appearance.” Are they trying see how many themes they can activate in a minute or what? What’s so wrong with a page explaining the theme? Or possibly things they may want to do now that they activated this theme?

      Why is it so crucial that they get taken back to all the other possible themes they could change too?

      • CyberChimps 1:09 am on April 10, 2014 Permalink | Log in to Reply

        +1.

        Valid points.

        The explanation I was told was because they want to improve the on boarding process for WordPress, and there is some concern that a lack of selection for themes may be a pain point. However, they are simply creating a user experience nightmare with all of these new rules.

    • nikeo 2:13 pm on April 21, 2014 Permalink | Log in to Reply

      Hi,
      This follows a discussion with @chipbennet and @catchtheme during a theme review (https://themes.trac.wordpress.org/ticket/18164).

      We were wondering about the possibility to incorporate links into the top admin bar.
      In my case (Customizr theme), I have added a “Help” button in the admin bar which is visible both on back end and front end for a user connected.
      Users can have an almost direct link to the support forum on WP.org, the FAQ or the theme ‘s documentation if they feel lost. I think this makes the theme more user’s friendly and this is not redundant with the built-in WP links already displayed in this bar like : add a new post,/page…, link to dashboard, search, …

      Many popular plugins are elevating those kind of links in the admin bar and I think that’s often really interesting from a user experience perspective too.

      I would love to have your point of view/feedback about this and hope that we could come up with consistent guidelines for the WP themes.

  • Chip Bennett 2:35 pm on April 3, 2014 Permalink
    Tags:   

    WordPress 3.9 Guidelines Revision Proposal: Round 2 

    Based on the previous discussion, the Guidelines proposal has been revised as follows. The proposed guideline change for Credit Links has been removed, and a proposed guideline change for Custom Logos has been added. Other proposals have been clarified based on previous discussion.

    The two most significant clarifications regard arbitrary header/footer scripts, and Theme activation.

    The proposed Recommended guidelines have not changed. While we understand the argument that there may not be consensus around certain implementations of features, we maintain that it is within the overall scope and objective of the Theme Review Team to encourage, facilitate, and drive best-practice consensus, and that it is in the best interest of end users to establish best-practice consensus. Thus, arguing that the Theme Review Team should not be establishing/promoting such best-practice standards in order to encourage consensus is moot – though we absolutely encourage discussion regarding what implementations should be considered/promoted as best-practice standards.

    Other Discussion Topics

    Screenshot

    I would be interested in discussing our screenshot requirements. It seems that “reasonable facsimile”, as a standard, isn’t really sufficiently meeting anyone’s needs. While the intent was to avoid blatant marketing via screenshot, the requirement tends to be taken so literally that developers cannot even display user-configurable features in their screenshot. This is especially limiting for Themes with featured-content front-page templates. As currently interpreted, the “reasonable facsimile” standard prevents the screenshot from displaying the featured-content front-page, because the featured content first has to be configured. So, let’s discuss a more sane/useful guideline for screenshots.

    Translation-Ready

    I would also be interested in discussing the establishment of at least some “best practice” guidelines for translation-readiness – primarily, proper i18n of strings. I think it is all but a given that, eventually, we should be requiring Themes to be translation-ready; but currently we don’t have objective standards to follow. The first step, then, is creating those standards, and then educating developers on them.

    Required

    Sane Defaults: Themes are required to use sane defaults.

    Themes must not save default settings to the database without explicit user action, and Themes must function properly out-of-the-box without user configuration (that is: if the user does not save settings, the Theme will still function properly)

    Bundled Plugins: Themes must not bundle Plugins.

    Themes may incorporate support for Plugins, and may integrate Plugin code directly into the Theme (if that Plugin code meets the presentation-vs-functionality requirement), but Themes must not bundle Plugins as a whole.

    Arbitrary Header/Footer Scripts: Themes must not provide Theme options for arbitrary header/footer scripts.

    Arbitrary scripts are non-Theme-specific scripts added to the document head or footer to provide non-Theme-specific functionality. Such scripts are Plugin territory, and pose a significant security risk if not handled properly.

    Custom CSS is acceptable, if properly sanitized.

    Note: this guideline does not apply to content “scripts” added to the template outside of the document head/footer, such as script widgets (Google Maps, Twitter Feed, etc.). Essentially, if a script can be hooked into the template via wp_head() or wp_footer(), then it falls under this guideline; otherwise, it does not.

    Theme Activation: Themes must not implement activation redirects, admin notices, or similar functionality on activation.

    Note: this guideline does not apply to admin notices such as TGM recommended Plugins (if implemented properly). I will open a separate discussion regarding consensus/standard “unboxing” admin notices. The purpose of this Guideline is to curtail the proliferation of unnecessary/obtrusive marketing in the user admin area, not to prevent legitimate, useful activation information for the end user.

    Theme Documentation: Themes must place any required documentation in a clearly marked readme file.

    Note: this guideline applies only to required documentation. Required documentation includes copyright/license attributions, Theme design constraints/limitations, description of non-standard Theme functionality, etc. Plugin-standard readme.txt is preferred, but not required.

    License: Themes are required to document in the Theme readme or license file the copyright/license attribution for all bundled resources.

    Themes are required to provide this documentation in the Theme readme file, regardless of where or how those bundled resources provide their own attribution. The purpose is to ensure that end users (and also, reviewers) don’t have to search for this important information, and to ensure that the developer has done due diligence to ensure that licenses for all bundled resources are GPL-compatible.

    Note: “blanket” statements for developer-owned resources (images, etc.) bundled with the Theme are perfectly acceptable. It is only third-party bundled resources that need to be listed explicitly.

    Custom Logos: If implemented, custom logos must be user-configurable, and disabled by default.

    This guideline will bring the handling of Theme options for custom logos in-line with the handling of Favicons. Currently, we require that “default” logos be generic/unbranded, but generic/unbranded logos are of no benefit to the end user. Likewise, Theme-branded logos are of no benefit to the end user. The most logical approach, then, is to require that custom logos not be displayed at all, unless the end user has configured one.

    Recommended

    Theme Documentation

    Themes are recommended to include a Plugin-standard readme.txt file.

    Themes are recommended to meet the WP core standard for inline documentation.

    Translation

    Themes are recommended to be translation-ready.

    Social Profile Links

    Themes are recommended to use a custom navigation menu when incorporating social network profile links

    Theme Options

    Themes are recommended to integrate Theme options into the core Theme Customizer

    Discuss

    Please discuss in the comments below.  If you have any additions to propose, please post them in the comments below, as well.

     
    • Rohit Tripathi 2:41 pm on April 3, 2014 Permalink

      +1 For Everything. Especially, the guideline change related to Screenshots. I hope it goes through.

      • Edward Caissie 4:19 pm on April 3, 2014 Permalink

        Aside from maintaining the premise of not allowing any sort of spammy / marketing type images I would be fine with opening the screenshots to something relatively easy to configure at installation provided how to create the screenshot’s “look” is documented in at least the `readme.txt` file … or similar documentation available to the end-user within the theme’s package.

    • tskk 2:57 pm on April 3, 2014 Permalink

      How much time do we have before recommendation of using theme customizer turns into requirement?

      • Chip Bennett 2:59 pm on April 3, 2014 Permalink

        Who knows? It’s something that may never happen. Right now, we just want to promote it as a best practice.

        Is there any particular reason not to want to integrate Theme options into the Customizer? I’m genuinely curious what those reasons might be.

        EDITED TO ADD: We made the Settings API *recommended* years ago, and have never made any move toward making it *required*.

        • tskk 3:03 pm on April 3, 2014 Permalink

          the left pane is very cramped,
          no framework like OF which has all the controls we need,
          no drag and drop setting/option

          • Chip Bennett 3:06 pm on April 3, 2014 Permalink

            True, the left pane can be a bit cramped – but I think they payoff (real-time preview of the setting change) more than compensates. Also, if you segregate your Theme options into logical sections, it makes the UI much more manageable.

            Almost every control imaginable is built-in to the API. Which one(s) are you missing, specifically?

            Can you explain the drag-and-drop? I’m not sure what you mean.

            • tskk 3:21 pm on April 3, 2014 Permalink

              The ability to use images in place of radio buttons like in optionsframework, ability to have a vertical accordion like i have in optionsframework. Is it possible to add stand alone text and maybe apply css to that text?

              If you see one of the cyberchimp themes, they have a drag and drop option where user can drag page elements around like reordering the site elements.

          • Zulfikar Nore 4:03 pm on April 3, 2014 Permalink

            I think with a little thought the drag and drop for page builders can also be integrated in the customizer.

            My thoughts here are based on the new incoming Widget control section which has some drag and drop options for the widgets.

        • tskk 2:08 am on April 4, 2014 Permalink

          Also customizer doesn’t have a reset button, import/export option.

          • Schwarttzy 4:12 am on April 9, 2014 Permalink

            import/export would be sweet for the customizer

    • daveshine (David Decker) 3:39 pm on April 3, 2014 Permalink

      *Tranlation-ready* should totally be REQUIRED!

      Why?
      Translations are essential, and I never understand why an international used platform like WordPress.org/themes should promote untranslateable themes in the year 2014+ ?!?

      *Translation-ready* also means a theme can be customized with another tone/ type/ of the same language, for example, still in English (but use British English, formal tone for business etc.).

      Also, to have it as a requirement will improve overall theme code and quality – and especially make them more user-friendly! And not to forget, it will all help prepare for upcoming launch of language packs (that are prepared in core, but “not yet launched” here on .org for themes, plugins).

      Standards:
      There are already standards all there, for years already:

      • load_theme_textdomain()
      • load_child_theme_textdomain()
      • all the translation functions for strings like __(), _e() plus all the related stuff there…
      • using sprintf() and printf() to keep as much markup as possible out of translation strings
      • using _x() context translation functions to add context to strings and/ or be better help for translators

      I don’t know any reason why *Translation-ready* should not be required for any theme here (and plugins also!)? So, if someone has such a reason for me, I am eager to know what speaks against all that.

      As a international developer and user I am fighting the good fight for years already, to get more and more themes, child themes and plugins translateable at all, and moreover to have them in the “standards” (see points above). WordPress.org theme repository should be the leading example in this field!

      PLEASE make it a requirement! Thanks so much!

      Dave from Germany :)

      • Chip Bennett 3:55 pm on April 3, 2014 Permalink

        I agree that making it *required* is our end goal. But we have to start somewhere. We have to have an established, objective string-translation standard. Then we have to educate developers how to implement it – and we have to educate reviewers how to evaluate Themes against it. We’re simply not ready for that.

        I want to get there. We need to get there. I agree that WPORG-hosted Themes should all be translatable. But we’re simply not at the point that we can make it required, and be able to enforce it fairly and consistently.

      • Ulrich 4:55 pm on April 3, 2014 Permalink

        I think it would be great if every theme and plugin were internationalized. From my experience reviewing themes a number of theme developers do not have a deep understanding of PHP so they find it difficult to internationalize the theme. By placing it as a requirement we are increasing the level of entry. Do we really want to do that?

        Somehow I think it is a theme developers decision to choose to support i18n or not. Users can show the demand by asking for i18n support.

        We did once discuss what is needed for a theme to be allowed to use the translation-ready tag. At the time we decided that all strings had to be internationalized and the header should contain the text domain but does not need to include a POT. How far do theme reviewers enforce best practices for creating strings?

      • Justin Tadlock 5:01 pm on April 3, 2014 Permalink

        I’m one of the biggest supporters of theme authors internationalizing their themes that you can find. I’ve done this myself for many years. However, I cannot get behind this being a requirement, at least at this point in time. The reason for this is that it is a huge barrier to entry. I probably would’ve never made my first theme if I had to do this.

        We need to start with education. I’d also like to see all articles in the Codex and Handbooks that provide code examples with text strings to actually show those strings with the proper functions.

      • Sami Keijonen 5:30 pm on April 3, 2014 Permalink

        I’m with David here. Make it required. This has been in theme/plugin development best practice for so long that it should be required. I don’t mind if it makes a little bit harder to get your theme on WP.org. It should be about quality, not quantity.

        Do you have data how many new themes are not Tranlation-ready?

      • wpweaver 8:02 pm on April 8, 2014 Permalink

        I am 100% for making theme translatable on the front side (visitor view).
        But, as usual, my theme (Weaver II) is on the extreme edge of things.

        It has a very complex admin interface, full of long, complex, and technical descriptions. It uses complex HTML and scripts to make the admin user interface work with its hundred of options.

        Making this in a translatable form (it has LOTS of direct HTML output) is next to impossible. And this doesn’t even mention how difficult it would be to get technically correct translations.

        But for the visitor side, my theme has already been translated to something like 25 languages, and that number is growing.

        So – visitor side translation capable – REQUIRE asap.
        admin side translation capable – leave recommended.

    • Frumph 3:45 pm on April 3, 2014 Permalink

      … no, no and no.

      If you want to write up guides and point to them to the designers, go for it.

      • daveshine (David Decker) 3:54 pm on April 3, 2014 Permalink

        Yes, sometimes to much guides/ guidelines make things more complicated and could take away some passion…!

        However, it’s not only about design here: it’s also about usability, security of code, making stuff translateable, avoiding aggressive marketing in themes etc. Over the years, the experience was some guidelines should be in place.

        • ruphel 12:17 am on April 4, 2014 Permalink

          With David 100% on this one.,make it rquired

    • Morgan Feeney 3:47 pm on April 3, 2014 Permalink

      Theme options in the customizer! The purpose of which is for live preview of your website, including styles, now widgets too, so why exclude any other content which can be edited on the back end from this?

      It makes total sense to me, I am a designer and front-end guy and I think it would be of benefit.

      if WordPress is to carry on competing on a global scale with new and existing CMS, anything which enables a real-time preview into how the site looks with on-the-fly changes being made only makes it a stronger contender in the long-run.

    • Zulfikar Nore 4:13 pm on April 3, 2014 Permalink

      +1 on all proposed changes!

      The Screenshot issue has been too stringent – allowing for configurable options to be included in the screenshot is a sane proposal.

    • Justin Tadlock 5:07 pm on April 3, 2014 Permalink

      I still disagree with the requirement for license info to be placed into readme.txt. WordPress itself uses a license.txt file for this. I’d be more supportive of this if we allowed for license info to be placed in either license.txt or readme.txt.

      • Emil Uzelac 5:42 pm on April 3, 2014 Permalink

        Wiki has nice readme.txt example:
        http://en.wikipedia.org/wiki/README

        • README General information
        • AUTHORS Credits
        • THANKS Acknowledgments
        • ChangeLog A detailed changelog, intended for programmers
        • NEWS A basic changelog, intended for users
        • INSTALL Installation instructions
        • COPYING / LICENSE Copyright and licensing information
        • BUGS Known bugs and instructions on reporting new ones
      • Chip Bennett 5:55 pm on April 3, 2014 Permalink

        I’m fine with that; I’ll update the post accordingly.

      • Catch Themes 3:22 pm on April 5, 2014 Permalink

        Yes I agree with Justin… It should be either readme.txt or license.txt.

    • Ron 5:23 pm on April 3, 2014 Permalink

      Most of the guidelines seems to be in order but I have to disagree with the Custom Logo being disabled by default. Unlike the favicon, a logo affects the overall design of a theme.

      Currently, we require that “default” logos be generic/unbranded, but generic/unbranded logos are of no benefit to the end user. Likewise, Theme-branded logos are of no benefit to the end user.

      True, but what about one that is not visible? There might not be any benefit to the end user whether a custom logo is enabled or disabled by default but then why make it a requirement?

      If the generic logo requirement isn’t good enough then maybe we could even have a standard logo image for every theme with a logo option to use. Maybe a WordPress logo?

      • Chip Bennett 5:55 pm on April 3, 2014 Permalink

        You might be misunderstanding what “disabled by default” means. It just means that, if the user configures a logo, then that logo is output; otherwise, if the user does not configure a logo, then no “default” logo is output.

        I’d be curious to see an actual case where a “disabled by default” custom logo would adversely impact a Theme’s design.

        • Ron 6:10 pm on April 3, 2014 Permalink

          Yup, that’s exactly how I understood the guideline. It might not be a very big difference but a visible logo helps a user envision the overall look of the theme after he/she either removes or changes it.

          My point is, are there actual benefits at all from a custom logo being either enabled or disabled by default that would command it to be a requirement? If there aren’t any then this would just unnecessarily add to the growing set of guidelines.

          • Chip Bennett 6:20 pm on April 3, 2014 Permalink

            Yes, there are actual advantages. A company is very likely to have a pre-defined logo that they would then configure for use with the Theme. But an individual (or even a non-commercial entity or group) likely won’t have a logo. For them, it is detrimental to have an arbitrary image (or worse: an image that says “Logo”) prominently displayed on their site. (Note: it would be equally bad to have an image displaying the Theme name prominently displayed on their site.)

            This is not an onerous guideline. It simply means wrapping the logo output in if ( '' != $themename_options['logo'] ) {}.

            • Ron 6:50 pm on April 3, 2014 Permalink

              A company is very likely to have a pre-defined logo.
              An individual (or even a non-commercial entity or group) likely won’t have a logo.

              Is this really the case? I think a user, whether intending a theme for company or individual use would decide on what theme to use basing on it’s looks (screenshot & preview). The visibility of a logo and seeing its positioning helps make that decision. I think it’s pretty reasonable to expect a user who chooses a theme that has a logo option, to use one. I think the fact that logos are required to be user-configurable is good enough.

              I’m not really that much against it but I just can’t see the guideline as an actual benefit to warrant being a requirement.

            • Chip Bennett 9:26 pm on April 3, 2014 Permalink

              I doubt that users primarily base their decision on whether or not a Theme supports a custom logo, nor should individuals be barred from using a Theme simply because it outputs a logo, and they don’t have or need one.

              The decisions to add this guideline is born out of the numerous instances of logos being problematic during the review/approval process. This guideline actually simplifies things for Theme developers, who no longer have to come up with a “generic/unbranded” logo to output by default (most of the time, Themes have had a Theme-branded default logo, and had to go to the extra effort to create an unbranded logo).

        • Catch Themes 3:26 pm on April 5, 2014 Permalink

          I think the only problem with this will be in Theme Preview. If we have option to make that logo available in preview then there will be no effect on design. For example in Catch Kathmandu theme, I added in generic logo just to show in Theme Review at http://wp-themes.com/catch-kathmandu/

    • Emil Uzelac 6:20 pm on April 3, 2014 Permalink

      +1 for all @chipbennett!

      • alex27 10:34 am on April 4, 2014 Permalink

        I totally agree with Chip on the logo. What good does the fancy custom logo does to the user anyway, when theme authors do not provide source files to customize it (not that I think we should require it).

    • Codice e Bella 2:47 am on April 4, 2014 Permalink

      I only developed my first theme for the repository about a month ago. While I created a very basic and simple theme to learn the process so that I could start developing themes that weren’t so “basic”, I didn’t think learning to develop it as translation-ready was that difficult. Someone else said it should be about quality, not quantity. Even as a new developer to the theme repository, I would agree with that, and say making it a required practice shouldn’t stop someone from developing new themes for the repository.

    • mudthemes 6:57 am on April 4, 2014 Permalink

      Screenshot Proposal is brilliant.

      To make it more transparent, why not ask theme developers to include the exact method used to achieve the screenshot in readme.txt or link the plugins/widgets used to create it.

    • Frank Klein 11:47 am on April 4, 2014 Permalink

      Screenshot

      I think that the screenshot should reflect the intended use case of the theme, so a blogging theme (like TwentyThirteen) should show the blog index. A theme with a front page template (like TwentyTwelve) could show this specific template.

      I’d argue though that themes should always show the front page (whether a blog index or static page). It is okay to have a screenshot that shows user-configurable options already set up. However the screenshot should not contain elements that are dependent on the installation of plugins.

      Translation-Ready

      I would be in favor of making this a requirement. I agree with Justin Tadlock that this represents a further barrier to entry for theme developers. But I would say that we need to think about the users first and only then about the developers.

      With an increasing number of WordPress users that don’t have English as their native language, themes that are not translated are effectively useless. So in this case, we should side with the users and make this a requirement.

      I would also add that Internationalization is no longer a mystery or novelty. With the amounts of tutorials and WordCamp talks on this subject, learning this is not an issue.

      Custom Logos

      I agree fully with this. Custom logos are an option. As such they should optional.

      Licensing information

      Having a file (whatever name it has) that contains all the licensing information for the theme is a big help for reviewers. It also makes the life for users easier that want to use themes for their own projects, as they don’t have to worry about finding out what licenses apply to the different elements of a theme.

    • Devin Price 4:09 pm on April 4, 2014 Permalink

      +1 for all these changes.

      I think we should put a note about how to properly enqueue Google fonts as this has come up a lot in my recent reviews. It could also perhaps be somewhat automated: https://github.com/Pross/theme-check/issues/6

      I would also love to get more theme support for translations. Perhaps there is a better way to match theme developers who are knowledgeable in this area with developers who wish to learn it?

    • Catch Themes 3:32 pm on April 5, 2014 Permalink

      +1 for the changes. Ready to work on Theme Review. Will need to adjust some on my themes as well. Thanks :)

    • Scott Smith 2:18 am on April 7, 2014 Permalink

      How should I be escaping Custom CSS? I crawled the internet for a while and wasn’t able to find a helpful bit of advice on this.

      • Frank Klein 12:00 pm on April 7, 2014 Permalink

        Id’ say that you can use htmlspecialchars(). Make sure to pass the blogs charset to it along with the appropriate quotes flag: htmlspecialchars( $css, ENT_QUOTES, get_option( ‘blog_charset’ ) );

    • Catch Themes 12:49 pm on April 17, 2014 Permalink

      Has this guideline been finalize. Can we use this proposed guidelines while review new themes. WordPress 3.9 is out now. But I don’t see final guidelines.

      • Chip Bennett 12:57 pm on April 17, 2014 Permalink

        New Guidelines are typically enforced one month after final release, to allow sufficient time for adoption.

  • Chip Bennett 12:23 pm on April 2, 2014 Permalink
    Tags:   

    Theme Review Incentive: March 2014 Winners 

    We are pleased to announce the following winners for March 2014.

    New Themes

    Theme Updates

    Please post a comment below, indicating your Featured Theme selection.

    Monthly Stats

    • New Themes:
      • Approved/Live: 97
      • Reviewers: 15
      • Eligibility: 10
      • Reopened: 19
      • Missed Eligibility due to reopened tickets: 2
    • Theme Updates
      • Approved/Live: 468
      • Reviewers: 19
      • Eligibility: 117

     

    Featured Theme Rotation

    Per the program changes, all Themes but the following will be removed from the list:

    • Twenty Fourteen
    • Twenty Thirteen

    Note: review totals are taken as a snapshot at an arbitrary point in time, based on this Theme-Trac report, and varying the filters as appropriate.  Totals are as accurate as reasonably possible.

     
    • acosmin 12:26 pm on April 2, 2014 Permalink

      Congrats to the winners! :)

    • tskk 12:34 pm on April 2, 2014 Permalink

      Thanks Chip and congratulations to other winners.
      I will continue with Alexandria.

    • ThinkUpThemes 12:39 pm on April 2, 2014 Permalink

      Congratulations guys!

    • alex27 1:09 pm on April 2, 2014 Permalink

      I’ll go with Sugar & Spice for this month. Thank you!
      http://wordpress.org/themes/sugar-and-spice

    • Rohit Tripathi 1:31 pm on April 2, 2014 Permalink

      Hi Chip, I will go with Fifteen -> http://wordpress.org/themes/fifteen/

      Congratulations to All and Thank you!

    • PageLines 1:45 pm on April 2, 2014 Permalink

      Congrats to everyone! We’ll go with DMS -> http://wordpress.org/themes/dms/

    • Themonic 1:54 pm on April 2, 2014 Permalink

      Congrats guys!

      @Chip So even the reopened tickets like these won’t count?
      https://themes.trac.wordpress.org/ticket/17544
      https://themes.trac.wordpress.org/ticket/17281

      • Chip Bennett 4:30 pm on April 2, 2014 Permalink

        Correct. If Emil or I have to reopen the ticket due to required issues that are missed prior to approval, then the ticket won’t count toward the incentive.

        • Themonic 10:29 am on April 8, 2014 Permalink

          The thing I wanted to show you was, that those were super minor issues and could have easily approved while asking the theme author to submit a new version asap. Even after 12 reviews this month, I didn’t make it to the list :( . I am relatively a new reviewer ~100 reviews, I am kinda feeling like if you have to then you can re-open any ticket this way and then just due to couple of tickets whole contribution effort seems to be wasted. If I am feeling this than what about the would be reviewers, wanting to get into theme reviews? I hope you get my point.

          May I also propose a small change :

          Approved/Live: 97
          Reviewers: 15
          Eligibility: 10
          Reopened: 19
          Missed Eligibility due to reopened tickets: 2

          Eligibility now 97/10 = 9.7

          Eligibility should be 97 – 19 = 78

          New Eligibility = 78/10 = 7.8

          This is more fair right?

          The current program is kind of perfect. Kindly look into it based on the above, it would be great if something can be done for reopened tickets with minor issues.

          • Chip Bennett 12:00 pm on April 8, 2014 Permalink

            97-19 is not correct. The 97 is the number of Themes approved and made live. Of the 97, 19 had to be reopened but were subsequently re-approved, and then made live.

            I am kinda feeling like if you have to then you can re-open any ticket this way…

            We’re not trying to reopen tickets for minor issues. We have no desire to “punish” reviewers for minor mistakes, nor do we have any desire to create more work for everyone involved. That’s why I published this list: so you know exactly the things I’m looking for.

            …and then just due to couple of tickets whole contribution effort seems to be wasted. If I am feeling this than what about the would be reviewers, wanting to get into theme reviews?

            Honestly, if the only reason that people are reviewing Themes is to win the incentive, then the entire system is failing, and w’ll have to reconsider it. The Theme Review Team is a community contributor group, which exists in order for WordPress community members to have an opportunity to contribute back to the WordPress project. Anyone involved merely for the incentive is involved for the wrong reasons.

    • Catch Themes 2:47 pm on April 2, 2014 Permalink

      Thanks Chip and Congratulations to all the winners.
      I will go with Catch Kathmandu http://wordpress.org/themes/catch-kathmandu/

    • Zulfikar Nore 7:55 pm on April 2, 2014 Permalink

      Congratulations to all winners – especially Catch Themes, good to see you in the mix :)

      I’ll go with Itek for this month: http://wordpress.org/themes/itek – thank you

    • robin90 7:10 am on April 3, 2014 Permalink

      Thanks Chip and Emil for their support and Congratulations to all the winners. I will go with Spacious http://wordpress.org/themes/spacious

    • talentedaamer 3:01 pm on April 3, 2014 Permalink

      congratulations to all winners, specially new for this month (pagelines, catchthemes) keep it up.

    • CyberChimps 10:30 pm on April 7, 2014 Permalink

      I would like an explanation as for why we didn’t win when we had more reviews then some of the winners.

      My staff has informed me that two of our reviews were discredited?

      I seems odd that an entire review should be discredited if a ticket only has to be re-opened once. Even if a review has to be reopened before final approval, the reviewer still did the majority of the review did they not?

      • Emil Uzelac 11:54 pm on April 7, 2014 Permalink

        As previously noted: if the ticket gets reopened that will resolve getting your ticket discredited.

      • Chip Bennett 12:25 am on April 8, 2014 Permalink

        The rules are stated, quite clearly:

        So, starting this month, any ticket that has to be reopened after being closed as “approved” will not count toward the incentive program.

        So yes: if a ticket gets reopened, even once, after approval, it doesn’t count toward the incentive. The reasoning is explained in the linked post. We’re not looking for nit-picky things when we do a final approval audit (see my checklist above). We’re not looking for excuses to reopen tickets, to create more work for everyone involved. If you disagree with the assessment to reopen any particular tickets that your staff have completed, you’re welcome to comment, in-ticket, to discuss it.

        • CyberChimps 3:23 am on April 8, 2014 Permalink

          We were under the impression that this contest was designed so that the admins of WordPress.org weren’t the ones deciding which themes get featured?

          Yet now you’re telling us a new rule has been put in place that just so happen to discredited two of our reviews pushing us out of contention to win the contest? Hmm.

          A rule that basically allows any admin the ability to discredit any reviews they want by simply re-opening a ticket essentially granting the admins the power to determine who wins the contest. I thought this was the very thing we were trying to get away from?

          I can easily understand why such a rule might be necessary for tickets that require being open more then once, but a ticket that has only been reopened once should not be disqualified.

          We are volunteering to contribute reviews, and now you’re telling us we’re not even allowed a single mistake?

          Theoretically you can find a reason to reopen any ticket at any time.

          This rule is completely unfair.

    • CyberChimps 5:04 am on April 8, 2014 Permalink

      CyberChimps did 10 reviews, and legitimately won this months review contest for the following reasons:

      1) Selective reviewing.

      We keep getting stuck with the themes that the other theme reviewers know have a chance of being re-opened. Everyone has figured out that if they target themes from reputable theme shops including Automatic the odds of the ticket being re-opened are lower, and they have to do less work per review.

      Go take a look at your winners this month and decide for yourself.

      It is an unfair practice that you guys are rewarding.

      2) The reopen ticket rule is not fair.

      I understand why this rule was put in place, but almost any ticket could be reopened at any point for any reason. It isn’t a fair metric to judge disqualifying a review on. We’re putting in hard work that isn’t being credited because we’re getting stuck with the themes other reviewers don’t want to review, and then we’re being disqualified for reviewing them. How does that make sense?

      Authors should have at least 1 reopen per review, we are volunteering, an occasional mistake shouldn’t be punished, especially on difficult tickets that require more oversight.

      3) Not enough tickets. It’s nearly impossible to get more then 10-15 themes to review per month because everyone is still trying to assign themselves tickets and still selectively picking tickets. We easily could have done another 10-15 reviews this month but couldn’t even if we wanted to.

    • tskk 5:45 am on April 8, 2014 Permalink

      1) Selective reviewing, not everyone has the same technical know how, they pick tickets they can review.
      2) If the ticket is difficult, Chip has mentioned to ask him for help before approving the theme, he said he will be happy to help as much as required before approving the theme.

      • CyberChimps 6:27 am on April 8, 2014 Permalink

        1) We agree, which is why it is not fair to discredit reviews that require being re-open a single time. If a theme requires that much additional oversight there is typically a reason. Or at least a determination should be made, not just an automatic disqualification. If the reviewer put in considerable time to review a theme and then gets it disqualified that isn’t right.

        Either way, there is still a reviewers cherry picking tickets who are being rewarded for their practices, and those who take on the less desirable tickets are being punished.

        2) We received no help for the tickets that disqualified us out of the contest. The tickets were reopen and we lost. That’s what happened, and will continue to happen to legitimate reviews as long as this rule stands.

        • Emil Uzelac 12:04 am on April 9, 2014 Permalink

          Untrue. In both tickets the explanation was provided.

    • Vivacity InfoTech Pvt. Ltd. 7:39 am on April 8, 2014 Permalink

      Congratulations to all winners!

  • Chip Bennett 8:30 pm on March 3, 2014 Permalink
    Tags:   

    Theme Review Incentive: February 2014 Winners 

    As you may recall, last month we announced changes to the Theme review incentive program, both opening up the incentive to more winners, and adding in a measure of accountability.  Per those changes, we are pleased to announce the following winners for February 2014.

    New Themes

    Theme Updates

    Please post a comment below, indicating your Featured Theme selection.

    For the month, there were a total of 88 new Themes added to the directory by 21 reviewers, and 369 Theme updates added by 16 reviewers. The eligibility requirements for this month were 8 New Themes approved, and 92 Theme updates approved.

     

    Featured Theme Rotation

    Per the program changes, all Themes but the following will be removed from the list:

    • Twenty Fourteen
    • Twenty Thirteen

    Note: review totals are taken as a snapshot at an arbitrary point in time, based on this Theme-Trac report, and varying the filters as appropriate.  Totals are as accurate as reasonably possible.

     
    • tskk 9:03 pm on March 3, 2014 Permalink

      Thanks Chip,I will continue with Alexandria.
      http://wordpress.org/themes/alexandria

    • Rohit Tripathi 9:16 pm on March 3, 2014 Permalink

      Congtratulations to all the winners.

      I would Like to Continue with Sixteen (http://wordpress.org/themes/sixteen/ ) for this month as well.

      Thank You. :) :)

    • Emil Uzelac 9:17 pm on March 3, 2014 Permalink

      Good job everyone!

    • pagelines 9:26 pm on March 3, 2014 Permalink

      Hey guys,

      Seems like we made the cut-off point too (based on the report you ran as well), we have 8 matches, and the eligibility requirement is 8. Shouldn’t we be in the winners list for new themes too, then?

      • alex27 11:11 am on March 4, 2014 Permalink

        For transparency sake would it be possible to make a snapshot (a screenshot?) of the report used from the moment winners are announced?

        • Chip Bennett 3:26 pm on March 4, 2014 Permalink

          I’m not particularly inclined to do that, for a few reasons: one, all the information is available via Theme-Trac reports, using the available filters; two, unless I have a way to automatically exclude ineligible reviews (tickets that had to be reopened by admins post-approval), I don’t want to do anything that would emphasize that some reviewers had a certain number of tickets reopened (the point of the program is to emphasize the *positive*, not the *negative*); and three, trying to take and post screenshots of a Trac report adds administrative time and complexity to the process, for little-to-no gain.

      • Catch Themes 2:52 pm on March 4, 2014 Permalink

        I thought both New Themes and Theme Updates combined result make the eligibility requirement. Was bit confusing.

        • Chip Bennett 3:31 pm on March 4, 2014 Permalink

          They’re counted separately, because new Themes and Theme updates are prioritized differently, and also because the amount of work involved in reviewing and approving them is considerably different.

    • robin90 1:45 am on March 4, 2014 Permalink

      Thanks Chip. And congratulation to all the winners. I will like to go with Radiate http://wordpress.org/themes/radiate :)

    • alex27 6:22 am on March 4, 2014 Permalink

      Great job! Congrats!

    • cyberchimpscode 9:29 am on March 4, 2014 Permalink

      Thank you, I would like to choose Responsive http://wordpress.org/themes/responsive

      Congratulations to the other winners.

    • Zulfikar Nore 11:09 am on March 4, 2014 Permalink

      Congrats to all and once again, great job by all involved.

      I’d like to continue with Ridizain please: http://wordpress.org/themes/ridizain

    • Jose 12:45 pm on March 4, 2014 Permalink

      Awesome job folks! Congrats all around.

    • Catch Themes 2:50 pm on March 4, 2014 Permalink

      Congratulation to all the winners :)

    • talentedaamer 3:42 pm on March 8, 2014 Permalink

      Congratulations to all the winners keep it up. :-)

    • Zulfikar Nore 8:39 pm on March 8, 2014 Permalink

      Just a nag :)

      Don’t see Radiate in the mix – has the list be refreshed yet?

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