Theme Settings and Data Security
- 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.
- For checkboxes and select options, Themes are required to use the checked() and selected() functions for outputtingchecked=”checked” and selected=”selected”, respectively.
- Themes are required to prefix all options, custom functions, custom variables, and custom constants with theme-slug (or appropriate variant).
- Themes are required to implement Theme Options and Theme Settings pages deliberately, rather than relying on copy-and-paste scripts from website tutorials.
- 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)
- Themes are required to use esc_attr() for text inputs and esc_html() (or esc_textarea() in WP 3.1) for textareas.
- Themes are required to provide explicit Settings-page nonce checking, if not using the Settings API (see: WordPress Nonces)
- Themes must not “phone home” without informed user consent:
- Themes are required to implement any collection of user data as OPT-IN; that is, via user-configurable Theme option, disabled by default.
- Themes are required to include within the Theme all images, scripts, and other bundled resources. Such resources must notbe “hotlinked” from a third-party site.
- Note: API calls, e.g. Google libraries, are acceptable.