wptt / wpthemereview Goto Github PK

Rule:

Have either UNIX or DOS line endings, not both. This rule gets applied to PHP, CSS, JS and TXT files.

Ref: https://make.wordpress.org/themes/handbook/review/required/theme-check-plugin/#line-endings

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/lineendings.php

Decision needed by Theme Review Board:

Currently the Theme Check plugin checks whether both \r as well as \n line endings or combinations thereof are found and throws a warning if that's the case as this can cause a problem with SVN repositories.
The warning leaves it open to the Theme Author to choose whether to use UNIX or DOS line endings as long as they do so consistently.

The existing PHPCS sniff for this - Generic.Files.LineEndings - generates an error.
Additionally the sniff is aimed at one preferred line ending not an either/or type of situation.

The WPCS standard is to throw an error and to require UNIX style \n line endings.

Advice: Follow the WPCS standard and adjust the rule to consistently require UNIX style \n line endings.

To do:

• If agreed that this should be an error and that UNIX line endings should be required - add existing Generic.Files.LineEndings sniff to the ruleset with the appropriate properties set.
• Add the rule in the Theme Review handbook to the Requirements page.

[Implement sniff] Check for functions that are plugin territory and display an error if found.

Rule type:

Error

Rule:

The theme options should not be pseudo custom post types and save non-trivial user data. Non-design related functionality is not allowed.

Ref: https://make.wordpress.org/themes/handbook/review/required/#presentation-vs-functionality

ERROR | The following three functions are not allowed (plugin territory): register_post_type(), register_taxonomy(), add_shortcode(). Review this list with the Theme Review board as there might be some more functions which could be added. The sniff could probably just extend the Forbidden Functions sniff - though it should be kept as a separate sniff for clarity.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/plugin-territory.php

To do:

• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

[New sniff] Check for Author URI and Theme URI

Rule type:

Warning

Rule:

WARNING | Check specifically against style.css whether the two recommended headers are found.

Rule as it is found in the handbook.
There is no specific rule in the handbook for this.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/style_suggested.php

[Optional Section] Decision needed:

Stylesheets and Scripts (Recommended)
The main style.css header can optionally include Author URI and Theme URI.

Advice/Request for decision: Should the above header recommendation be added to the recommended list?

Notes for implementation:

• This sniff will rely on the WordPress_AbstractThemeSniff Class to get the $sniff_helper array.
• Testing will require that a style.css file is in the same folder as the test file.

To do:

• Decision/Add the rule in the Theme Review handbook to the Recommended page.
• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

Rule type:

Error

Rule:

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

Ref: https://make.wordpress.org/themes/handbook/review/required/#code

Theme check file covering this rule:

N/A

To do:

• Add existing WordPress.XSS.EscapeOutput sniff to the ruleset.
• Add existing WordPress.VIP.ValidatedSanitizedInput sniff to the ruleset.

Rule type:

Error

Rule:

From what I can see, there are actually 5 distinct i18n related rules which may need sniffs - this issue covers the third item on the list.

