WordPress Theme Submission Requirements

Features Requirements

Following are the core feature requirements for WordPress themes:

• Themes must not use features/APIs meant for WordPress core, including these private functions.
• Themes must display posts, pages, archive pages, home page, blog page, search, etc., and must support all of the following features:
  • Comments
  • Sidebars
  • Editor style
  • Title tag
• Themes must be widget-ready in all advertised locations.
• wp_nav_menu() must be included in at least one theme location. Menu locations may only display placeholders such as Add Menu and Set Menu if the current user is a logged in admin user and no menu has yet been set.
• All widgets included with WordPress core must display correctly in all widgetized areas and must be appropriately styled to match the theme/demo design.
• Themes must not unregister default WordPress widgets. Instead, new widgets should be registered via a plugin.
• index.php must be reserved for the standard blog “latest posts” view.
• Custom solutions are not allowed for the following features, instead, the core feature must be used/supported:
  • Logo
  • Site Icon
  • Navigation Menu
  • Custom Header
  • Custom Background
  • Feed Links
  • Post Thumbnail

Exceptions

• Core features may be extended if required, but only if done so in a way that will not prevent plugins from filtering or extending them.
• Fallbacks may be provided as long as they are only provided to users on versions of WordPress that do not contain the core feature. For example, the Site Icon feature was added in WordPress 4.3. Users on WordPress 4.3 or above must not be presented with a custom favicon solution.
• In cases where it is non-trivial to migrate users to the core feature because of existing presentational data, the custom functionality can continue to be used. For example, if CSS has been entered into a custom CSS feature, there is no need to migrate it to the core Additional CSS feature. The custom CSS feature can continue to be used as long as the core functionality is not disabled or interfered with in any way. 

Core Settings

Following are the core settings requirements for WordPress themes:

• Themes must not create a custom setting if an equivalent already exists in WordPress core. 
  For example, themes must not create a setting for Posts Per Page since it already exists in Reading settings. Other examples include Site tagline, Custom date formats, Search engine visibility, etc.
• An existing WordPress core option may be updated through a custom theme settings page if it improves the user experience.

Sidebars and Content Areas 

Following are the sidebars and content requirements for WordPress themes:

• Themes must not display content areas if no content exists for them. For example, is_active_sidebar can be used to only display sidebar content and supporting markup if a sidebar is active.
• Themes must not display public placeholder messages such as Add widgets here.
• Themes must be styled to be usable with or without active content areas.
• Content, including placeholder/demo content, must not be hardcoded into the template files.

Menu Position

Following are the menu requirements for WordPress themes:

• If the theme has an Options page and no other custom Admin pages, then it must go in either the Customizer (strongly recommended) or the Appearance section.
• If the theme creates other sub menu items not directly related to Appearance such as installing plugins, importing demo data, etc, then a single top level menu entry that groups all themes settings is allowed. 

Customizer

Following are the customizer usage requirements:

• Customizer Adoption: Integrating the Customizer into a theme will make it more appealing to developers and website creators by providing a core theme options framework and live site previewing. Users are increasingly expecting to find theme options within the Customizer. For more information, refer to Theme Options – The Customize API.
• Customizer Sanitization: All Customizer settings must be properly validated and sanitized with an appropriate sanitization callback. This may either be done by defining a callback function or hooking into an action prior to saving all settings to the database. For more information, refer to the Validation and Sanitization in the Customizer article.
• Core Sanitization Methods: Core sanitization functions must be used rather than custom sanitization callbacks that sanitize with the same methodology. For example, if a URL field is expected to contain a valid URL, the sanitization function must be esc_url instead of a custom callback.
• Custom Sanitization Callbacks: Custom sanitization callbacks are allowed if no core sanitization function exists, but they must utilize proper sanitization methods. For example, this callback is simply returning the unsanitized value “as-is”, which is unacceptable.
• Extending the Customizer: Themes can add custom controls and apply styles/scripts to the Customizer, but they must not adversely affect the Customizer output in any way. All core features must be preserved and plugins must be able to add sections and panels as needed, without conflict.  

Child Themes

If a child theme is provided with the theme, it must:

• Load the parent stylesheet using wp_enqueue_style() instead of @import.
• Consist of style.css, functions.php and screenshot.png files at a minimum.
• Append “Child” to the theme name so it can be identified as a child theme.
• Include files within the child theme directory using get_stylesheet_directory().
• Reference the parent theme via Template: parameter in the style.css header

