A theme must meet all of the following requirements to be included in the The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party. 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

Warning: If you are a theme shop you should be selling under GPLGPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing The GPL is a ‘copyleft’ license This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples. to be in the The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. repo (See explanation). Example: If you have a Themeforest account and you’re selling themes on it, all those themes need to state on their sales page that they are 100% GPL compatible (Info).

Multiple Theme Author Accounts Multiple Theme Author Accounts

Warning: This is important,  so please read it carefully

You can have multiple accounts with the following restrictions:

  • You can’t have more than one (1) open ticket in any of the trac reports/queues or under review. That means you can’t have one (1) theme ticket from an account and another one from a secondary account, simultaneously open in any of the queues.
  • Failing to respect the above requirement will result in the closing of all tickets and not having the possibility to upload those themes again. Also, a 1 month no upload possibility for each ticket closed. Depending on the severity of the case, you might also end up with a permanent ban on all your accounts
  • To avoid penalties, we request that you disclose all your accounts by emailing us at themes[at]

Top ↑

Child themes Child themes

  • Child themes must include more than minor changes (such as font and colour changes) to the parent theme to be accepted. To make it easier on the reviewer, make sure you describe what modifications/features you did on top of the parent theme (in a ticket comment).

Top ↑

Accessibility Accessibility

Skip Links -Themes must include a mechanism that enables users to navigate directly to content or navigation on entering any given page. These links may be positioned off screen initially but must be available to screen reader users and must be visible on focus for sighted keyboard navigators.

A minimally conforming skip link must:

  • Be the first focusable element perceived by a user via screen reader or keyboard navigation.
  • Be visible when keyboard focus moves to the link.
  • Move focus to the main content area of the page when activated.

Note that this only applies if there is something to skip past, such as a menu or larger header section or secondary widget area before the main content.

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

Top ↑

Code Code

  • No PHP or JS notices.
  • 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. Theme nav menu locations and sidebar IDs are exceptions.

Examples Examples

No PHP errors, warnings or notices

Themes must support PHP7. This means there must be no PHP errors, warnings or notices when running on PHP7. 

WordPress still supports lower PHP versions such as PHP 5.6 (read more). There should not be any PHP errors, warnings or notices if the theme is activated on a server with PHP 5.6.  Instead of downgrading the code to work for 5.6, the theme can include a PHP version check and deactivate the theme.

Have a valid DOCTYPE declaration and include language_attributes
<!doctype html>
<html <?php language_attributes(); ?>> 
No adding shortcodes

The use of the add_shortcode() function is not allowed in themes as shown below:

add_shortcode( 'shortcode_name', 'shortcode_callback_func' );
No removing or modifying non-presentational hooks
remove_action( 'wp_head', 'wp_generator' );
remove_action( 'wp_head', 'feed_links_extra', 3); 
remove_action( 'wp_head', 'feed_links', 2); 

remove_action( 'admin_notices', 'update_nag', 3 );
remove_action( 'network_admin_notices', 'update_nag', 3 );

remove_filter( 'the_content','wpautop' );

add_filter( 'show_admin_bar', '__return_false' );

Top ↑

Core Functionality and Features Core Functionality and Features

  • Use WordPress functionality and features first, if available.
    If incorporated, features must support the WordPress functionality:  
  • Do not use features/APIs meant for WP Core use only e.g. admin pointers and private functions.
  • No pay wall restricting any WordPress feature.
  • 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)
  • The theme tags in style.css and description must match what the theme actually does in respect to functionality and design. Don’t use more than 3 subject tags (See: Theme Tag List).
  • Use template tags and action/filter hooks properly.
  • Include comments.php (via comments_template()).
  • Themes may be backwards compatible, but only for 3 major WordPress versions (version 4.9 if 5.2 is latest).
  • Themes should not remove, hide, or otherwise block the admin bar from appearing.
  • Core theme activation UX should not be modified. There should be no redirect on activation behaviour.
  • All the notifications generated by a theme should use the admin_notices API and follow the core design pattern. They must be dismissible. Everything wrapped in the admin notice needs to follow core ui design for the notices

» Explanations & examples

Top ↑

readme.txt file readme.txt file

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)
  • 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.
  • Showing preview/demo data or manipulating the preview on is not allowed and can result in your user account being terminated.
  • Adding custom blocks for Gutenberg (the new text editor in WordPress) is not allowed. Use a companion plugin instead.
  • Placeholder/default images for posts without defined featured images need to follow these rules

» Explanations & examples

Importing or Downloading Importing or Downloading

Themes are not allowed to import content to a user’s site.
Themes are not allowed to link directly to an XML, JSON, ZIP, or other file for direct download or import.
Themes are not allowed to bundle demo content via an XML, JSON, ZIP, or other file.

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.

» Explanations & examples

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.

» Explanations & examples

Top ↑

Options and Settings Options and Settings

  • Use the Customizer for implementing theme options.
  • Save options in a single array.
  • Don’t use transients for things they shouldn’t be used for, like storing theme options.
  • 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 recommend plugins from or third-party sites (link to them as free or upsell plugins, GPL licensed only).
  • Themes may use TGM Plugin Activation to recommend only plugins hosted on (by using 'required' => false for each plugin).
  • 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.

Screenshots are allowed to display only dummy text that doesn’t suggest/describe theme features, functionality, or statistics. If it looks like an AD, then it’s not allowed.

  • Dummy text examples: Lorem ipsum (or similar generators), text that doesn’t describe your theme, company, service, or products.

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
  • If the URI is a demo site, the content must be about the theme itself and not test data.
  • Using in the Theme URI is reserved for official themes.
  • Author URI is optional. If used it is required to link to a page or website about the author, author theme shop, or author 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
  • Your site needs to state explicitly that the products you’re selling are GPL compatible. It needs to be in an easy-to-find place for the reviewer and customers.
  • Themes should not display “obtrusive” upselling. Examples.
  • Themes are not allowed to have affiliate URLs or links.

» Explanations & 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 hot-linking. The exception to this is Google Fonts.

» Explanations & examples

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.