Are you thinking of adding your theme to the WordPress.org repository? Are you aware that all the Theme are reviewed by WordPress Theme Review Team (WPTRT) before adding it to the WordPress.org repository? WPTRT checks your WordPress Theme mainly in the area of the License, Code Quality, Security and Layout issues.
This article is useful for the developers who are preparing to submit theme to WordPress.org. This article will help you to get your theme approved by WordPress Theme Review Team.
WordPress Theme Development
- Set WP_DEBUG to true in your wp-config.php file and make sure your theme does not output any messages.
- Install the following 3 plugins and check your theme.
- Screenshot
- Check screenshot.png is sized properly: Recommended 4:3 W:H ratio, size 600x450px (2x the previous 300x225px, to account for Retina displays).
- Maximum size: 600x450px
- The screenshot should be “reasonable facsimile” of the default view of the site
- Check your License: Review the header tags in style.css. Ensure that the License and License URI header tags exist. License must be GPL-compatible, and that the indicated URI is a valid, full-text license. Further, all your icons, fonts and scripts used must be GPL-compatible. Check other template files, such as footer.php, to ensure that there are no inline comments regarding use restriction, such as prohibiting changing the footer, or requiring a credit link, etc.
- Check your Theme Name, Theme URI and Author URI.
- Theme Name should be unique and you need to check in the WordPress.Org Theme repository to see the name is already taken or not. Also you need to verify that the Theme name meets naming convention requirements.
- Theme URI is required to link to a page specifically related to the Theme. It cannot be just a demo site of the theme.
- Author URI is required to link to an author’s personal web site or project/development website.
- Template/Stylesheet Path:
- Themes are required to use get_template_directory() rather than TEMPLATEPATH to return the template path.
- Themes are required to use get_stylesheet_directory() rather than STYLESHEETPATH to return the stylesheet path.
- header.php
- Feed links shouldn’t be hard-coded into the document head
- No CSS files other than style.css should be hard-coded into the document head. These files must either be enqueued and hooked in appropriately, or added using IE conditional tags. See wp_enqueue_style() function.
- No scripts or script file links are hard-coded into the document head. These must be enqueued and hooked in appropriately. See wp_enqueue_script() function.
- No unnecessary meta tags (WordPress generator tag, SEO meta tags, copyright meta tags, etc.) are hard-coded into the document head.
- The wp_head() template tag is placed immediately before the closing HTML head tag.
- footer.php
- No scripts or script file links are hard-coded into the footer. These must be enqueued and hooked in appropriately. See wp_enqueue_script() function.
- The wp_footer() template tag is placed immediately before the closing HTML body tag.
- functions.php, admin setting file and all other function files
- Themes are required to prefix all options, custom functions, custom variables, and custom constants with theme-slug (or appropriate variant).
- Themes are required to use the add_theme_page() function to add the Theme Settings Page to the Appearance menu, rather than using add_menu_page() to add a top-level menu.
- Themes are required to use the edit_theme_options capability for add_theme_page(), rather than rely on a role (e.g. “administrator”), or a different capability (e.g. “edit_themes”, “manage_options”) for the capability to add the settings page.
- Themes are required to save options in a single array, rather than create multiple options for its settings page. Use of set_theme_mod and get_theme_mod handles this for you, as does using the Settings API.
- Themes are required to validate and sanitize all untrusted data before entering data into the database, and to escape all untrusted data before being output in the Settings form fields or in the Theme template files. See Data Validation Part I, Part II, and WP codex
- Themes are recommended to use the Settings API to get and save form input data rather than rely on $_POST and $_REQUEST data directly.
- No core WordPress functions introduced prior to one previous, major WordPress release are wrapped in function_exists() conditionals.
- Use Theme Unit Tests Data and check your theme.
- Download test data.
- Import test data into your WordPress install. Do this by going to Tools -> Import.
- Check all the layout test, Menu Test (Long and Short Menu) HTML Elemets, Image Test, Embed Test, Site Title Test (Add in Long Site Tile for testing), Pagination and so on. Read More »