Table of Contents
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:
- 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. All menu locations must not use placeholders such as Add Menu, Set Menu, etc., as this forces the user to either add a menu or modify the theme to remove the placeholder.
- 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:
- Site Icon
- Navigation Menu
- Custom Header
- Custom Background
- Feed Links
- Post Thumbnail
- 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.
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.
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.
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.
Following are the Gutenberg editor support requirements:
- Themes must ensure that all WordPress core blocks are styled to match the design of their theme/demos.
- Themes must not register blocks as that is plugin territory. If extra blocks are required, they must be added via an accompanying plugin.
- Custom blocks in accompanying plugins must define basic block styles to ensure they work with other themes. Themes may enhance block styles.
- Themes must not blacklist blocks.
Wide-images and Styling Classes: It is recommended that themes provide support for the .alignwide and .alignfull classes by declaring theme support for wide-images and styling these classes. For more information, refer to Align wide and full classes and Gutenberg & Themes.
Gutenberg Editor: It is recommended that the theme styles are added to the Gutenberg editor using the enqueue_block_editor_assets action hook and that web fonts are enqueued.
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.
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.
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.