I will be leading the initiative to automate the requirements so to reduce the amount of manual checking.
The first steps that we have taken is to remove duplicate requirements on three topics:
The second step was to work on the template requirements as they were previously too vague.
After discussing the requirments with the other admins this is the list of requirments that we could automate. The information below are the requirments with the type of notice that the check would output in bold and then how we could check for this requirement in italics. We will be discussing this further on Tuesday at the team meeting. I have published this today so that you can read through the proposal and prepare some thoughts for the team meeting. At the end of the discussion I will open a GitHub issue for each of the requirements to track the progress. Everyone is welcome to help writting pull requests to complete these checks.
- No PHP or JS errors. – Required – Run PHP and JS validator to catch code errors like with the plugins
- No removing or modifying non-presentational hooks. – Required – Check for `remove_action(‘wp_head’)`
- Provide a unique prefix for everything the Theme defines in the public namespace, including options, functions, global variables, constants, post meta, etc. – Info – Check if contains theme slug
Core Functionality and Features
- Use WordPress functionality and features first, if available. – Info – Extend list to include favicon and logo
- Don’t include admin/feature pointers. – Required – Check for `
wp_enqueue_style( ‘wp-pointer’ ); wp_enqueue_script( ‘wp-pointer’ );`
- No disabling of the admin toolbar. – Required – Check for `add_filter(‘show_admin_bar’, ‘__return_false’);` and `show_admin_bar(false)`
- The theme tags in style.css and description must match the what the theme actually does in respect to functionality and design. (See: Theme Tag List) – Info – Add checks for buddypress, featured-images, custom-header, custom-background, custom-menu, editor-style, flexible-header, post-formats, theme-options and threaded-comments
Presentation vs Functionality
- The theme options should not be pseudo custom post types and save non-trivial user data. Non-design related functionality is not allowed. (See: Plugin territory examples) – Warning – Checks for user_contactmethods and metaboxes
- Include a text domain in style.css – Required – Self explanatory
- Theme names must not use: WordPress, Theme. – Required – A check has already been written by @poena which need to be added in the plugin.
- Spell “WordPress” correctly in all public facing text: all one word, with both an uppercase W and P. – Warning – Self explanatory
Options and Settings
- 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”). – Required – Check for `current_user_can()` & `user_can()` with roles & `get_role()`
Use the Customizer for implementing theme options. – Required – Check for `add_settings_section`, `add_settings_field`, `register_setting`, `settings_fields` and `do_settings_sections`
- Don’t include any plugins. A theme can recommend plugins but not include those plugins in the theme code. – Required – Check for bundled zip files.
Stylesheets and Scripts
- Required to use core-bundled scripts rather than including their own version of that script. For example jQuery. – Warning – @poena has already written a check for `wp_dequeue_script`