1. All theme text strings are to be translatable. (#33)
2. Include a text domain in style.css (#34)
3. 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.
4. Can use any language for text, but only use the same one for all text. (#33)
5. Correct usage of the WP i18n functions. (#31)

Refs:
https://make.wordpress.org/themes/handbook/review/required/#language
https://make.wordpress.org/themes/handbook/review/required/theme-check-plugin/#additional-checks

This requires a slightly different implementation, the existing WordPress.WP.I18n sniff can check whether all i18n functions use the same text domain. For that check, the text domain - at this moment - will have to be provided via the phpcs config file or programmatically. I suggest this text domain injection into the PHPCS configuration will be implemented in the Theme Check wrapper which will call PHPCS in order to enable this check.

Note: it is being investigate upstream whether the text-domain can be determined from the files. If that would be implemented, no further action would be needed for the Theme Check plugin.

Currently the WordPress.WP.I18n sniff only checks against the one text domain and does not keep track of the found text domains (other than reporting them in the error message)

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/textdomain.php

Decision Needed:

Request for decision: How should we deal with extra (allowed) text-domains ? Is there a white-list of extra text-domains related to frameworks which can be checked against ?

To do:

• Potentially implement passing the text domain to PHPCS in Theme Check.
• Potentially extend the existing WordPress.WP.I18n sniff to keep a count of all encountered text-domains and report if the count is more than two.

Rule:

No short open tags allowed.

Ref: https://make.wordpress.org/themes/handbook/review/required/theme-check-plugin/#additional-checks

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/phpshort.php

Decision needed by Theme Review Board:

In the Theme Check plugin, this rule currently generates a warning and the rule is not mentioned on the Theme Review Requirements page.

The existing PHPCS sniff implementation for this - Generic.PHP.DisallowShortOpenTag - generates an error. If this should be a warning, either a PR needs to be submitted upstream to PHPCS to allow for changing the error level or alternatively the existing sniff would need to be extended/copied to a WP specific sniff which would do the same, but generate a warning instead of an error.

Advice: As short open tags have been removed in PHP 7, I would suggest making this rule a requirement and raising the error level to error instead of warning.

To do:

• If agreed this should be an error - add existing Generic.PHP.DisallowShortOpenTag sniff to the ruleset.
• Add the rule in the Theme Review handbook to the Requirements page.

As described in #11, themes should use add_theme_page() and are not allowed to use the other add_.._page() functions.

In that same category of functions there are two functions which remove menu pages: remove_menu_page() and remove_submenu_page().

Is it ok to use these in a theme or should these be forbidden as well ?

Ref: https://codex.wordpress.org/Administration_Menus

Rule:

WARNING : Themes that use the tag accessibility-ready will need to undergo an accessibility review.

Ref: https://make.wordpress.org/themes/handbook/review/accessibility/

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/style_tags.php

To do:

• Create unit tests
• Create new sniff

Rule:

WARNING : Using iframes is discouraged. All resources should be included in the theme. iframes are sometimes used to load unwanted adverts and code on your site.

Ref: https://make.wordpress.org/themes/handbook/review/required/#stylesheets-and-scripts

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/iframes.php

To do:

• Create unit tests
• Create new sniff

[New sniff] Check for unapproved and deprecated tags in style.css.

Rule type:

Error - unapproved
Warning - deprecated

Rule:

ERROR Theme tags in style.css must be approved theme tags.
WARNING Deprecated theme tags found in style.css.

Rule as it is found in the handbook.
Core Functionality and Features
The theme tags in style.css and description must match the what the theme actually does in respect to functionality and design.
This rule is a reasonable fit for the sniff. There are no other rules I can find.
Ref: https://make.wordpress.org/themes/handbook/review/required/#core-functionality-and-features

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/style_tags.php

Notes for implementation:

• This sniff will rely on the WordPress_AbstractThemeSniff Class to get the $sniff_helper array.
• Testing will require that a style.css file is in the same folder as the test file.

To do:

• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

I have xampp installed on my system. It already comes with PHPCS and whenever I try to put WPCS into the config, it gives me error that no config file exists. Please guide me what to do :(

One thing I often run across is the following in custom widgets.

$title = apply_filters( 'widget_title', $title );

There's 2 missing parameters there. Ref: https://developer.wordpress.org/reference/hooks/widget_title/

When themes call this, it should be like so:

$title = apply_filters( 'widget_title', $title, $instance, $id_base );

They need to make sure that all 3 parameters are correct and passed to filters. Otherwise, it breaks plugins that rely on those 2nd and 3rd parameters.

[New sniff] Check Customizer sanitize-callback is not empty

Rule type:

ERROR

Rule:

ERROR | Ensure that all calls the ->add_setting() for the Customizer include a
sanitize_callback or a sanitize_js_callback parameter and that it's non-empty.
An exception will need to be made for the (two) calls found in Kirki_Settings
as they do correctly comply, but are wrappers for the real call.

Rule as it is found in the handbook.
Code - Validate and/or sanitize untrusted data before entering into the database.
https://make.wordpress.org/themes/handbook/review/required/#code

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/customizer.php

To do:

• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

Decision needed by Theme Review Board:

There is currently no rule to check for a Unicode Byte Order Mark.

As having a BOM in one of the theme files will often give issues when using those files, it might be a good idea to add this as a rule.

Advice: Add rule which disallows having a BOM in theme files.

To do:

• If agreed this should be a rule - add existing Generic.Files.ByteOrderMark sniff to the ruleset.
• Add the rule in the Theme Review handbook to the Requirements page.

[New class] Create Theme Sniff Class

Create new theme sniff class that will create a theme data array that will be accessible by other sniffs during a theme check. The theme data will consist of data pulled from the style.css file.

Example array content.

$theme_data = array(
'theme_name' => 'Name of Theme',
'theme_uri' => 'www.theme.uri',
'theme_author' => '
'theme_author' => 'Author Name',
'theme_author_uri' => 'www.author.uri',
'theme_description' => 'Description of theme from style.css',
'theme_version' => '0.0.1',
'theme license' => 'GPLv2 or later',
'theme_license_uri' => 'http://www.gnu.org/licenses/gpl-2.0.html',
'theme_tags' => array( theme tags from style.css),
'text_domain' => 'text domain from style.css',

Elements not in style.css will be blank, for example 'theme_uri' => '',

Sniffs that need the $theme_data array, should set up the class with extends WordPress ThemeSniff.

The array is then accessed with $this->theme_data.

Issues:

Conventional testing of sniffs that use this class is not possible because style.css will be required in addition to a test file.

To do:

• develop and add Class
• test Class with a sniff that uses theme data

[New sniff] Check for deprecated WordPress Function and issue Error or Warning

Rule type:

Error / Warning

Rule:

Use WordPress functionality and features first, if available.

Ref: https://make.wordpress.org/themes/handbook/review/required/#core-functionality-and-features

ERROR | Check for usage of deprecated WP functions (required), for most recent versions 5 and earlier.
WARNING | Check for usage of deprecated WP functions (recommended - only for deprecated functions from the most recent 4 versions.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/deprecated.php
https://github.com/Otto42/theme-check/blob/master/checks/dep-recommended.php

Decision needed:

This sniff covers both required and recommended deprecated WP Function changes. It just made sense to combine the two into one sniff. It simplifies the maintenance as you simply needs to add the current version and deprecated functions every major WordPress release.

To do:

• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

We would like to allow the use of certain functions to be used in certain places without allowing the function everywhere.

The concrete example is the use of base64_encode and base64_decode in Freemius_Api_Base

https://github.com/Freemius/wordpress-sdk/blob/master/includes/sdk/FreemiusBase.php#L156-L186

[New sniff] No wordpress.org allowed in Theme URI

Rule type:

Error

Rule:

ERROR | Verify - in style.css that the Theme URI does not point to wordpress.org (with predefined list of themes which are exempt and live under the wordpressdotorg user or have a check based on Author name.

Rule as it is found in the handbook.
There is no specific rule on this.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/uri.php

Decision needed:

If we are striving to have rules for sniffs the following rule should be considered.
Selling, credits, and links

• Using a WordPress.org Theme URI is reserved for official themes.

Notes for implementation:

• This sniff will rely on the WordPress_AbstractThemeSniff Class to get the $sniff_helper array.
• Testing will require that a style.css file is in the same folder as the test file.

To do:

• Decision and implementation to add the rule in the Theme Review handbook to the Requirements page.
• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

[New sniff] Check that theme supports used have a tag in style.css file.

Rule type:

Error

Rule:

ERROR | Verify that an add_theme_support() call is made for any feature the
theme has been tagged with from the following list: custom-background,
custom-header, custom-menu, featured-images/post-thumbnails, post-formats,
custom-logo

Rule as it is found in the handbook.
Core Functionality and Features
The theme tags in style.css and description must match the what the theme actually does in respect to functionality and design.
Ref: https://make.wordpress.org/themes/handbook/review/required/#core-functionality-and-features

The following are detected :
add_theme_support('custom-header') -> must have custom-header in style.css tags list
add_theme_support('custom-background') -> must have custom-background in style.css tags list
add_theme_support('custom-logo') -> must have custom-logo in style.css tags list
add_theme_support('post-formats') -> must have post-formats in style.css tags list
add_theme_support('post-thumbnails') -> must have featured-images or featured-image-header in style.css tags list
wp_nav_menu() -> must have custom-menu in style.css tags list
register_nav_menu() -> must have custom-menu in style.css tags list

Theme check file covering this rule:

There really is not a theme check that covers this.

Notes for implementation:

• This sniff will rely on the AbstractThemeSniffClass to get the style.css theme data needed. More specifically the tag list.
• Testing will require that a style.css file is in the same folder as the test file.

To do:

• Create unit tests
• Create new sniff

Rule type:
Error

Rule:

No hard coding of scripts and styles unless a browser workaround script. Everything should be enqueued.

Ref: https://make.wordpress.org/themes/handbook/review/required/#stylesheets-and-scripts

Existing Sniff:

https://github.com/WPTRT/WordPress-Coding-Standards/blob/feature/theme-review-sniffs/WordPress/Sniffs/WP/EnqueuedResourcesSniff.php

Theme check file covering this rule:

None.

Decision needed:

The sniff looks for scripts and stylesheets included in the templates (via <script src=[...]> and <link rel=[...]>).

The rule makes an exception for browser workaround scripts.

Request for decision:

Given that since WordPress 4.2, wp_script_add_data() exists, and browser workaround scripts now can be enqueued (see TwentySixteen), should the rule be changed to encompass all scripts and stylesheets?

To do:

• Adjust the rule in the Theme Review handbook.
• Add existing sniff to the ruleset.

Rule type: Error

Rule:

Avoid hard coding to modify content. Instead, use function parameters, filters and action hooks where appropriate.

Ref: Link to the Theme Review handbook page & subsection where the rule can be found, i.e. https://make.wordpress.org/themes/handbook/review/required/#core-functionality-and-features

Here are a few example of things that should not be done.

require_once(ABSPATH . 'wp-admin/includes/media.php');
require_once '../../../../../../wp-load.php';
require_once(ABSPATH . 'wp-admin/admin.php');
include_once( ABSPATH . 'wp-admin/includes/plugin.php' );

get_admin_url() and admin_url() should be used instead.

Decision needed:

The borderline one is restricting loading plugin.php to check if an plugin is active. The alternative would be to check if a function, class or constant existed.

To do:

• Create unit tests
• Create new sniff

Rule type:

Error

Rule:

From what I can see, there are actually 5 distinct i18n related rules which may need sniffs - this issue covers the first and fourth item on the list.

1. All theme text strings are to be translatable.
2. Include a text domain in style.css (#34)
3. 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. (#35)
4. Can use any language for text, but only use the same one for all text.
5. Correct usage of the WP i18n functions. (#31)

Refs:
https://make.wordpress.org/themes/handbook/review/required/#language
https://make.wordpress.org/themes/handbook/review/required/theme-check-plugin/#additional-checks

Checking whether all text strings are translatable is very tricky as the echo call and the string building aren't always done in the same place. Strings within PHP are often enough also used for other purposes - think array indexes -, so it is doubtful this can be implemented in the form of a sniff.

The Pig Latin plugin comes to mind as a useful tool to check this, but this is a tool that checks at runtime in contrast to PHPCS which does a static code analysis.

Similarly, checking whether all text strings are in the same languages would be a very interesting challenge to.

I believe these will remain manual check.

All the same: ideas welcome ;-)

Theme check file covering this rule:

n/a

Decision needed:

Request for decision: Is it acceptable that this will stay a manual check ?

To do:

• ... ?

Rule type:

ERROR

Rule:

ERROR | Verify that tags in style.css that are related to theme support are being supported by the theme.

Rule as it is found in the handbook.
Core Functionality and Features
The theme tags in style.css and description must match the what the theme actually does in respect to functionality and design.
Ref: https://make.wordpress.org/themes/handbook/review/required/#core-functionality-and-features

custom-header -> if present must have add_theme_support('custom-header')
custom-background -> if present must have add_theme_support('custom-background')
custom-logo -> if present must have add_theme_support('custom-logo')
post-formats -> if present must have add_theme_support('post-formats')
featured-images -> if present must have add_theme_support('post-thumbnails')
featured-image-header -> if present must have add_theme_support('post-thumbnails')
custom-menu -> if present must use register_nav_menu() or wp_nav_menu()

Theme check file covering this rule:

There really is no theme check covering this rule.

Note that this is a different sniff then Issue #28.

Notes for implementation:

• This sniff will rely on the $theme_data array from the AbstractThemeSniffClass. More specifically the tag list.
• This sniff will rely on the $sniff_helper array from the AbstractThemeSniffClass. More specifically the theme supports list.
• Testing will require that a style.css file is in the same folder as the test file.

To do:

• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

Rule:

Admin Pages only allowed via add_theme_page().

Ref: https://make.wordpress.org/themes/handbook/review/required/theme-check-plugin/#admin-menu

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/admin_menu.php

To do:

• Create unit tests
• Create new sniff

[New sniff] Check for deprecated function arguments and issue Error if found.

Rule type:

Error

Rule:

Use WordPress functionality and features first, if available.
Use *_url() template tags, rather than bloginfo() equivalents.

Ref: https://make.wordpress.org/themes/handbook/review/required/#core-functionality-and-features

ERROR | Check for usage of deprecated WP functions and provide alternative based on the parameter passed. For details, see Theme-Check plugin - /checks/more_deprecated.php We could probably extend an existing sniff of similar ilk for this or even combine this with the other deprecated checks.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/more_deprecated.php

To do:

• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

[New Class] Create WordPress_AbstractThemeSniff Class

Create new theme sniff class that will create a $sniff_helper array that will be accessible by other sniffs during a theme check.
Replaces issue #43 New Theme Sniff Class

The purpose of the class is :

• To pull theme data from style.css to be accessed by other sniffs created for WordPress theme review.
• Do a once through of theme files to provide a array of switches used to satisfy checks that require a complete review of files before a positive or negative decision can be made.
• Conduct sniffs/checks that can't be done during a standard Code Sniffer run. Typically these are checks not associated with any file.
• Display results in a similar format to Code Sniffer report.

The class essentially allows integration of checks that can't be properly done with a file-token-sniff approach.

Array Content

$sniff_helper = array(
    'theme_data' => array(
        'name'        => '',
        'uri'         => '',
        'author'      => '',
        'author_uri'  => '',
        'description' => '',
        'version'     => '',
        'license'     => '',
        'license_uri' => '',
        'tags'        => '',
        'text_domain' => '',
    ),
    'theme_supports' => array(
        'custom-header' => false,
        'custom-background' => false,
        'custom-logo' => false,
        'post-formats' => false,
        'featured-images' => false,
        'featured-image-header' => false,
        'custom-menu' => false,
    ),
    'comment_reply' => array(
        'enqueued' => false,
        'comment_reply_term' => false,
    ),
    'comments_pagination' => false,
    'content_width' => false,
    'add_editor_style' => false,
    'avatar_check' => false,
    'custom_menu_support' => false,
    'post_pagination' => false,
    'post_format_support' => false,
    'post_thumbnail_support' => false,
    'post_tags_support' => false,
    'title_tag' => array(
        'theme_support' => false,
        'wp_title' => false,
    ),
    'sidebar_support' => array(
        'register_sidebar_used' => false,
        'dynamic_sidebar_used' => false,
        'widgets_init_used' => false,
    ),
    'basic_function_calls' => array(
        'wp_footer' => false,
        'wp_head' => false,
        'language_attributes' => false,
        'charset' => false,
        'automatic_feed_links' => false,
        'comments_template' => false,
        'wp_list_comments' => false,
        'comment_form' => false,
        'body_class' => false,
        'wp_link_pages' => false,
        'post_class' => false,
    ),
    'doctype' => false,
    'index_file_used' => false,
    'style_file_used' => false,
    'readme_file_used' => false,
    'screenshot' => array(
        'found' => false,
        'less_than_1200_wide' => false,
        'less_than_900_high' => false,
        'aspect_ratio_4_by_3' => false,
        'details_not_found' => false,
    ),
    'css_required' => array(
        'sticky' => false,
        'bypostauthor' => false,
        'alignleft' => false,
        'alignright' => false,
        'aligncenter' => false,
        'wp-caption' => false,
        'wp-caption-text' => false,
        'gallery-caption' => false,
        'screen-reader-text' => false,
    ),
);

Checks done in the Class

The following theme checks that require a once through are included in the class.
From WordPress/WordPress-Coding-Standards#578

Rules which can probably be turned into a sniff but would need to be run against every file before a positive/negative result can be determined:

ERROR | Verify that an add_theme_support() call is made for any feature the theme has been tagged with from the following list: custom-background, custom-header, custom-menu, featured-images/post-thumbnails, post-formats, custom-logo
ERROR | Check that the comment reply script is being enqueued (comments should always be supported by themes).
ERROR | Check that the comment_reply string or rather any HTML identifiers needed for the JS script to work are present (need more info) (comments should always be supported by themes, enqueuing the script alone is not enough)
ERROR | Check that comment pagination is supported. At least one of the following functions would need to be found in at least one of the template files, fail if none are found at all. paginate_comments_links(), the_comments_navigation(), the_comments_pagination(), next_comments_link() or previous_comments_link()
ERROR | Check that - normally in functions.php, but could be in another file - the global variable $content_width is set, so either in the global namespace using $content_width or within a function using global $content_width; $content_width =... or $GLOBALS['content_width']. Note: currently the Theme Check plugin also checks for filters on embed_defaults and content_width and passes if those are found. Those checks are outdated and should not be ported.
ERROR | Verify that an add_editor_style() call is made if the theme has been tagged with editor-style.
ERROR | Verify that get_avatar() or wp_list_comments() is used at least once.
WARNING | Verify that there are max one link each to the author's website and one link to wordpress.org in front-end visitor facing template, e.g. footer.php or similar.
WARNING | Verify that (register|wp)_nav_menu() is used at least once. This should become an error if the theme is tagged with custom-menu.
ERROR | Verify that (get_post_format()|has_format() or CSS rules covering .format are found, at least once if the theme has a add_theme_support( 'post-format' ) call. This should become an error if the theme is tagged with post-formats.
ERROR | Check that post pagination is supported. At least one of the following functions would need to be found in at least one of the template files, fail if none are found at all. posts_nav_link(), paginate_links(), the_posts_navigation(), the_posts_pagination(), next_posts_link() or previous_posts_link()
ERROR | Verify that the_post_thumbnail()is found at least once if the theme has a add_theme_support( 'post-thumbnails' ) call. This should become an error if the theme is tagged with featured-image.
ERROR | Check if a number of specific CSS identifiers have been given styles in any of the CSS files. See Theme-Check plugin - /checks/style_needed.php for the list.
ERROR | Check that post tags are supported in the theme. At least one of the following functions would need to be found in at least one of the template files, fail if none are found at all. the_tags(), get_the_tag_list(), get_the_term_list()
ERROR | Check that add_theme_support( 'title-tag' ) is used in at least one file.
WARNING | Check if at least one call to register_sidebar() or dynamic_sidebar() is made.
ERROR | If a call to register_sidebar() is found, make sure there is at least one call to dynamic_sidebar() as well and visa versa.
ERROR | Check that the register_sidebar() function is called with an add_action( 'widget_init', ... ) call.
ERROR | Check for a number of function calls which each theme has to contain. See Theme-Check plugin - /checks/basic.php for the list.
ERROR | Check that the theme contains a DOCTYPE headers somewhere.

Rules which would need another solution (like in the bootstrap file which would run PHPCS from the Theme-check plugin within an install):

WARNING | Have a default (always on) INFO item which will warn people not to use their own functions for features which should be supported through add_theme_support().
ERROR | Check that at the very least the following two files exist: index.php and style.css.
WARNING | Check that a readme.txt file exists.
ERROR | Check that at least one screenshot is found.
ERROR | Check that the screenshot is either a jpg or png.
ERROR | Check that the screenshot is smaller than 1200x900, has a 4:3 size ratio.
WARNING | Recommend a screenshot size of 1200 x 900 if the screenshot is smaller.

As we continue to push towards more automated theme checks, this class offers a way to add checks that do not conform to the file->token->sniff approach.

Sniffs that need the $sniff_helper array, should set up the class with extends WordPress_Abstract_ThemeSniff.

The array is a global array so to access in your sniff, simply add 'global $sniff_helper' to your process function.

Issues:
Conventional testing of sniffs that use this class is not possible because style.css will be required in addition to a test file.
This class does not run if a single file is being checked. It is designed for a theme check of all theme files.

This class has been designed and has been initially tested.
I can create a pull request if the group feels it is worth pursuing.

To do:

• develop and add Class
• test Class with a sniff that uses theme data

Rule:

WARNING Verify that no hard-coded URLs are found. Manual verification necessary. An exception is made for the Author URI and (Theme) URI as set in the style.css header as well as links to wordpress.org. Links in the text of PHP/JS comments should be excluded from this check.

Ref: https://make.wordpress.org/themes/handbook/review/required/theme-check-plugin/#info

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/links.php

To Do:

• Create unit tests
• Create new sniff

Rule type:

Error

Rule:

From what I can see, there are actually 5 distinct i18n related rules which may need sniffs - this issue covers the second item on the list.

1. All theme text strings are to be translatable. (#33)
2. Include a text domain in style.css
3. 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. (#35)
4. Can use any language for text, but only use the same one for all text. (#33)
5. Correct usage of the WP i18n functions. (#31)

Refs:
https://make.wordpress.org/themes/handbook/review/required/#language
https://make.wordpress.org/themes/handbook/review/required/theme-check-plugin/#additional-checks

The second item should be quite doable to implement as a sniff which checks the CSS files until it finds the one called style.css and only then searches for the required text string.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/textdomain.php

To do:

• Create unit tests -> this will be the hard part in this case
• Create new sniff

[New Sniff]

Rule:

ERROR : Check that capabilities are used not roles. Functions to check: get_role(), current_user_can(), current_user_can_for_blog(), user_can(), add_..._page()

Ref: https://make.wordpress.org/themes/handbook/review/required/#core-functionality-and-features

To do:

• Create Unit Tests
• Create Unit Sniff

Rule:

No hiding of the admin bar - check if show_admin_bar( false ) is called or if add_filter( 'show_admin_bar', '__return_false' ) is somewhere in the code.

Ref: https://make.wordpress.org/themes/handbook/review/required/#core-functionality-and-features

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/adminbar.php

To do:

- [ ] Create unit tests
- [ ] Create new sniff

• Open PR upstream in WPCS to improve the admin bar removal sniff.
• Add WordPress_Sniffs_VIP_AdminBarRemovalSniff sniff to the ruleset.

[New sniff] Check to ensure searchform.php is not loaded directly.

Rule type:

Error

Rule:

Standard templates should be called by their respective function.

Ref: https://make.wordpress.org/themes/handbook/review/required/#templates

ERROR | check that no include calls to searchform.php are found, if they are, recommend using get_search_form() instead.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/searchform.php

To do:

• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

Rule type:

Error

Rule:

From what I can see, there are actually 5 distinct i18n related rules which may need sniffs - this issue covers the fifth item on the list.

1. All theme text strings are to be translatable. (#33)
2. Include a text domain in style.css (#34)
3. 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. (#35)
4. Can use any language for text, but only use the same one for all text. (#33)
5. Correct usage of the WP i18n functions.

Refs:
https://make.wordpress.org/themes/handbook/review/required/#language
https://make.wordpress.org/themes/handbook/review/required/theme-check-plugin/#additional-checks

There is an existing sniff within WPCS which has extensive coverage in checking whether the i18n functions are used correctly.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/i18n.php
https://github.com/Otto42/theme-check/blob/master/checks/textdomain.php

To do:

• Add existing WordPress.WP.I18n sniff to the ruleset.
• Maybe add some more information to the handbook about what the correct usage is of the i18n functions ?

Rule:

ERROR : The theme must not use the <title> tag.

Ref: https://make.wordpress.org/themes/handbook/review/required/
"You should support up to 2 versions behind the current WordPress version."

The test and the sniff should include this exception: inline SVG code.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/title.php

To do:

• Create unit tests
• Create new sniff

[New sniff] Use of CDN is not permitted. All scripts and styles must be bundled with the theme, and enqueued.

Rule type:

ERROR - for listed uri's.
WARNING - if CDN is found in other uri's.

Rule:

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.

Ref: https://make.wordpress.org/themes/handbook/review/required/#stylesheets-and-scripts

If a specific search string is found in the url, an ERROR is displayed.
If 'cdn' is found in a url not on the list, a WARNING is displayed.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/cdn.php

This sniff reduces the lists from the the cdn.php themecheck, but will catch all the same blacklisted uri's.

Decision needed:

In this sniff an ERROR is displayed for listed uri's where the themecheck only issued a warning. I have changed this as I feel it can improve automation.

To do:

• Make the decision on ERROR vs WARNING for blaclisted uri's
• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

Rule:

Removal of WP admin pages is not allowed.

The exception would be a child theme removing a theme admin submenu page added by the parent theme.

Ref: #12 (comment)

Theme check file covering this rule:

n/a

Decision needed:

This is currently not in the handbook as a rule. Should it be one ?

Notes for implementation:

• Check for remove_menu_page() and forbid this.
• Check for remove_submenu_page() and only forbid this if one of a known list of WP Core admin pages is being removed

To do:

• If agreed this should be an error - Add the rule in the Theme Review handbook to the Requirements page.
• If agreed this should be an error - Create unit tests
• If agreed this should be an error - Create new sniff

Rule:

A number of functions are forbidden for use in a theme.

Current list:

• eval()
• ini_set()
• popen()
• proc_open()
• exec()
• shell_exec()
• system()
• passthru()
• base64_decode()
• base64_encode()
• uudecode()
• str_rot13()

Ref: https://make.wordpress.org/themes/handbook/review/required/theme-check-plugin/#check-for-bad-things

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/badthings.php

Decision needed:

The above list needs proper review - is this list complete ?

Should the WPCS WordPress.PHP.DiscouragedFunctions sniff be turned on as well ?

Should there also be a check against the use of the backtick operator ?
Ref: http://php.net/manual/en/language.operators.execution.php

To do:

• Review the list of forbidden functions.
• Create unit tests
• Create sniff
• If so agreed - add existing WordPress.PHP.DiscouragedFunctions sniff to the ruleset.
• If needed, update the rule in the Theme Review handbook.

Rule:

WARNING : Using a CDN is discouraged. All JS and CSS should be bundled.

Ref: https://make.wordpress.org/themes/handbook/review/required/#stylesheets-and-scripts

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/cdn.php

To do:

• Create unit tests
• Create new sniff

[New sniff] Check that Author and Theme URIs in style.css are not the same

Rule type:

ERROR

Rule:

ERROR | Check in style.css for the Author URI and Theme URI and verify that these are not the same.

Rule as it is found in the handbook.
There is no specific rule covering this.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/uri.php
Note that this theme check also checks that wordpress.org is not part of the URI. This will be moved to a separate sniff.

Decision needed:

If we are striving to have rules for sniffs the following rule should be considered.
Selling, credits, and links

• Theme URI and Author URI must not be the same.

Notes for implementation:

• This sniff will rely on the WordPress_AbstractThemeSniff Class to get the $sniff_helper array.
• Testing will require that a style.css file is in the same folder as the test file.

To do:

• Decision/Add the rule in the Theme Review handbook to the Requirements page.
• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

Rule:

WARNING : Themes must not deregister core scripts.

Ref: https://make.wordpress.org/themes/handbook/review/required/#stylesheets-and-scripts

"Required to use core-bundled scripts rather than including their own version of that script. For example jQuery."

This is basically meant to only check that core scripts aren't being deregistered, however maintaining a list of core scripts for that purpose would be a maintenance nightmare, so returning a warning when any such call is encountered is the current solution.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/deregister.php

To do:

• Add / clarify the rule in the Theme Review handbook to the Requirements page.
• Create unit tests
• Create new sniff

Decision needed by Theme Review Board:

There is currently no rule to check for the use of __FILE__ in combination with add_theme_page() which could lead to full path disclosure..

There is already a sniff available in WPCS which will check this - WordPress.VIP.PluginMenuSlug.

Should this sniff be activated for theme reviews ?

Advice: Follow WP VIP's lead in this.

To do:

• If agreed this should be a rule - add WordPress.VIP.PluginMenuSlug sniff to the ruleset.
• Add the rule in the Theme Review handbook to the Requirements page.

[New sniff] Verify that the theme is not auto-generated

Rule type:

ERROR

Rule:

Generated themes are not allowed in the theme directory.

Ref: I don't think there is a specific requirement that covers this.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/generate.php

To do:

• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

Decision needed by Theme Review Board:

There is currently no rule to check for alternative PHP open tags, like ASP tags and the PHP Script tag.

There has just been a discussion upstream in WPCS that these should not be allowed in general and it is expected that the associated sniff will be merged into WPCS.

Should alternative PHP open tags be forbidden in themes as well ?

Advice: Follow WPCS's lead in this.

To do:

• If agreed this should be a rule - add WordPress.PHP.DisallowAlternativeOpenTag sniff to the ruleset.
• Add the rule in the Theme Review handbook to the Requirements page.

[Implement sniff] Look for list of php file functions using WordPress.Functions.FunctionRestrictionsSniff

Rule type:

Error

Rule:

Use WordPress functionality and features first, if available.

Ref: https://make.wordpress.org/themes/handbook/review/required/#core-functionality-and-features

ERROR| Verify that file system calls use the WP_Filesystem method and not PHP native functions. For a list of functions to trigger on, see Theme-Check plugin - /checks/malware.php

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/malware.php

Decision needed:

I have changed this from WARNING to ERROR. It is very easy to change back, but I thought it appropriate to be an ERROR. Are there any cases where use of these functions are acceptable?

To do:

• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

[New sniff] Check for different kinds of favicons and issue Error if found.

Rule type:

Error

Rule:

Use WordPress functionality and features first, if available.

Ref: https://make.wordpress.org/themes/handbook/review/required/#core-functionality-and-features

ERROR | Verify that no favicon / Apple icon / Windows tile / Android whatever they call it is being added from the theme. The current check is in Theme-Check plugin - /checks/favicon.php, but could definitely use some fine-tuning and improvement.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/favicon.php

Decision needed:

Switch from WARNING in themecheck to ERROR in Sniff.

To do:

• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

Otto brought this up in Slack (https://wordpress.slack.com/archives/themereview/p1470952005002504), but it's long been one of those things that we wouldn't allow.

Basically, themes should not be attempting to find and load the wp-load.php file. I can't think for a legit use case for themes to do this.

This is most often an issue when themes are attempting to create a dynamic stylesheet instead of utilizing the wp_add_inline_style() function.

Rule:

Have either UNIX or DOS line endings, not both. This rule gets applied to PHP, CSS, JS and TXT files.

Ref: https://make.wordpress.org/themes/handbook/review/required/theme-check-plugin/#line-endings

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/lineendings.php

Decision needed:

Currently the Theme Check plugin check also checks the line endings in .txt files. This is not covered by the existing Generic.Files.LineEndings sniff and quite likely can't be covered by it as no tokenizer for .txt files is available within PHPCS.

A decision is needed on if and if so, how to continue checking the line endings for .txt files.

To do:

• ... ?

Related: #3

[New sniff] Check that all required headers in style.css are there.

Rule type:

Error

Rule:

ERROR | Check specifically against style.css whether the required headers are found. See Theme-Check plugin - /checks/style_needed.php for the list.

Rule as it is found in the handbook.
There are no other specific rules in this sniff. Most are pretty obvious.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/style_needed.php
Required styles are also included in this theme check but they will have to be moved to a separate sniff.

[Optional Section] Decision needed:

There is only the one rule covering text domain requirements. The other checks that will be done are pretty obvious. However if we are striving for rule/sniff consistency I would suggest the following additions.
Stylesheets and Scripts (Required)
The main style.css header requires: Theme name, Description, Author, Version, License, License URI, and Text Domain.

Advice/Request for decision: Should the above header requirements be added to the requirements lists?

Notes for implementation:

• This sniff will rely on the WordPress_AbstractThemeSniff Class to get the $sniff_helper array.
• Testing will require that a style.css file is in the same folder as the test file.

To do:

• Decision and implementation to add the rule in the Theme Review handbook to the Requirements page.
• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

[New sniff] If theme uses include(_once) or require(_once) issue warning to consider get_template_part().

Rule type:

Warning

Rule:

Custom template files should be called using get_template_part() or locate_template().

Ref: https://make.wordpress.org/themes/handbook/review/required/#templates

WARNING (manual check required) | Check if a theme uses include(_once) or require(_once) (where they should use get_template_part()). Current implementation excluded the functions.php file from this check. We may want to continue doing so.

Theme check file covering this rule:

https://github.com/Otto42/theme-check/blob/master/checks/include.php

To do:

• Create unit tests
• Create new sniff
• Adjust existing WPCS / PHPCS sniff and send in PR upstream.
• Add existing sniffname sniff to the ruleset.

Rule:

ERROR : Check for usage of deprecated WP constants relating to themes and discouraged PHP constants e.g __FILE__. We could probably extend an existing sniff of similar ilk for this.

Ref: https://make.wordpress.org/themes/handbook/review/required/#core-functionality-and-features

Theme check file covering this rule:

https://github.com/Otto42/theme-check/pull/162/files

Decision needed:

Confirmation is needed that the current list is correct. If not, input is needed about which other theme related WP constants should (not) be covered by this sniff.

To do:

• Review the current list of constants being checked for and confirm that this covers the theme related WP constants. If not, please leave a comment in this issue thread with details of the changes needed.
• Expand and clarify the rule in the Handbook.
• Create unit tests
• Create new sniff
• Open new item for related but distinct PHP constants sniff
• If needed: Open new item for related but distinct other constants sniff

Rule type:

Error - (No) Error Control Operator @

Rule:

No PHP or JS errors.

PHP errors should not be silenced

Ref: https://make.wordpress.org/themes/handbook/review/required/#code

To do:

• Document the check in the Theme Review handbook to the Requirements page.
• Add existing <rule ref="Generic.PHP.NoSilencedErrors" /> sniff to the ruleset.