WPThemeReview input/decision needed issues

One of the thing that helps theme reviewers and theme authors check and write better code is having automatic checks in place that will warn them if the code they wrote is compliant with Theme Review Team rules.

This is why we are working on WPThemeReview coding standards. But this ruleset is not finished and has some issues that we need help with. That is why we have a list of issues in the WPThemeReview standards with input/decision needed flag.

I will be pasting these issues with some comments, so that we can get some more insights about theme before making some decisions in the meetings.
Feel free to leave a comment on any of those, what you think needs to be done to get some clear resolution so that we can start writing sniffssniff A module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food. 🙂

Issues list

Variables in template files are flagged as global

Part of this issue has been resolved with the modified PrefixAllGlobals sniffsniff A module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food., but a decision needs to be made about GlobalVariablesOverride sniff which will warn about overwriting WordPress native global variables – and in templates (loaded using coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functions) the variables such as $title, $post, $page etc.

Maybe we could extend the GlobalVariablesOverride sniff in the similar fashion as PrefixAllGlobals sniff and exclude that check if the file name matches the in the allowed folder or are coming from the template files.


Add EnqueuedResourceParameters sniff to the WPThemeReview ruleset

WPCSWordPress Coding Standards A collection of PHP_CodeSniffer rules (sniffs) to validate code developed for WordPress. It ensures code quality and adherence to coding conventions, especially the official standards for WordPress Core. 1.0.0 added a new WordPress.WP.EnqueuedResourceParameters sniff which checks that when registering/enqueuing scripts and styles, a $version is passed correctly so new versions will break out of the browser cache and for scripts, that the $in_footer parameter is passed to prevent unnecessary layout-rendering blocking scripts.
Should this be added in WPThemeReview ruleset at all, and if yes, should it be a warning or an error?

While having $version parameter can be beneficial (cache busting), with modern development workflows (gulp, webpack), it’s not needed. But we don’t know how many theme authors are using these tools, so adding this as a warning may not be a bad idea.


Proposal to add additional rulesets to WPThemeReview

Separate ruleset in different rulesets like in WPCS (WordPress-Core, WordPress-Extra etc.). Similarly the WPThemeReview would have

WPThemeReview-Required with everything which is in the handbook.
WPThemeReview-Extra with sniffs covering additional best practices and sniffs which cover rules which have been proposed to the TRT, but have not (yet) been approved.

In practice this would result in the following:

WPThemeReview – the Theme native sniffs would live in this directory and the ruleset would include the Required and Extra rulesets
WPThemeReview-Required – directory with only a ruleset
WPThemeReview-Extra – directory with only a ruleset. Ruleset would include WPThemeReview-Required and references to additional sniffs.

Naming of these need to be decided and a list of extra rules we’d recommend would need to be added.


Discourage CSS rules for images setting width:auto

Flag CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. rules for images that have the property width: auto.
There is no rule in the handbook for this, but it falls under the general guideline to honor the user’s choices.

The default value for CSS width is auto, so there is no need to specify it. When it is specified, it will override the HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. width attribute. So an img tag with a different width attribute than the source image is would be affected, and it will display as the size of the source image instead of the size the user requested.

Additional points to consider about this are

  • The CSS tokenizer is proposed to be removed in PHPCS 4.0, so while we can still sniff CSS files at this time, there’s no guarantee this can still be done in the future.
  • CSS within inline HTML in PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. files can be checked, though if the value for width is set in a variable or constant, it will not be possible to sniff this in a reliable manner.

Adding metadata sniffs

We need sniffs that check metadata. Currently, the theme review team allows themes to have metadata if it is presentational in nature. Some common examples:

  • SidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. position
  • Background color
  • Layout

However, we do not allow metadata that is non-presentational in nature. Some common examples:

Video URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org
Gallery shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site.
User-specific social URLs

This would probably need to be an warning-level notice because we wouldn’t be able to know whether the metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. is presentational or not via code.


Disallow hiding or removing the themes section of the customizer

The theme section in the customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. shows the name of the active theme and the Change button where the user can preview and select another theme.

By hiding or removing the section authors can lock users in.

A decision needs to be made for this, if this doesn’t exist in the handbook, a rule needs to be added, then the examples can be added and tested against when creating a sniff.


Passing dynamic information to sniffs

