• Themes are recommended to use current recognized version(s) of (X)HTML and CSS, and to test using one of the following methods:
  • Themes should not support backward compatibility for more than one prior major WordPress version (currently, that means versions prior to WordPress 3.6)
  • Themes are recommended to use theme-slug as this unique slug
  • Theme is recommended to incorporate the following WordPress core features, but is not required to do so. However, if incorporated, features must support the core WordPress implementation:
  • Themes are recommended to hook stylesheet and script enqueue callbacks into `wp_enqueue_scripts`
  • 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 ))
  • Text Direction: bloginfo( 'text_direction' )
    • is_rtl() for conditional statements (recommended)
  • Theme is recommended to include:
    • 404.php
    • archive.php
    • page.php
    • search.php
    • single.php
    • header.php (via get_header())
    • footer.php (via get_footer())
    • sidebar.php (via get_sidebar())
      • Note: header.php, footer.php, and sidebar.php include variations such as: sidebar-left.php, sidebar-right.php, sidebar-footer.php, etc.
  • Theme may optionally include:
    • attachment.php
    • author.php
    • category.php
    • date.php
    • editor-style.css
    • image.php
    • tag.php
  • Themes are recommended to use core markup for the following forms, using the indicated template tag:
    • Login Form: Must be included using wp_login_form()
    • Search Form: Must be included using get_search_form()
      • Themes may optionally customize the search form, as searchform.php

    Submitted themes are recommended not to include files named like the following. However, if such files are used, Themes arerequired to provide end-user documentation explaining how to use them:

    • page-foobar.php
    • category-foobar.php
    • tag-foobar.php
    • taxonomy-foobar.php

    Note: The reason to avoid this template naming convention for publicly released Themes is to avoid surprising users that create a page with the “-foobar” slug and expect the default template. See Template_Hierarchy#Page_display.

  • Theme Settings and Data Security
    • Themes are recommended to use the Settings API to get and save form input data rather than rely on $_POST and $_REQUEST data directly.
    • Themes are recommended to use do_settings_sections() to output settings sections/fields, rather than hard-coding markup
  • Bundled Resources
    • Themes are required to state the copyright and license information for any bundled resources not covered by the Theme’s license statement. Themes are recommended to state this information in the Theme’s README documentation.
  • Credit Links
    • Themes may optionally designate Author URI and Theme URI in style.css.
      • Theme URI, if used, is required to link to a page specifically related to the Theme. If a demonstration site or page is being used, the content must be related to the theme itself.
      • Author URI, if used, is required to link to an author’s personal web site or project/development website.
      • Themes are recommended to provide at least one of these two links, in order to ensure Theme users have a point of contact for the Theme developer.
    • Themes may optionally include a public-facing credit link in the Theme footer.
      • If used, Themes are required to include no more than one such footer credit link.
      • Credit link, if used, is required to use either Theme URI or Author URI.
      • Credit link anchor text and title are required to be relevant and appropriate with respect to the linked site. Spam or SEO-seeded anchor text and titles may subject Themes to automatic rejection.
      • A second “Powered by” link for WordPress is also acceptable, with the link pointing to http://wordpress.org.
    • Themes may optionally include a Theme Option to display additional credit links or text.
      • If used, such options are required to be opt-in (i.e. disabled by default, rather than enabled)
      • If used, such options are recommended to provide user-modifiable text/links, rather than merely providing an enable/disable option
      • In general, such opt-in credit text/links are exempted from above-listed requirements regarding relevance and appropriateness. However, the Theme Review team reserves the right to prohibit such optional text/links if, at its sole discretion, a Theme abuses this option.
    • Themes may optionally include a Theme Option to display additional credit links or text.
      • In general, such opt-in credit text/links are exempted from above-listed requirements regarding relevance and appropriateness. However, the Theme Review team reserves the right to prohibit such optional text/links if, at its sole discretion, a Theme abuses this option.
    • Credit Link Removal
      • Since Themes are GPL (or compatible), Theme authors are prohibited from requiring that these links be kept by Theme users. An appropriate way to ask for Theme users to keep a link to the author’s website is as follows:

      “It is completely optional, but if you like the Theme I would appreciate it if you keep the credit link at the bottom.”

  • Theme Documentation
    • Themes are recommended to include a readme.txt file, using Plugin readme.txt markdown.
    • In lieu of a readme.txt file, Themes are recommended to include a changelog, indicating version-to-version Theme changes.
    • Please be clear about the following in the documentation included with your Theme. The following helps many users over any potential stumbling blocks:
      • Indicate precisely what your Theme and template files will achieve.
      • Adhere to the naming conventions of the standard Theme hierarchy.
      • Indicate deficiencies in your Themes, if any.
      • Clearly reference any special modifications in comments within the template and stylesheet files. Add comments to modifications, template sections, and CSS styles, especially those which cross template files.
      • If you have any special requirements, which may include custom Rewrite Rules, or the use of some additional, special templates, images or files, please explicitly state the steps of action a user should take to get your Theme working.
      • Provide contact information (website or email), if possible, for support information and questions.

      It is also recommended, both for standardization and to minimize any risks that may be associated with other file extensions, areadme.txt text file be used for documentation not made in comments within the template and stylesheet files. Other forms of documentation may be included in addition to the readme file at the Theme author’s discretion such as “Contextual Help” within the Theme’s “option” page(s).