Introduction
WordPress powers a significant portion of the web, making plugin development an essential skill for extending website functionality. However, developing a plugin involves more than simply writing code that works. To ensure maintainability, security, scalability, and compatibility, developers must follow established WordPress coding standards and best practices.
This document outlines the standards our development team should follow while building WordPress plugins.
1. Follow WordPress Coding Standards
Always adhere to the official WordPress Coding Standards.
PHP Standards
- Use tabs for indentation.
- Use meaningful variable and function names.
- Follow WordPress naming conventions.
- Avoid short and ambiguous variable names.
Good Example:
$user_id = get_current_user_id();Avoid:
$uid = get_current_user_id();
JavaScript Standards
- Follow WordPress JavaScript Coding Standards.
- Use ES6+ features when appropriate.
SCSS & CSS Standards
- Declare the variable, so easy to extend values in theme
- Use meaning full Variable name.
- Use the core classes names used to wordpress to maintain the core design.
2. Plugin Structure
Maintain a clean and organized directory structure.
3. Security Best Practices
Sanitize Input
Always sanitize the input fields.
$name = sanitize_text_field( $_POST['name'] ); Escape Output
Always escape data before displaying. If not then HTML content will be considered as a string.
echo esc_html( $name );
Verify Nonces
Verify the nounce during the form submissions or during AJAX requests.
wp_verify_nonce( $nonce, 'save_data' );4. Internationalization (i18n)
For basic strings (meaning strings without placeholders or plurals) use __(). It returns the translation of its argument:
Example :
__( 'Settings', 'my-plugin' );Remember : Do not use variable names or constants for the text domain portion of a gettext function. For example: Do not do this as a shortcut:
__( ‘Translate me.’ , $text_domain );
For more reference visit :
https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/
5. Database Operations
Use WordPress APIs
Prefer WordPress APIs over custom SQL queries whenever possible.
Wrong Way :
global $wpdb;
$results = $wpdb->get_results("SELECT * FROM {$wpdb->posts} WHERE post_type = 'post' AND post_status = 'publish' ORDER BY post_date DESC LIMIT 5");Right way :
$args = array(
'post_type' => 'post',
'posts_per_page' => 5,
'post_status' => 'publish'
);
$query = new WP_Query($args);
6. Create and Use Hooks Properly
Hence the wordpress is hook driven add a new hooks in your plugin where a important action takes place. Always use the wordpress default hooks and filters to extend the functions.
7. Namespacing and Prefixing
To avoid the naming conflicts with other plugins and themes use a specific names, it also helps in code organization and maintainability.
Prefix :
function mdy_register_settings() { }Namespace :
namespace Mandy\Post_Card;8. Object-Oriented Programming
It is better to use the OOPS concepts in the plugin development because it will be easy to extend the functionalities(reuseability) and keep the code clean and organised.
9. Gutenberg Block Development Standards
When we are in block based plugin development it is easy and better to start the plugin setup with the cmd
npx @wordpress/create-block@block-nameThis will install all the dependencies needed initially and the block is created, we can start the block edits straightly.
Points to remember :
- Always use block.json.
- Register assets through block metadata.
- Follow React best practices.
- Avoid rerenders.
For more Detail visit :
https://developer.wordpress.org/block-editor/reference-guides/packages/packages-create-block/
10. Plugin Versioning and Release Management
Every plugin release should follow a consistent versioning strategy. This makes it easier for developers and site administrators to identify the type of change included in a release and safely manage updates.
| Versions | Exapmles |
|---|---|
| Major | 1.0.0 → 2.0.0 |
| Minor | 1.2.0 → 1.3.0 |
| Patch | 1.3.0 → 1.3.1 |
Major Release :
Increment the major version when the plugin introduces breaking changes.
- Removing an existing functionality or public API’s.
- Introducing any functionality that needs manual configuration.
Minor Release :
Increment the minor version when adding functionality without breaking existing functionality.
- Adding new features or new API endpoints..
- Adding a new backend fields, or supporting fields that doesn’t break the function.
Patch Release :
Increment the patch version for backward-compatible fixes.
- Bug fixes, Security fixes or Performance improvements.
- Small UI corrections.
Maintain a Single Plugin Version
If the plugin uses a constant, keep the version in one central location, Avoid maintaining different versions manually across multiple files.
/**
* Plugin Name: My Plugin
* Version: 1.4.2
* Text Domain: my-plugin
*/Git Tags
Every production release should have a corresponding Git tag. The Git tag should point to the exact commit that was released to production.
Example : v1.4.0 , v1.4.1
Changelog Management
Every plugin release should have a corresponding changelog entry in the CHANGELOG.md file, which should be updated with each release and focused on changes relevant to developers, administrators, and users.
11. Documentation
Every plugin should contain:
- README.md and readme.txt
- Installation instructions (on the readme File)
- Changelog
- Inline code documentation
readme.txt is the mandatory file used by WordPress.org to generate your plugin’s public directory listing and README.md is an optional file primarily used for developer documentation on Repositories.
12. Testing Checklist
Functional Testing
Check all the functions are working correctly during the specific actions.
- Plugin activation.
- Plugin deactivation.
- Plugin uninstall.
Compatibility Testing
- Latest WordPress version.
- Supported PHP versions.
- Theme compatibility.
- WooCommerce compatibility (if applicable).