Adding an optional way to check for things like text domain when running PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS. using CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress., or in the Theme SnifferTheme Sniffer Theme Sniffer is a plugin utilizing custom sniffs for PHP_CodeSniffer that statically analyzes your theme and ensures that it adheres to WordPress coding conventions, as well as checking your code against PHP version compatibility. The plugin is available from GitHub. Themes are not required to pass the Theme Sniffer scan without warnings or errors to be included in the theme directory. 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. Another thing to add would be the theme tags parameters, and then if a theme uses add_theme_support() but the tag is not, the sniffer would throw an error.

Input is needed about what additional dynamic variables could be checked in this way, what sniffs need to be added and decide on names of the sniffs.


Add malware/worm sniff

Verify a number of typical php snippets which are known as malware indicators

The list of snippets might need to be expanded.

The rule should be checked if exists in the handbook, if not add it. Then we need examples, and a sniff name can be made (based on the handbook rule) and created.


Incorrect function parameter usage

Check for incorrect usage of certain parameters in WP functions (hard-coded) and provide valid alternatives based on the parameter passed.

To create this sniff, a list of function should be compiled where theme authors are typically doing this wrong, i.e. passing hardcoded information instead of variables/function calls.

Which function and parameters should be covered by this sniff? Input needed.


Check for direct load of searchform.php

Check to ensure searchform.php is not loaded directly.

This was a WIP but since we’ve branched off to a separate ruleset was not worked on.

We need to see if there are other violations like this and maybe include them in a more general sniff that would cover the required rule in the handbook.


Check that all required headers in style.css are there

This sniff proposal needs an input based on the fact that CSS sniffs may be deprecated/removed in PHPCS 4.0. So we would be doing a double work. Maybe we should focus on moving CSS/JS issues to Theme Sniffer plugin, so that they can be checked using eslint and stylelint or some similar tool.


Make sure widget_title filter has all parameters

This sniff would check if the correct number of parameters is passed to widget_title.

This issue raises a number of questions:

  • Is this the only filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. where a check like this would need to take place or are there / will there be more actions/filters where the parameters will need to be checked ?
  • Does the check need to be for the amount of parameters passed or also need to go into the content ? (If the answer would be ‘content’, that would be neigh impossible as variables can be named differently across themes.)

Questions from an implementation perspective:

  • Do we need to create a re-usable abstract class which handles a large part of the logic and can be extended for individual actions/filters or small groups thereof?
  • If this will be the only one, we can just use a hard-coded check, if not, we may need to have an extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. array property listing the hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. or in the case of the abstract, possibly a function instead.
    Also: is there a rule in the handbook covering this or should it be added ?

Check that only one – or at most two – text-domains are used in the theme

We need to see how to implement this into a sniff – what direction we want to go with this?


Check that all text strings are translated and in the same language

The “check that all translatable strings are in the same language” bit may be sniffable if we could do some sort of dictionary check, possibly using the PHP ICU extension, but the “check that all text strings are translatable” bit is neigh impossible to sniff for.

We need a decision about this, do we want to pursue this or not.


Using a CDN is discouraged

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

It would be really helpful for finishing this off to have code samples of both things which should be flagged as well as things which shouldn’t be. The more variety in the code samples, the better!


Check for removal of admin pages

Themes can remove admin pages from, for instance, a parent theme, but they are not allowed to remove WP Core admin pages, so there is a lot more involved in that.

Rule should be added in the handbook about this, and a sniff needs to be worked on.

Conclusion

These are issues where we need some decision on. Either updating/adding rule in the handbook, naming decision and most important of all: code examples.

The more code examples we have, the quicker and easier it is to write sniffs.

Additionally, if you have time and can go through the open issues and think that some of those could be a good first issue to solve that would be great, as we could work on them in the upcoming WCEU contributor dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/..

#automation, #rules, #sniffs, #wpthemereview

Rough draft: Upsell/Affiliate/Sponsorship guidelines

After talking with the team leads, I was asked to publish an outline of ideas to consider for guidelines. These are being posted here for feedback from the entire community.

Nothing is set in stone. The below and any comments will be discussed in the next team meeting. Now is the time to share your thoughts.

The following is in response to the recent uptick in discussion as well as usage of affiliate and sponsored links within themes. These need to be addressed in a meaningful way that’s both fair to users and theme authors without allowing themes to be displaying things that are akin to spam.