The child theme will be held to the same standards and best practices as the parent theme. For more information on Child Theme development, refer to WordPress Codex article. 

WooCommerce Templates

Developers must never remove WooCommerce template hooks from modified core templates. Removing hooks will likely lead to issues with extensions, as well as core WooCommerce functionality.

Strongly Recommended! 

Using WooCommerce Action and Filters: It is recommended that developers utilize available actions and filters within WooCommerce rather than modifying core templates. This makes it far easier to maintain a theme and ensure core template updates are properly reflected.

Coding Requirements

Themes must not include unused code fragments (ie., commented out code), todo lists in comments, or any other comments that do not contribute to understanding the code.

Themes must not obfuscate or hide code in any way, including through the use of base64 encoding.

Prefixing

Required Prefixes

A unique prefix must be used for all function names, classes, hooks, public/global variables, action/filter hooks, custom image sizes, constants, database entries, theme-specific scripts and theme-specific styles to avoid conflicts with plugins and other themes.

Prefixes should consist of either themename_, authorname_ or frameworkname_. While multiple prefixes are allowed (theme-specific, framework and external PHP libraries), they must be consistent, at least three characters, and unique (ie not using a common term such as ‘seo’). For more information, refer to Prefix all the things article.  

Third-Party Scripts

Third-party scripts/styles must not be prefixed or suffixed to avoid double loading. For more reference, follow this github link.

Reserved Prefixes

The wp_ prefix is reserved for WordPress core functionality and must not be used by a theme. Prefixes must never begin with an underscore or hyphen.

Loading Files

File Paths

Hard-coded URIs must not be used when including or referencing files. The helper functions provided by WordPress should be used where possible.Strongly Recommended! 

It is recommended that the following WordPress 4.7+ functions be used, as they greatly improve the child theming capabilities of the theme:

• get_theme_file_uri()
• get_parent_theme_file_uri()
• get_theme_file_path()
• get_parent_theme_file_path()

Note: A fallback may be required for users on versions of WordPress prior to 4.7.

These functions should be used in preference to basename, dirname, pathinfo, etc. 

For example, you should use:

include get_theme_file_path( '/includes/myscript.php' );

In preference to:

include dirname( __FILE__ ) . '/myscript.php';

For more information, refer to the following:

• File Path Example
• Backwards Compatibility/Fallback Example
• Further reading

WordPress Assets

Following are the requirements for WordPress assets:

• The wp_enqueue_style() function must be used to enqueue all stylesheets. For more information, refer to wp_enqueue_style().
  
• The wp_enqueue_script() function must be used to enqueue JavaScript code. For more information, refer to wp_enqueue_script().  
• Themes must use the scripts shipped with WordPress instead of including their own copy of the script or using one from a CDN. This includes jQuery, jQuery UI, Backbone, Underscore, etc. For more information, refer to the list of scripts included with WordPress.
• If a CDN version of a library is included (only allowed if not shipped with WordPress), a local copy must be provided as a fallback.
• All assets must be loaded using an SSL-friendly approach. Assets loaded from the theme directory must use get_template_directory_uri() or get_stylesheet_directory_uri() to build the URL. These functions will automatically use the appropriate protocol. For external assets, the theme must either use check is_ssl() and set the appropriate protocol prefix or use protocol-relative formats such as //example.com/file.js instead of http://example.com/file.js.

Strongly Recommended! 

Themes should make sure that any scripts/stylesheets they use are only loaded on the pages that they are actually needed on. 

Combining Scripts

Third-party scripts and libraries must not be combined. They must be enqueued individually to ensure that:

• They are not loaded a second time by a plugin.
• Users can deregister scripts if required.

Font Loading

The @import rule must not be used when loading fonts, as this blocks parallel downloads and slows down the loading of the page. Instead, the fonts must be enqueued using wp_enqueue_style(). 

If using the Google Fonts library:

• The theme must only include variants that will actually be used, as seen in this example where only weight 700 of Inconsolata is loaded:
  fonts.googleapis.com/css?family=Inconsolata:700
• The theme must load multiple typefaces (if required) via a single HTTP request, using the pipe |operator, as seen in this example:
  fonts.googleapis.com/css?family=Lora:400,700|Inconsolata:700
