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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Theme customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings..

New Guidelines (REQUIRED)

  • Required HooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. and Navigation
  • Theme Features
    • If implementing a site logo, Themes are REQUIRED to provide user-configuration of the logo via the core custom headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. 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 filterFilter Filters are one of the two types of Hooks They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. (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