We are a group of volunteers who review and approve themes submitted to be included in the official WordPress Theme directory.
We do license, security, and code quality reviews.
We help build and maintain default themes.
The primary focus of the team is to help theme authors transition to blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-based themes.
During this week’s meeting, we discussed modifying our workflows, both to add a “Report Theme” workflow, and to add an auto-approval workflow for updates to approved, live Themes. As adding these elements will essentially require a complete rewrite of the Theme Review process workflows, we decided that now would be a good time to review/discuss both our existing workflow, and the proposed additions. The thinking is that, if we’re going to start from scratch, we might as well make sure that we’re building the best possible workflow, rather than continue to “bolt on” pieces to a system that already resembles something created by Dr. Frankenstein.
To that end, I have roughed-out a workflow diagram that shows both our current workflows, and the new/proposed additional workflows. To help make the workflow more understandable, the various actions are sub-divided. At the top are user/developer actions that set things in motion. After that are a series of system actions that lead to the tickets. After that are the actions of the Theme Review Team that process the tickets. And finally, there are the system actions that make Themes live in the directory.
Note that the existing workflow is in black-line, and the new/proposed workflows are in red-line. The “Report Theme” button that we discussed during the meeting would fall under the “Live Theme Reported” box in the upper right corner:
Current and proposed workflows for Theme submission, review, approval, update, and reporting
So, please review and discuss. Do the proposed workflows make sense? Are there ways that we can improve them? While we welcome feedback on our existing workflows (in particular: does the diagram accurately reflect our current workflows), at this point, we are primarily looking for feedback on the proposed workflows for the new functionality: the Theme reporting functionality, and the auto-approval of updates to live Themes.
Theme developers: please see this important information from @jorbin on Make/CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. regarding upcoming core support for PHP7, and how that does and will impact Themes.
As was discussed in previous meetings, we have begun work on the Theme Review Team’s GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repository to build a library of code examples. The first area to tackle is example Customizer code, which currently includes examples for adding panels, sections, settings, basic coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. controls, specialized core text controls (email, URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, etc.), advanced core controls (color control, image control), and an example custom control (radio image).
Suggestions, requests, questions, and pull requests welcome!
A theme must meet all of the following requirements to be included in the WordPress.orgWordPress.orgThe 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 pluginPluginA 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.
AccessibilityAccessibilityAccessibility (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)
No PHPPHPPHP (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.
No removing or modifying non-presentational hooksHooksIn 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 CSSCSSCSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. classes:
sticky (can be unstyled)
bypostauthor (can be unstyled)
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 metaMetaMeta 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.
CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Functionality and Features
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 filterFilterFilters 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..
Declare copyright and license explicitly. Use the license and license uri headerHeaderThe 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.
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 CustomizerCustomizerTool 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.
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.
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 URLURLA 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.
If using templates, custom template files should be called using get_template_part() or locate_template().
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.