WordPress Theme Requirements Part 2 -  Features

This article explains the WordPress core features and settings that themes are required to support. This article is Part 2 of the requirements for WordPress Theme authors. WordPress is a large topic, so you will also need Parts 1 - 6 of the requirements below:
- WordPress Theme Requirements Part 1 - General
- WordPress Requirements Part 2 - Features (you are here!)
- WordPress Requirements Part 3 - Theme Plugins
- WordPress Requirements Part 4 - Coding
- WordPress Requirements Part 5 - Theme Security
- WordPress Requirements Part 6 - Gutenberg

If you are a Code author looking for more information on Wordpress Plugins to upload to a code category, please refer to the Plugin Requirements.

• Core Features
• Core Settings
• Sidebars and Content Areas
• Menu Position
• Customizer
• Child Themes
• WooCommerce Templates

Core Features

Following are the core feature requirements for WordPress themes:

• Themes must not use features/APIs meant for WordPress core, including these private functions.
• Themes must display posts, pages, archive pages, home page, blog page, search, etc., and must support all of the following features:
  • Comments
  • Sidebars
  • Editor style
  • Title tag
• Themes must be widget-ready in all advertised locations.
• wp_nav_menu() must be included in at least one theme location. Menu locations may only display placeholders such as Add Menu and Set Menu if the current user is a logged in admin user and no menu has yet been set.
• All widgets included with WordPress core must display correctly in all widgetized areas and must be appropriately styled to match the theme/demo design.
• Themes must not unregister default WordPress widgets. Instead, new widgets should be registered via a plugin.
• index.php must be reserved for the standard blog "latest posts" view.
• Custom solutions are not allowed for the following features, instead, the core feature must be used/supported:
  • Logo
  • Site Icon
  • Navigation Menu
  • Custom Header
  • Custom Background
  • Feed Links
  • Post Thumbnail

Exceptions

• Core features may be extended if required, but only if done so in a way that will not prevent plugins from filtering or extending them.
• Fallbacks may be provided as long as they are only provided to users on versions of WordPress that do not contain the core feature. For example, the Site Icon feature was added in WordPress 4.3. Users on WordPress 4.3 or above must not be presented with a custom favicon solution.
• In cases where it is non-trivial to migrate users to the core feature because of existing *presentational* data, the custom functionality can continue to be used. For example, if CSS has been entered into a custom CSS feature, there is no need to migrate it to the core Additional CSS feature. The custom CSS feature can continue to be used as long as the core functionality is not disabled or interfered with in any way.

Core Settings

Following are the core settings requirements for WordPress themes:

• Themes must not create a custom setting if an equivalent already exists in WordPress core.
  For example, themes must not create a setting for Posts Per Page since it already exists in Reading settings. Other examples include Site tagline, Custom date formats, Search engine visibility, etc.
• An existing WordPress core option may be updated through a custom theme settings page if it improves the user experience.

Sidebars and Content Areas

Following are the sidebars and content requirements for WordPress themes:

• Themes must not display content areas if no content exists for them. For example, is_active_sidebar can be used to only display sidebar content and supporting markup if a sidebar is active.
• Themes must not display public placeholder messages such as Add widgets here.
• Themes must be styled to be usable with or without active content areas.
• Content, including placeholder/demo content, must not be hardcoded into the template files.

Menu Position

Following are the menu requirements for WordPress themes:

• If the theme has an Options page and no other custom Admin pages, then it must go in either the Customizer (strongly recommended) or the Appearance section.
• If the theme creates other sub menu items not directly related to Appearance such as installing plugins, importing demo data, etc, then a single top level menu entry that groups all themes settings is allowed.

Customizer

Following are the customizer usage requirements:

• Customizer Adoption: Integrating the Customizer into a theme will make it more appealing to developers and website creators by providing a core theme options framework and live site previewing. Users are increasingly expecting to find theme options within the Customizer. For more information, refer to Theme Options – The Customize API.
• Customizer Sanitization: All Customizer settings must be properly validated and sanitized with an appropriate sanitization callback. This may either be done by defining a callback function or hooking into an action prior to saving all settings to the database. For more information, refer to the Validation and Sanitization in the Customizer article.
• Core Sanitization Methods: Core sanitization functions must be used rather than custom sanitization callbacks that sanitize with the same methodology. For example, if a URL field is expected to contain a valid URL, the sanitization function must be esc_url instead of a custom callback.
• Custom Sanitization Callbacks: Custom sanitization callbacks are allowed if no core sanitization function exists, but they must utilize proper sanitization methods. For example, this callback is simply returning the unsanitized value “as-is”, which is unacceptable.
• Extending the Customizer: Themes can add custom controls and apply styles/scripts to the Customizer, but they must not adversely affect the Customizer output in any way. All core features must be preserved and plugins must be able to add sections and panels as needed, without conflict.

Child Themes

If a child theme is provided with the theme, it must:

• Load the parent stylesheet using wp_enqueue_style() instead of @import.
• Consist of style.css, functions.php and screenshot.png files at a minimum.
• Append “Child” to the theme name so it can be identified as a child theme.
• Include files within the child theme directory using get_stylesheet_directory().
• Reference the parent theme via Template: parameter in the style.css header

The child theme will be held to the same standards and best practices as the parent theme. For more information on Child Theme development, refer to WordPress Codex article.

WooCommerce Templates

Developers must never remove WooCommerce template hooks from modified core templates. Removing hooks will likely lead to issues with extensions, as well as core WooCommerce functionality.

Strongly Recommended! Using WooCommerce Action and Filters: It is recommended that developers utilize available actions and filters within WooCommerce rather than modifying core templates. This makes it far easier to maintain a theme and ensure core template updates are properly reflected.

Explore WooCommerce template files on GitHub to find relevant actions and filters.