• Here is an example of how to load fonts correctly.

Strongly Recommended! 

The theme should not simply include a drop-down list of all Google Fonts in the options, as this can be confusing for users. Consider choosing a subset of font combinations that suit the design instead. 

WordPress Code

Following are the WordPress coding requirements:

• Deprecated template tags or functions are not allowed.
• The following functions must be present:
  
  • wp_head() – just before </head>
  • wp_footer() – just before </body>
  • body_class() – inside <body> or <html> tags
  • post_class()
• The theme must let WordPress add and manage the title. This is done by adding add_theme_support( ‘title-tag’ ); to functions.php instead of using wp_title() in the document head.
• If the theme includes custom template files, they must be called using get_template_part() orlocate_template().
• WordPress theme files and directories must be named using lowercase letters. Words must be separated by hyphens, not camelCase or underscores. The theme filenames recognized by WordPress must be used where applicable.
• Themes must not add any entries to the admin bar and must not remove, hide, or otherwise block the admin bar from appearing.
• The $content_width variable must be used to define the maximum allowed width for images, videos, and oEmbeds displayed within a theme. This is set in functions.php, for an example, refer to this sample.
• Themes must not remove any filters added by WordPress core, for example, wpautop, wptexturize, etc.
• Default WordPress CSS classes must be covered in the stylesheet.
• WP_Filesystem methods must be used where available instead of direct PHP filesystem calls. For example, mkdir, fopen, fread, fwrite, fputs, etc., must not be used.

PHP Code

Note: It is strongly recommended that your themes follow the WordPress PHP Coding Standards.

Following are the PHP coding requirements:

• Themes must not have any PHP notices, warnings, or errors.
  Strongly Recommended! 
  
  It is recommended that development is done with errors enabled and WP_DEBUG set to true.
• The create_function() function has been deprecated as of PHP 7.2.0 and must no longer be used.
• The “@” operator must not be used to suppress error messages or notices.
• The use of PHP short tags is not allowed.
• Tabs must be used for indentation, refer to the WordPress PHP Coding Standards.
• Themes must not include code to support PHP4. For example, themes must not use &$this when calling add_action. For more information, refer to this article. 
• PHP references (ie using &) must be avoided unless absolutely necessary. For more information, refer to Do not use PHP references.
• The creation of global variables is discouraged. They should be used only if absolutely necessary. If used, they must follow the prefixing rules.
• Single-statement inline control structures are prohibited. Either curly braces should be used (even where they are optional) or where appropriate the alternative syntax for control structures may be used. 
  
  For example,
  Do not use:if ( empty( $somevar ) ) return false;Instead use:if ( empty( $somevar ) ) {  return false; }Or in the context of a template file or other predominantly HTML file, use:if ( empty( $somevar ) ) : return false;
  endif;
• The eval() function must not be used.

PHP Version

Themes must work with the latest release of PHP. There is no required minimum supported version of PHP, but:

• The decision on which versions to support should be made with the stats in mind.
• The requirements should be made clear to customers, so as to avoid dissatisfaction.

HTML/CSS Code

Note:  It is strongly recommended that your theme follows both the WordPress HTML Coding Standards and the WordPress CSS Coding Standards.

Following are the HTML/CSS coding requirements:

• CSS styling must not be hardcoded anywhere within a theme, either inline or in a <style> tag.
• Dynamic styling must be added via wp_add_inline_style() with the exception of adding a background image to an element. In this instance, the following would be permitted:
  <div id=”header-background” style=”background-image: url( <?php echo esc_url(
  ‘$header-background’ ); ?> );”></div>Any other styling for that element such as background-size: cover; must be added with wp_add_inline_style().
• Dynamic styling must be attached to the appropriate stylesheets in order to prevent loading CSS where it is not needed. For example, dynamic styling for WooCommerce must be attached to a woocommerce-inline-styles stylesheet rather than the main theme stylesheet.
• IDs and classes must be appropriately named and follow a naming convention.
• Selectors must be human readable and describe what elements are being styled.
• Overqualified selectors should not be used. For example, .container should be used instead of div.container. 
• When using CSS (or JavaScript) to manipulate elements, you must make sure that only your elements are affected. For example, when applying CSS to jQuery UI elements you’ve added to a page, you must make sure any jQuery UI elements that may be added by another item are not affected.

