General
- Use comments everywhere. Any new developers should be able to know what the code is doing pretty quickly.
- Stay Current. Adhere to the latest version of WordPress standards and APIs.
- Use best practices as detailed at http://codex.wordpress.org/Writing_a_Plugin
- Test site with define(‘WP_DEBUG’, true); added to wp-config.php to view errors.
File Structure
- The following folders should exist to support the main plugin file:
- /js – all javascript
- /css – all style sheets
- /img – all images
- /inc – all PHP include files
- The root should contain at least:
- the plugin file (my-plugin.php)
- uninstall.php – all code to remove plugin and database entries
Plugin Coding Standards
- Use common PHP coding standards (see php.net).
- Use common WordPress coding standards (see codex.wordpress.org). Follow rules for quotes, indentation, spacing, etc. at http://codex.wordpress.org/WordPress_Coding_Standards
- Follow CSS coding standards at http://codex.wordpress.org/CSS_Coding_Standards
- Use common JavaScript and jQuery coding standards.
- Use jQuery for most common custom JavaScript unless it doesn’t make sense to do so or you are taking from existing working code.
- Use no-conflict mode: write jQuery( ) instead of $( ).
- Reference supporting files with the following syntax:
- plugins_url( ‘/css/my-plugin-css.css’ , __FILE__ )
- The plugin folder itself should never be referenced.
- When a file is needed only for the admin screen or the public site, only load the necessary files using the function is_admin().
- CSS and JS files should be loaded with the functions wp_enqueue_style and wp_enqueue_script.
- Separate the admin and public CSS and JS files and load theme only where needed using the actions wp_enqueue_scripts and admin_enqueue_scripts.
- Prefix all functions with a common abbreviation of the plugin.
- Example: pib_register_settings()
Database Reading and Updating
- Do not read or write from the database using SQL strings if there is a built-in WordPress API for doing so otherwise.
- Instead built-in WordPress functions in the Options API such as update_option, get_option, etc. should be used.
- If there is not an API for what is needed SQL strings can be used if all precations are taken (SQL injection attacks prevented, user input validated, etc.)
- Use arrays to store and retrieve options for performance. Example:
$options = array(
‘color’ => ‘red’,
‘fontsize’ => ‘120%’,
‘display_posts’ => 1,
‘display_pages’ => 0
);
update_option( ‘myplugin_options’, $options );
- Store booleans as 1 and 0 when using arrays (see example above). When retrieving they should be returned as true and false.
Plugin Options Screen (Settings Page)
- Get and update options using the Settings API if possible. See http://codex.wordpress.org/Settings_API
- Use the Options API functions such as get_option if needed along with the Settings API.
- Use the HTML and layout standards dictated for option screens.
- <div class=”wrap”> surrounding page html
- <h2> for title
- class=”updated” for update messages
- class=”error” for error messages
- Display update and error messages to the user after settings are saved.
References