Meeting Minutes 06/11/15

Per our meeting yesterday and the comments on the earlier post, the Theme review requirements have been modified. Additions are highlighted in red, and deletions are struck-out:

A theme must meet all of the following requirements to be included in the theme repository.

Along with these checks you should also make sure you run the theme through the theme check plugin. It automatically checks for all the required items. You can find a full list of what it checks here.


  • If the theme has the tag ‘accessibility-ready’ then it needs to meet these requirements.


  • No PHP or JS errors.
  • Include at least index.php and style.css.
  • Have a valid DOCTYPE declaration and include language_attributes.
  • Sanitize everything.
  • No removing or modifying non-presentational hooks.
  • No shortcodes are allowed.
  • Support the following WordPress-generated CSS classes:
    • alignleft
    • alignright
    • wp-caption
    • wp-caption-text
    • gallery-caption
    • sticky (can be unstyled)
    • bypostauthor (can be unstyled)
    • screen-reader-text
  • Must meet all uploader/Theme Check required tests
  • Provide a unique prefix for everything the Theme defines in the public namespace, including options, functions, global variables, constants, post meta, etc.

Core Functionality and Features

  • Use WordPress functionality and features first, if available.
  • Don’t include admin/feature pointers.
  • No custom post types and no custom taxonomies.
  • No pay wall restricting any WordPress feature.
  • No disabling of the admin tool bar.
  • Use get_template_directory() rather than TEMPLATEPATH to return the template path.
  • Use get_stylesheet_directory() rather than STYLESHEETPATH to return the stylesheet path.
  • Avoid hard coding to modify content. Instead, use function parameters, filters and action hooks where appropriate. For example wp_title should be modified using a filter.
  • Able to have child themes made from them. (Child theme ready)
  • Include comments_template().
  • The theme tags and description must match the what the theme actually does in respect to functionality and design.
  • Use template tags and action/filter hooks properly.

Presentation vs. Functionality

  • Must not not generate user content, or configure non-theme site options or site functionality.


  • Any custom features, options or any limitations (for example menu restrictions), should be explained. Enough documentation should be provided.


  • If implemented, disable favicons by default and have the ability for users to override.


  • All theme text strings are to be translatable.
  • Include a text domain in style.css
  • Use a single unique theme slug – as the theme slug appears in style.css. If it uses a framework then no more than 2 unique slugs.
  • Can use any language for text, but only use the same one for all text.


  • Be 100% GPL and/or 100% GPL-compatible licensed.
  • Declare copyright and license explicitly. Use the license and license uri header slugs to style.css.
  • Declare licenses of any resources included such as fonts or images.
  • All code and design should be your own or legally yours. Cloning of designs is not acceptable.


  • Theme names must not use: WordPress, Theme.
  • Spell “WordPress” correctly in all public facing text: all one word, with both an uppercase W and P.

Options and Settings

  • Save options in a single array.
  • Use sane defaults and don’t write default setting values to the database.
  • Use edit_theme_options capability for determining user permission to edit options, rather than rely on a role (e.g. “administrator”), or a different capability (e.g. “edit_themes”, “manage_options”).
  • Use the Customizer for implementing theme options.


  • Don’t include any plugins. A theme can recommend plugins but not include those plugins in the theme code.
  • Don’t do things in a theme considered plugin territory.


  • The Screenshot should be of the actual theme as it appears with default options, not a logo or mockup.
  • The screenshot should be no bigger than 1200 x 900px.

Security and Privacy

  • Don’t phone home without informed user consent. Find out more about security here.
  • Make any collection of user data “opt-in” only and have a theme option that is set to disabled by default. Validate and sanitize untrusted data before entering into the database. All untrusted data should be escaped before output. (See: Data Validation.)
  • No URL shorteners used in the theme.
  • Use esc_attr() for text inputs and esc_textarea() for textareas.

Selling, credits and links

  • If you are a theme shop you should be selling under GPL to be in the repo.
  • If the theme adds a footer credit link, there should only be one (link to WordPress does not count)

Stylesheets and Scripts

  • No hard coding of scripts, styles and Favicons unless a browser workaround script. Everything should be enqueued.
  • No analytics or tracking.
  • No minification of scripts or files unless provide original files.
  • Required to use core-bundled scripts rather than including their own version of that script. For example jQuery.
  • Include all scripts and resources it uses rather than hot-linking. The exception to this is Google libraries.
  • If a tag is used in style.css the theme should support that feature or adhere to what that tag stands for. For example custom background or header.


It’s worth noting we are working to automate a lot of the above requirements.

Along with the required items, you should also consider the recommended items. The recommended items are there to make sure your theme is the best it can be and good advice to include as best practice.

If you have any questions regarding what was updated/clarified, please ask in the comments.

Please note that we will very likely continue to look for ways to clarify and simplify the Requirements, including more extensive usage of code examples, explanations, and clarifications linked from the Requirements elsewhere in the Theme Review Handbook.