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
          (body_class/post_class)
        • 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

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.

Feedback

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