Required

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

Themes that have 3 or more distinct issues may be closed as not-approved. However, theme authors may resubmit the theme once they’ve corrected the issues.

Along with these checks you should also run the theme through the Theme Check plugin. You can find a full list of what it checks here.

Note: If you are getting started with your first reviews, please read Become a reviewer

Accessibility Accessibility

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

Top ↑

Code Code

  • No PHP or JS notices.
  • Have a valid DOCTYPE declaration and include language_attributes.
  • Validate and/or sanitize untrusted data before entering into the database. All untrusted data should be escaped before output. (See: Data Validation)
  • No removing or modifying non-presentational hooks.
  • Must meet all Theme Check requirements
  • Provide a unique prefix for everything the Theme defines in the public namespace, including options, functions, global variables, constants, post meta, etc.

Top ↑

Core Functionality and Features Core Functionality and Features

Top ↑

Presentation vs Functionality Presentation vs Functionality

  • The theme options should not be pseudo custom post types and save non-trivial user data.
  • Non-design related functionality is not allowed. (See: Plugin territory examples)
  • Demo content may be used to show the user how the options work. Use starter content, existing content, or installation instructions instead of placeholder content. Installation instructions should only be visible to users with the edit_theme_options capability, not to visitors.

Top ↑

Documentation Documentation

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

Top ↑

Language Language

  • 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.

Top ↑

Licensing Licensing

  • 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.
  • Any copyright statements on the front end should display the user’s copyright, not the theme author’s copyright.

Top ↑

Naming Naming

  • Theme names must not use: WordPress, Theme.
  • Child themes should not include the name of the parent theme unless the themes have the same author.
  • Spell “WordPress” correctly in all public facing text: all one word, with both an uppercase W and P.

Top ↑

Options and Settings Options and Settings

  • Use the Customizer for implementing theme options.
  • 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”).

Top ↑

Plugins Plugins

  • Themes cannot include plugins.
  • Themes cannot require plugins to work.
  • Themes may only recommend plugins that are available in the WordPress.org Plugin Directory.
  •  Themes may use TGM Plugin Activation to recommend plugins.
  • Themes may include libraries such as option frameworks (these must pass the requirements).

Top ↑

Screenshot Screenshot

  • The screenshot should be a reasonable representation of what the theme can look like.
  • The screenshot may optionally show supported plugins, settings and templates.
  • The screenshot should not be a logo or mockup.
  • The screenshot should be no bigger than 1200 x 900px.

Top ↑

Privacy Privacy

  • Don’t phone home without informed user consent. Make any collection of user data “opt-in” only and have a theme option that is set to disabled by default.
  • No URL shorteners used in the theme.

Top ↑

  • Theme URI is optional.
  • If used, it must be about the theme we’re hosting on WordPress.org.
  • If the URI is a demo site, the content must be about the theme itself and not test data.
  • Using WordPress.org in the Theme URI is reserved for official themes.
  • Author URI is optional. If used it is required to link to an author’s personal website or project/development website.
  • Themes may have a single footer credit link, which is restricted to the Theme URI or Author URI defined in style.css.
  • Themes may also have an additional footer credit link pointing to WordPress.org.
  • If you are a theme shop you should be selling under GPL to be in the WordPress.org repo (See explanation).
  • Themes should not display “obtrusive” upselling. Examples.

Top ↑

Stylesheets and Scripts Stylesheets and Scripts

  • No hard coding of script and style files.
  • No minification of scripts or files unless you 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 hotlinking. The exception to this is Google Fonts.

Top ↑

Templates Templates

 

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.