The general rule of thumb should be: Any link, advertisement, etc. should benefit the user in using this specific theme. It should not be upsells of unrelated products.

Affiliate links in general:

Affiliate links in and of themselves are OK. They’re not inherently bad.

Upselling:

Themes may only upsell products and services that are directly related to the theme. It’s probably best to go with a whitelist of things that are OK just so that it’s clear. I think the following covers most things, but I may have missed something.

  • Child themes for this specific theme.
  • A pro version of the theme, whether in theme or 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party form.
  • An add-on plugin for this theme.
  • Design/Development services.
  • Theme support.

Plugin recommendations:

Themes may not include third-party plugin recommendations either via link or TGMPA solely as part of a paid sponsorship. Any plugin recommended by a plugin (affiliate link or otherwise) must have some sort of theme integration. The following is a list of some things that I consider theme integration.

  • Theme uses plugin hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. to make template HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. match.
  • Theme adds CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. to directly style components of the plugin.
  • Theme adds custom templates to handle the front-end output.

Paid sponsorship:

Any sort of paid sponsorship for backlinks should be prohibited. For example, hosting companies shouldn’t have their links on a theme admin page, which are not relevant to the theme itself.

Meeting Minutes 06/11/15

Per our meeting yesterday and the comments on the earlier post, the Theme review requirements have been modified. Additions are highlighted in red, and deletions are struck-out:

A theme must meet all of the following requirements to be included in the WordPress.orgWordPress.org 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. https://wordpress.org/ theme repository.

Along with these checks you should also make sure you 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. It automatically checks for all the required items. You can find a full list of what it checks here.

AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)

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

Code

  • No PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. or JS errors.
  • Include at least index.php and style.css.
  • Have a valid DOCTYPE declaration and include language_attributes.
  • Sanitize everything.
  • No removing or modifying non-presentational hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same..
  • No shortcodes are allowed.
  • Support the following WordPress-generated CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. classes:
    • alignleft
    • alignright
    • wp-caption
    • wp-caption-text
    • gallery-caption
    • sticky (can be unstyled)
    • bypostauthor (can be unstyled)
    • screen-reader-text
  • Must meet all uploader/Theme Check required tests
  • Provide a unique prefix for everything the Theme defines in the public namespace, including options, functions, global variables, constants, post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., etc.

CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Functionality and Features

  • Use WordPress functionality and features first, if available.
  • Don’t include admin/feature pointers.
  • No custom post types and no custom taxonomies.
  • No pay wall restricting any WordPress feature.
  • No disabling of the admin tool bar.
  • Use get_template_directory() rather than TEMPLATEPATH to return the template path.
  • Use get_stylesheet_directory() rather than STYLESHEETPATH to return the stylesheet path.
  • 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 filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..
  • Able to have child themes made from them. (Child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. 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.

Presentation vs. Functionality

  • Must not not generate user content, or configure non-theme site options or site functionality.

Documentation

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

Favicons

  • If implemented, disable favicons by default and have the ability for users to override.

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.

Licensing

  • Be 100% GPLGPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. 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. and/or 100% GPL-compatible licensed.
  • Declare copyright and license explicitly. Use the license and license uri headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. 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.

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.

Options and Settings

  • 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”).
  • Use the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. 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.

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.

Security and Privacy

  • Don’t phone home without informed user consent. Find out more about security here.
  • Make any collection of user data “opt-in” only and have a theme option that is set to disabled by default. Validate and sanitize untrusted data before entering into the database. All untrusted data should be escaped before output. (See: Data Validation.)
  • No URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org shorteners used in the theme.
  • Use esc_attr() for text inputs and esc_textarea() for textareas.

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.

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.

If you have any questions regarding what was updated/clarified, please ask in the comments.

Please note that we will very likely continue to look for ways to clarify and simplify the Requirements, including more extensive usage of code examples, explanations, and clarifications linked from the Requirements elsewhere in the Theme Review Handbook.

Theme Review Requirements and Documentation

Some time ago, the Theme Review Guidelines underwent a major revision, with focus on Theme Review Requirements, and moving of the official version of those Requirements from the Codex to the Theme Review Handbook. During that change, several requirements were omitted from the previous iteration. Those omissions, along with the apparent spread of documentation locations, has led to considerable confusion for admins, reviewers, and developers alike.

