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.
As was discussed in previous meetings, we have begun work on the Theme Review Team’s GitHub 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 core controls, specialized core text controls (email, URL, etc.), advanced core controls (color control, image control), and an example custom control (radio image).
Suggestions, requests, questions, and pull requests welcome!
Declare copyright and license explicitly. Use the license and license uri header slugs to style.css.
Declare licenses of any resources included such as fonts 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 Customizer 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 URL 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.