Theme Review Chat Notes

Topic: Custom CSS

  • Discourage usage in favor of plugin
  • If used, must take security, permissions, escaping into account ( ping somebody capable of doing such review )
  • Security is biggest concern
  • Need good examples of _doing_it_right_

Sub-topic: requirement examples

  • Add items to
  • Encourage commenting but will have a weekly after meeting for examples

Next Week’s topic: Review Quality

  • Security
  • no-comment-approvals

Link to meeting in Slack:

Introducing the new auto assigning button!

Christmas is really here for the theme review team as we’ve got our auto assigning button. Check it out in our sidebar!

2014-12-22 at 15.42

From today, we are retiring the comment queue and this will be the way new reviewers get themes. If you are an existing reviewer, nothing should change for you. This button is designed to work for those who haven’t got a theme yet. A big thanks to @nacin for making this much needed button happen.

In the future we are going to also be assigning mentors, but that is in phase two for this button.


While the clock has started ticking on the 3.5 release grace period for Guidelines updates, I would like to discuss formalizing one other _doing_it_wrong() issue that has been implicitly enforced for some time now: use of query_posts().

Would anyone be opposed if we formally added query_posts() to Theme Check as a required stopper?

To understand why query_posts() is always inherently _doing_it_wrong(), see @nacin‘s WordCamp presentation You Don’t Know Query, and this great WordPress StackExchange answer by @rarst.

In short, if you are creating secondary queries, you should use WP_Query(), and if you’re modifying the main query, you should filter pre_get_posts.


#discussion, #guidelines

WordPress 3.5 Guidelines Revisions

It is that time of year again: with the upcoming release of WordPress 3.5, the Theme Review Team conducts its periodic review of the Theme Review Guidelines, and proposes any changes, either as necessitated by the new WordPress version, or otherwise as-needed.

The 3.5 release has little impact on Themes, and as such will be mostly invisible to Theme developers. One minor change will be support for HiDPI (i.e. “Retina”) screenshots. If there are any other 3.5-related changes that we need to account for, please post in the comments.

Here is the starting point for the discussion regarding changes to the Guidelines:

  • Change Theme Screenshot (screenshot.png) maximum dimensions from 300x225px to 600x450px. (Fixed per comment below)
  • New guideline under presentation-vs-functionality: Themes must not bundle custom post-content shortcodes
  • Change guideline: reduce criticality for Content Sidebar feature from required to recommended. (Themes would still be required to implement core Settings API if Theme incorporates content sidebar feature.)
  • Change criticality of add_theme_support( ‘automatic-feed-links’ ) from required to recommended. (Modified per comments below)

Please discuss in the comments, and recommend any additions or changes to these proposed Guidelines revisions.


Proposed WordPress 3.4 Guidelines Revisions

As we near the final release of WordPress 3.4, it is time to begin discussion and finalization of the related changes to the Theme Review Guidelines. Below are the proposed changes. Please discuss in the comments. We’ll do our best to keep this proposed list updated based on discussions in the comments.

New WordPress 3.4 Functionality

  • Custom Headers/Backgrounds
    • New and deprecated functions are already covered by existing Guidelines. Themes may OPTIONALLY provide backward-compatibility with pre-3.4 handling of custom backgrounds and headers
  • Child Themes
    • Child Themes will formally be allowed to be submitted for inclusion in the Theme repository.
    • Child Themes are REQUIRED to use an approved Theme as a Template (i.e. as the Parent Theme)
    • Child Themes are REQUIRED to demonstrate sufficient difference from the Parent Theme to warrant inclusion
    • Stand-alone Themes are REQUIRED to provide basic Child-Theme support, including:
      • Proper use of get_template_directory()/get_template_directory_uri() vs. get_stylesheet_directory()/get_stylesheet_directory_uri()
      • Proper enqueueing of stylesheets, and proper cascading of styles, including no inline styles in the Theme template
  • Backward Compatibility
    • Backward compatibility is covered by existing Guidelines. Per existing Guidelines (2 major WP versions required/1 major WP version recommended):
      • Themes MUST NOT support backward-compatibility for more than two major WordPress versions (i.e. 3.2).
      • Themes are RECOMMENDED NOT to support backward-compatibility for more than one major WordPress version (i.e. 3.3).
  • Theme Settings and Data Security
    • Themes are RECOMMENDED to incorporate Theme options into the WordPress core Theme customizer.

New Guidelines (REQUIRED)

  • Required Hooks and Navigation
  • Theme Features
    • If implementing a site logo, Themes are REQUIRED to provide user-configuration of the logo via the core custom header feature. (Exception: if incorporating both a site logo and custom header, the custom header is required to support the core custom header feature, and the custom logo is then required to be implemented via custom Theme option.)
  • Function Parameters, Filters, and Action Hooks
    • Themes are REQUIRED to use function parameters, filters, and action hooks where appropriate in order to modify content, rather than hard-coding:
      • wp_title: Themes are REQUIRED to modify output via wp_title filter. (Refer to Codex note.)
      • body_class()/post_class():
        • Themes are RECOMMENDED to modify output via filter
        • Themes may OPTIONALLY modify output via function parameter
          (body_class( $class )/post_class( $class ))

New Guidelines (RECOMMENDED)

  • Code Quality
  • Script Enqueueing
    • Themes are RECOMMENDED to enqueue the comment-reply script at the comment_form_before hook
      function theme_slug_enqueue_comment_reply_script() {
      	if ( comments_open() && get_option( 'thread_comments' ) ) {
      		wp_enqueue_script( 'comment-reply' );
      add_action( 'comment_form_before', 'theme_slug_enqueue_comment_reply_script' );


Clarifications to existing guidelines being enforced:

  • Presentation vs Functionality
    • Themes are REQUIRED to function as stand-alone code. Themes may OPTIONALLY integrate support for third-party Plugins; however, Themes are REQUIRED to degrade gracefully and to function fully and properly without any such Plugins active.


What else should be included? What should be revised? Let us know in the comments.

#3-4, #guidelines