Work on requirements automation update #1

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.

Code

  • No PHP or JS errors. – RequiredRun PHP and JS validator to catch code errors like with the plugins
  • No removing or modifying non-presentational hooks. – RequiredCheck 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. – InfoCheck if contains theme slug

Core Functionality and Features

  • Use WordPress functionality and features first, if available. – InfoExtend list to include favicon and logo
  • Don’t include admin/feature pointers. – RequiredCheck for `
    wp_enqueue_style( ‘wp-pointer’ ); wp_enqueue_script( ‘wp-pointer’ );`
  • No disabling of the admin toolbar. – RequiredCheck 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) – InfoAdd 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) – WarningChecks for user_contactmethods and metaboxes

Language

  • Include a text domain in style.css –  RequiredSelf explanatory

Naming

  • Theme names must not use: WordPress, Theme. – RequiredA 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. – RequiredCheck for `add_settings_section`, `add_settings_field`, `register_setting`, `settings_fields` and `do_settings_sections`

Plugins

  • Don’t include any plugins. A theme can recommend plugins but not include those plugins in the theme code. –  RequiredCheck 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`