Let’s sort that out, and clean it up.

Documentation

Documentation Sources

Handbook

The only and official Theme Review documentation is the Theme Review Handbook. Within that handbook are the Theme Review Requirements.

The Requirements page in the Handbook is deprecated. It should be removed. Until just a moment ago, it was linked from the welcome box on the front page of Make/Themes. I have changed that to a link to the official Requirements ins the Handbook.

The various Handbook pages linked from the Theme Review Codex page are also deprecated, and should be removed.

Make/Themes

The Make/Themes site (this site) is where we post official things, and generate discussion not well-suited to SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. Anything discussed on Make/Themes is unofficial/discussion-only, unless and until it is posted in the Handbook, whether as a Requirement or a Recommendation.

Codex

The Codex is deprecated, and is slated to go away at some point. Thus, the Theme Review page on the Codex is no longer official, or maintained.

Summary

Official:

Unofficial/Discussion-Only:

  • Make/Themes blog posts

Deprecated:

Requirements

Next: requirements. Please discuss the additions in red italic, below. I am proposing them to be included again in the official version. The complete list of current Requirements is below:

A theme must meet all of the following requirements to be included in the WordPress.orgWordPress.org 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. https://wordpress.org/ theme repository.

Along with these checks you should also make sure you 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. It automatically checks for all the required items. You can find a full list of what it checks here.

AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)

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

Code

  • No PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. or JS errors.
  • Include at least index.php and style.css.
  • Have a valid DOCTYPE declaration and include language_attributes.
  • Sanitize everything.
  • No removing or modifying non-presentational hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same..
  • No shortcodes are allowed.
  • Support the following WordPress-generated CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. classes:
    • alignleft
    • alignright
    • wp-caption
    • wp-caption-text
    • gallery-caption
    • sticky (can be unstyled)
    • bypostauthor (can be unstyled)
    • screen-reader-text
  • No backwards compatibility support for outdated versions of WordPress
  • No Theme Check required notices
  • No deprecated function or doing_it_wrong() notices
  • Provide a unique slug for everything the Theme defines in the public namespace
  • Prefix all options, custom functions, custom global variables and custom constants with the theme-slug. (Note: moved from Options and Settings, as the requirement has a wider scope than just options)

CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Functionality and Features

  • Use WordPress functionality and features first, if available.
  • Don’t include admin/feature pointers.
  • No custom post types and no custom taxonomies.
  • No pay wall restricting any WordPress feature.
  • No disabling of the admin tool bar.
  • Use get_template_directory() rather than TEMPLATEPATH to return the template path.
  • Use get_stylesheet_directory() rather than STYLESHEETPATH to return the stylesheet path.
  • 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 filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..
  • Able to have child themes made from them. (Child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. ready)
  • Include comments_template().
  • The theme tags and description must match the what the theme actually does in respect to functionality and design.
  • Properly implement core template tags and action/filter hooks, when used.

Presentation vs. Functionality

  • Since the purpose of Themes is to define the presentation of user content, Themes must not be used to define the generation of user content, or to define Theme-independent site options or functionality.

Documentation

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

Favicons

  • If implemented, disable favicons by default and have the ability for users to override.

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.

Licensing

  • Be 100% GPLGPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. 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. and/or 100% GPL-compatible licensed.
  • Declare copyright and license explicitly. Use the license and license uri headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. 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.

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.

Options and Settings

  • 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”).
  • Use the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. 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.

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.

Security and Privacy

  • Don’t phone home without informed user consent. Find out more about security here.
  • Make any collection of user data “opt-in” only and have a theme option that is set to disabled by default. Validate and sanitize untrusted data before entering into the database. All untrusted data should be escaped before output. (See: Data Validation.)
  • No URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org shorteners used in the theme.
  • Use esc_attr() for text inputs and esc_textarea() for textareas.

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.

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.
  • Template files must follow the template hierarchy.

Obsolescence

  • Themes are required to be kept current once accepted in the Theme directory.

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.

I am formally proposing that the text in red-italic be restored to the Theme Review Requirements. Please discuss in the comments.

Details on the new theme settings (customizer) guideline

During yesterday’s team meeting, we made what we knew would be a controversial decision about theme settings. This post will go into more details about this decision and how we plan to move forward.

Continue reading →