Theme Review : Required Standards

Licensing

  • Be 100% GPL and/or 100% GPL-compatible licensed.For works licensed under (or compatible with) GPL, this attribution is important, because it ensures that end users know their rights regarding modification and distribution of the copyrighted work.

  • 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,js or images.

  • All code and design should be your own or legally yours. Cloning of designs is not acceptable.

Security and Privacy

  • Validate and sanitize untrusted data before entering into the database. All untrusted data should be escaped before output.

    Why is Validation and Sanitization Important?

    • Hackers can inject various script including XSS (Cross-Site Scripting)

    • Data can break the forms at output

    • Data can be used to spread malware

  • for escaping URLs to save to the database or use in URL redirecting, use esc_url_raw. For escaping URLs that will be printed to the page use esc_url.:

    <a href="<?php echo esc_url($url);?>" title="Link Title"> Link Text </a>

  • To escape unsafe characters (such as quotes, and double-quotes in this case) use esc_attr function. e.g.

    <span class=“customize-control-title“><?php echo esc_html( $this->label ); ?></span>

  • No URL shorteners used in the theme.

Code

  • No PHP or JS errors.

  • Have a valid DOCTYPE declaration and include language_attributes.e.g. 

    <!DOCTYPE html><html <?php language_attributes(); ?>>

  • Sanitize everything. e.g.

    <?php echo esc_html( $text ); ?>

  • No shortcodes allowed.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.

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

  • Functions like ‘the_archive_title’ and ‘the_archive_description’ are now available in WordPress core. And thus, we don’t have to keep the backward compatibility for more than last two major versions. They must not be defined. Mostly they are defined in ‘template-tags.php’.

Core Functionality and Features

  • Use WordPress functionality and features first, if available. For example: don’t recreate widgets that already exist in core, feed links, custom backgrounds, pagination and navigation.

  • Don’t include admin/feature pointers.

  • No pay wall restricting any WordPress feature.

  • No disabling of the admin toolbar.

  • Use get_template_directory() rather than TEMPLATEPATH to return the template path. e.g.

    require_once( trailingslashit( get_template_directory() ) . inc/example.php' );

  • Use get_stylesheet_directory() rather than STYLESHEETPATH to return the stylesheet path.e.g.

    require_once( trailingslashit( get_stylesheet_directory() ) . 'inc/example.php' );

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

  1. accessibility-ready: must complies to the accessibility-ready guidelines.

  2. threaded-comments: must support threaded comments

Documentation

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

/*
* Fires before the opening #page tag
*/
function theme_before_page(){
   do_action( 'theme_before_page' );
}

Language / Localization / Internationalization

  • All theme text strings are to be translatable. You pass in a text domain as a second parameter, like so:

    <?php _e( 'Some Text String', 'my-theme-name' ); ?>

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

  • Use Pig Latin plugin for testing

Naming

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

  • Theme’s folder name must match the theme’s slug (textdomain). Text domain should be in lowercase and ‘hyphenated’ for two words. For e.g. for theme name ‘My Nepal’ it should be ‘my-nepal’ for both theme folder name and text domain.

Options and Settings

  • Save options in a single array.

  • All themes must use sane defaults, i.e options cannot be saved unless user clicks the save button and theme must run without saving anything in 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.

Plugins

  • 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. For e.g. social sharing icons, custom meta fields,etc falls under plugin territory.

Screenshot

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

Selling, credits and links

  • If you are a theme shop you should be selling under GPL to be in the WordPress.org 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.

  • All stylesheets must be enqueued. Cannot use:

<link type="text/css" rel="stylesheet" href="<?php echo get_stylesheet_uri(); ?> />

In the functions.php file you would use:

add_action( 'wp_enqueue_scripts', 'my_parent_theme_css' );
function my_parent_theme_css() {
   wp_enqueue_style( 'theme-style', get_stylesheet_uri() );
}

Templates

  • If using templates, custom template files should be called using get_template_part() or locate_template().

  • There are several template specific things you should consider when certain ones are being used.

  • Use *_url() template tags, rather than bloginfo() equivalents.

  • Follow the template hierarchy.

Other

  • W and P of WordPress always in uppercase.

  • Remove out unnecessary commented code. If any file or folder is not being used, it should be removed.

  • It is not necessary to provide backward compatibility more the two major versions.

  • No customization in WordPress admin.