Strongly Recommended! 

It is recommended that all your code be run through the W3C validator. Items will be soft-rejected for important errors such as unclosed tags, nesting errors, duplicate IDs, etc.

JavaScript Code

Note:  It is strongly recommended that your theme follow the WordPress JavaScript Coding Standards.

Following are the JavaScript coding requirements:

• JavaScript code must be placed in external files whenever possible.
• External JavaScript files must be enqueued correctly.
• If PHP variables or data need to be passed to JavaScript, wp_localize_script() must be used.
• JavaScript files must be loaded via the footer using the $in_footer parameter of wp_enqueue_script(), except where it must be in the head element for it to work.
• There must be no JavaScript notices or errors created.
• The use of eval() is not allowed.
• If using jQuery, then .on() must be used instead of .click(), .bind(), .hover(), etc.
• Strict mode must be used for all JavaScript. For example, for jQuery:

      (function($) {
          "use strict";
          // your code here
       })(jQuery);

• Redundant events must not be used. For example, there is no need for multiple $(document).ready() or $(window).load() events.
• Development and debugging code such as console.log() must be removed.

Translation Ready

Following are the WordPress Internationalization requirements: 

• Translatable Text: All theme text strings must be internationalized and properly escaped so that the theme can be translated and localized without parent theme modifications. For more information, refer to this Internationalization article.
• Translation Variables: Text strings must not contain variables or constants, as dynamic content is not translatable. Instead, use the printf family of functions with a placeholder or PHP argument swapping (for multiple variables). For more information, refer to Variables section in this Internationalization article.
• Text Domains: Constants, variables or definitions must not be used to define the theme’s text domain. The text domain must use dashes rather than underscores and be lowercase plain-text.Strongly Recommended! 
  
  It is recommended that the text domain match the theme’s slug to help ensure uniqueness. For more information, refer to Internationalization article.
• Irrelevant Text Domains: Text domains that are unrelated to the theme are not allowed and must be removed. Packaged PHP libraries (i.e. TGMPA), frameworks and plugin template text domains are relevant and therefore allowed. 
• Translation File: The localization file should be in English and delivered as a .pot file. The .pot will contain all translation strings. The .pot file name should match the theme-slug (i.e. themeslug.pot).
  • Themes can include actual translation files (.po/.mo) for any variety of specific languages, but must not add the en_US.mo or en_US.po because English is already implied.
  • Ensure the .POT translation file is up-to-date. Having an outdated .POT file limits the translatable functionality of the theme, which will negatively affect international customers.Strongly Recommended! 
    
    Right To Left (RTL) Support: It is recommended that you add support to your theme for languages that are read from right to left (RTL). This is relatively easy to do and makes your theme appealing to wide range of customers. For more information, refer to RTL support in themes article.

Theme Validation

Please use the following tools to identify and fix any issues before submitting your theme.

Envato Theme Check Plugin

Themes are required to fix all issues that result in a REQUIRED notice in the Envato Theme Check plugin. There are no longer any allowable exceptions.
Strongly Recommended! 
It is recommended that WARNING, RECOMMENDED and INFO notices are resolved if possible. Some may be the result of an issue that is cause for rejection (Reviewers make this decision).

The Envato Theme Check plugin is a fork of the original Theme Check plugin, which has been modified to more closely match these requirements.  

WordPress Unit Test Data

Themes will be tested against the WordPress Unit Test data to ensure that all necessary components are styled properly.

• Posts must be displayed correctly with no apparent visual problems.
• All expected components, such as title, body, comments, comment form, post meta, etc., must be rendered correctly.
• Posts must be displayed in the correct order.
• Page navigation must work correctly.
• The search results page must work properly, with results displayed appropriately. If there are no results the user must be informed of this.
• Sticky posts must be styled and displayed appropriately.
• The Read More link must work properly (linking to the <!–more–> tag location).
• If the theme supports post formats, each type must be displayed appropriately in index/archive views.
• Lack of content, such as body text, must not adversely impact the layout.
• Themes must include both the Tag and the Category taxonomies in some manner.
• Floats must be cleared properly for the floated element, that is, thumbnail images.
• Content overflow issues must be addressed. For example, a title with a long non-breaking string must not break the layout.