WordPress Plugin Development Guide Archives - Developry Plugins

WordPress Plugin Development from Scratch: Complete Beginner’s Guide

Krasen Slavov — Fri, 30 Jan 2026 09:00:00 +0000

WordPress plugin development opens endless possibilities for extending WordPress functionality. This beginner-friendly guide teaches you to build your first plugin from scratch, even if you’ve never written PHP code before. You’ll learn fundamental concepts, best practices, and create a functioning plugin by the end.

What Are WordPress Plugins?

Plugins are PHP files that extend WordPress core functionality without modifying core files. They add features, modify behavior, and integrate services. WordPress’s extensive plugin API provides hooks and functions that let you tap into WordPress at precise moments during execution.

Understanding this principle is crucial: never modify WordPress core. Always build plugins (or themes) to add functionality. This keeps your changes upgrade-safe and maintainable.

Prerequisites and Setup

Before starting, ensure you have:

Basic PHP knowledge – Understand variables, functions, arrays
HTML/CSS basics – Know how to structure and style content
Local development environment – LocalWP, MAMP, or Docker
Code editor – VS Code, PhpStorm, or Sublime Text

Install LocalWP for the easiest local WordPress setup. It handles server configuration, making development straightforward for beginners.

Your First Plugin File

Create a new folder in wp-content/plugins/ named my-first-plugin. Inside, create my-first-plugin.php:


/**
 * Plugin Name: My First Plugin
 * Plugin URI: https://example.com/my-first-plugin
 * Description: A simple plugin to learn WordPress development
 * Version: 1.0.0
 * Author: Your Name
 * Author URI: https://example.com
 * License: GPL v2 or later
 * License URI: https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain: my-first-plugin
 * Domain Path: /languages
 */

// If this file is called directly, abort.
if ( ! defined( 'WPINC' ) ) {
    die;
}

The header comment tells WordPress about your plugin. Required fields are Plugin Name and Description. The security check prevents direct file access.

Navigate to Plugins in your WordPress admin. You’ll see “My First Plugin” listed. Click Activate.

Understanding WordPress Hooks

Hooks are WordPress’s event system. They allow your plugin to execute code at specific moments.

Actions let you run code at specific points:

function dprt_welcome_message() {
    echo 'Welcome to our site!
';
}
add_action( 'admin_notices', 'dprt_welcome_message' );

This displays a message in the WordPress admin when the admin_notices action fires.

Filters let you modify data:

function dprt_modify_excerpt_length( $length ) {
    return 30;
}
add_filter( 'excerpt_length', 'dprt_modify_excerpt_length' );

This changes excerpt length to 30 words by filtering the default value.

Common Hooks for Beginners

Start with these essential hooks:

init – Fires after WordPress finishes loading. Use it for registering post types, taxonomies, and initialization:

function dprt_init_plugin() {
    // Register custom post types, taxonomies, etc.
}
add_action( 'init', 'dprt_init_plugin' );

wp_enqueue_scripts – Load CSS and JavaScript for frontend:

function dprt_enqueue_assets() {
    wp_enqueue_style(
        'dprt-styles',
        plugin_dir_url( __FILE__ ) . 'assets/css/style.css',
        array(),
        '1.0.0'
    );

    wp_enqueue_script(
        'dprt-scripts',
        plugin_dir_url( __FILE__ ) . 'assets/js/script.js',
        array( 'jquery' ),
        '1.0.0',
        true
    );
}
add_action( 'wp_enqueue_scripts', 'dprt_enqueue_assets' );

admin_menu – Add admin menu pages:

function dprt_add_menu_page() {
    add_menu_page(
        'My Plugin Settings',  // Page title
        'My Plugin',           // Menu title
        'manage_options',      // Capability required
        'my-plugin',           // Menu slug
        'dprt_settings_page',  // Function to display page
        'dashicons-admin-generic', // Icon
        20                     // Position
    );
}
add_action( 'admin_menu', 'dprt_add_menu_page' );

function dprt_settings_page() {
    echo '';
    echo 'My Plugin Settings
';
    echo 'Settings page content goes here.
';
    echo '
';
}

Plugin Activation and Deactivation

Run code when plugins activate or deactivate:

function dprt_activate_plugin() {
    // Set default options
    add_option( 'dprt_welcome_message', 'Welcome to our site!' );

    // Create custom database tables if needed
    // Flush rewrite rules if registering custom post types
    flush_rewrite_rules();
}
register_activation_hook( __FILE__, 'dprt_activate_plugin' );

function dprt_deactivate_plugin() {
    // Clean up temporary data
    // Flush rewrite rules
    flush_rewrite_rules();

    // Don't delete user data on deactivation
    // Save that for uninstall
}
register_deactivation_hook( __FILE__, 'dprt_deactivate_plugin' );

Never delete user data on deactivation. Users might temporarily deactivate to troubleshoot. Save deletion for uninstall.

The Options API

Store plugin settings using the Options API:

// Save option
update_option( 'dprt_setting_name', 'value' );

// Get option
$setting = get_option( 'dprt_setting_name', 'default value' );

// Delete option
delete_option( 'dprt_setting_name' );

Options are stored in the wp_options table. Use them for plugin configuration, user preferences, and cached data.

Plugin Security Basics

Security is paramount. Follow these practices from day one:

Sanitize input – Clean data users provide:

$user_input = sanitize_text_field( $_POST['input_field'] );
$email = sanitize_email( $_POST['email_field'] );

Escape output – Prevent XSS attacks:

echo '' . esc_html( $user_data ) . '
';
echo '( $link ) . '">Link';

Use nonces – Verify form submissions:

// Create nonce
wp_nonce_field( 'dprt_save_settings', 'dprt_settings_nonce' );

// Verify nonce
if ( ! wp_verify_nonce( $_POST['dprt_settings_nonce'], 'dprt_save_settings' ) ) {
    wp_die( 'Security check failed' );
}

Check capabilities – Ensure users have permission:

if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( 'Unauthorized access' );
}

Organizing Plugin Files

As plugins grow, organize code across multiple files:

my-first-plugin/
├── my-first-plugin.php    (Main file)
├── includes/
│   ├── class-admin.php
│   ├── class-frontend.php
│   └── functions.php
├── assets/
│   ├── css/
│   │   └── style.css
│   └── js/
│       └── script.js
└── languages/

Include files in your main plugin file:

require_once plugin_dir_path( __FILE__ ) . 'includes/functions.php';
require_once plugin_dir_path( __FILE__ ) . 'includes/class-admin.php';

Debugging Your Plugin

Enable WordPress debugging in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Log debug messages:

error_log( 'Debug message: ' . print_r( $variable, true ) );

Check /wp-content/debug.log for logged errors.

Building a Complete Example Plugin

Let’s build a simple quote display plugin:


/**
 * Plugin Name: Simple Quote Display
 * Description: Display random quotes on your site
 * Version: 1.0.0
 */

if ( ! defined( 'WPINC' ) ) {
    die;
}

// Add admin menu
function sqd_add_menu() {
    add_menu_page(
        'Quotes',
        'Quotes',
        'manage_options',
        'sqd-quotes',
        'sqd_quotes_page',
        'dashicons-format-quote'
    );
}
add_action( 'admin_menu', 'sqd_add_menu' );

// Admin page
function sqd_quotes_page() {
    if ( isset( $_POST['sqd_add_quote'] ) ) {
        if ( ! wp_verify_nonce( $_POST['sqd_nonce'], 'sqd_add_quote' ) ) {
            wp_die( 'Security check failed' );
        }

        $quote = sanitize_textarea_field( $_POST['quote'] );
        $quotes = get_option( 'sqd_quotes', array() );
        $quotes[] = $quote;
        update_option( 'sqd_quotes', $quotes );
    }

    $quotes = get_option( 'sqd_quotes', array() );
    ?>
    class="wrap">
        Manage Quotes
        "post">
            <?php wp_nonce_field( 'sqd_add_quote', 'sqd_nonce' ); ?>
            "quote"</span> rows=<span class="st">"3"</span> cols=<span class="st">"50"</span>>
            "submit" name="sqd_add_quote" value="Add Quote" class="button button-primary">
        
        Existing Quotes
        
            <?php foreach ( $quotes as $quote ) : ?>
                <?php echo esc_html( $quote ); ?>
            <?php endforeach; ?>
        
    
    <?php
}

// Shortcode to display random quote
function sqd_display_quote() {
    $quotes = get_option( 'sqd_quotes', array() );
    if ( empty( $quotes ) ) {
        return '';
    }
    $random_quote = $quotes[ array_rand( $quotes ) ];
    return '' . esc_html( $random_quote ) . '
';
}
add_shortcode( 'random_quote', 'sqd_display_quote' );

This complete plugin adds quotes via admin, stores them, and displays them with [random_quote] shortcode.

Common Beginner Mistakes

Avoid these pitfalls:

Not using prefixes – Prefix all functions to avoid conflicts
Forgetting security – Always sanitize, escape, and verify
Ignoring WordPress functions – Use WordPress APIs instead of raw PHP/SQL
Not testing – Test across WordPress versions and with other plugins
Poor error handling – Anticipate failures and handle gracefully

Next Steps

After mastering basics:

Study the Plugin Handbook thoroughly
Explore the Settings API for complex settings pages
Learn custom post types and taxonomies
Understand the REST API for modern integrations
Study established plugins’ code on GitHub

Conclusion

WordPress plugin development is accessible to beginners willing to learn. Start with simple plugins, follow security best practices, use WordPress APIs, and gradually build complexity. Your first plugin might be basic, but it establishes the foundation for building sophisticated WordPress extensions.

External Links

Call to Action

Supercharge your development! ACF Copilot Pro generates ACF field groups with AI, exports to PHP, and accelerates custom field workflows—try it free!

The post WordPress Plugin Development from Scratch: Complete Beginner’s Guide appeared first on Developry Plugins.

WordPress Plugin Internationalization: Making Plugins Translation-Ready

Krasen Slavov — Sun, 25 Jan 2026 09:00:00 +0000

Making your WordPress plugin available in multiple languages opens doors to a global audience. Internationalization (i18n) prepares your code for translation, while localization (l10n) provides the actual translations. Let’s make your plugin speak every language.

Understanding i18n vs l10n

Internationalization (i18n): The process of preparing your plugin code to support multiple languages. This involves wrapping all user-facing strings in translation functions.

Localization (l10n): The process of translating those strings into specific languages. Translators can work on l10n without touching your code.

The “18” in i18n represents the 18 letters between “i” and “n” in internationalization. Similarly, l10n has 10 letters between “l” and “n”.

Setting Up Your Text Domain

Every plugin needs a unique text domain identifier. Define it in your plugin header:

/**
 * Plugin Name: My Awesome Plugin
 * Text Domain: my-awesome-plugin
 * Domain Path: /languages
 */

The text domain should match your plugin slug. Load translations in your main plugin file:

function myplugin_load_textdomain() {
    load_plugin_textdomain(
        'my-awesome-plugin',
        false,
        dirname(plugin_basename(__FILE__)) . '/languages'
    );
}
add_action('plugins_loaded', 'myplugin_load_textdomain');

This tells WordPress where to find translation files for your plugin.

Translation Functions

WordPress provides several functions for marking strings as translatable:

Basic Translation:

// Returns translated string
$text = __('Hello World', 'my-awesome-plugin');

// Echoes translated string
_e('Welcome to my plugin', 'my-awesome-plugin');

Translation with Context:

Use context when the same word might need different translations:

// "Post" as in a blog post
$label = _x('Post', 'noun', 'my-awesome-plugin');

// "Post" as in submit button
$button = _x('Post', 'verb', 'my-awesome-plugin');

Plural Forms:

Different languages handle plurals differently. Never hardcode plural logic:

// Wrong approach
$text = $count . ' item';
if ($count != 1) {
    $text .= 's';
}

// Correct approach
$text = sprintf(
    _n('%d item', '%d items', $count, 'my-awesome-plugin'),
    $count
);

Plural with Context:

$text = sprintf(
    _nx('%d product', '%d products', $count, 'e-commerce', 'my-awesome-plugin'),
    $count
);

Escaped Translation Functions

Always escape output for security. WordPress combines translation and escaping:

// For HTML content
echo esc_html__('Plugin Settings', 'my-awesome-plugin');
esc_html_e('Save Changes', 'my-awesome-plugin');

// For HTML attributes
$title = esc_attr__('Click to expand', 'my-awesome-plugin');
echo '('Help text', 'my-awesome-plugin') . '">';

// With context
$label = esc_html_x('Post', 'noun', 'my-awesome-plugin');

// For admin pages
echo '' . esc_html__('Dashboard', 'my-awesome-plugin') . '
';

Translating Dynamic Content

Use placeholders for variable content:

// Single placeholder
$message = sprintf(
    __('Welcome, %s!', 'my-awesome-plugin'),
    $user_name
);

// Multiple placeholders with ordering
$message = sprintf(
    __('You have %1$d new messages and %2$d notifications', 'my-awesome-plugin'),
    $message_count,
    $notification_count
);

// Named placeholders (WordPress 5.5+)
$message = sprintf(
    __('Hello %(name)s, you have %(count)d messages', 'my-awesome-plugin'),
    array(
        'name' => $user_name,
        'count' => $message_count
    )
);

Translator Comments

Provide context for translators using special comments:

/* translators: %s: user display name */
$greeting = sprintf(__('Welcome back, %s', 'my-awesome-plugin'), $name);

/* translators: 1: number of posts, 2: post type name */
$status = sprintf(
    __('Found %1$d %2$s', 'my-awesome-plugin'),
    $count,
    $post_type
);

These comments appear in translation files, helping translators understand context.

Avoiding Common Mistakes

Never concatenate translatable strings:

// Wrong - breaks translation
echo __('Click', 'my-awesome-plugin') . ' ' .
     '' . __('here', 'my-awesome-plugin') . '';

// Correct - translatable as complete phrase
printf(
    __('Click here', 'my-awesome-plugin')
);

Don’t split sentences:

// Wrong
echo __('Total:', 'my-awesome-plugin') . ' ' . $count;

// Correct
printf(__('Total: %d', 'my-awesome-plugin'), $count);

Avoid hardcoded HTML in translations:

// Wrong
__('Important: Save your work', 'my-awesome-plugin');

// Better - allows translator to reorder
sprintf(
    __('%sImportant:%s Save your work', 'my-awesome-plugin'),
    '',
    ''
);

Creating POT Files

POT (Portable Object Template) files contain all translatable strings from your plugin. Generate them using WP-CLI:

wp i18n make-pot . languages/my-awesome-plugin.pot

Or use Poedit to scan your plugin directory. The POT file serves as the template for all language translations.

Translation File Structure

Organize translation files in a languages/ directory:

my-awesome-plugin/
├── languages/
│   ├── my-awesome-plugin.pot        (template)
│   ├── my-awesome-plugin-es_ES.po   (Spanish - editable)
│   ├── my-awesome-plugin-es_ES.mo   (Spanish - compiled)
│   ├── my-awesome-plugin-fr_FR.po   (French - editable)
│   └── my-awesome-plugin-fr_FR.mo   (French - compiled)

PO files contain the actual translations. MO files are compiled binary versions that WordPress loads.

Creating Translations with Poedit

Open Poedit and select “Create New Translation”
Choose your POT file as the source
Select target language
Translate strings in the interface
Save as .po file (Poedit auto-generates .mo)

Poedit provides context from translator comments and shows source code references.

JavaScript Internationalization

Translate strings in JavaScript files:

// Enqueue script and make it translatable
function myplugin_enqueue_scripts() {
    wp_enqueue_script(
        'myplugin-frontend',
        plugins_url('js/frontend.js', __FILE__),
        array('jquery'),
        '1.0',
        true
    );

    wp_set_script_translations(
        'myplugin-frontend',
        'my-awesome-plugin',
        plugin_dir_path(__FILE__) . 'languages'
    );
}
add_action('wp_enqueue_scripts', 'myplugin_enqueue_scripts');

In your JavaScript file:

const { __ } = wp.i18n;

// Simple translation
const message = __("Click to continue", "my-awesome-plugin");

// With sprintf
const greeting = sprintf(__("Welcome, %s!", "my-awesome-plugin"), userName);

Generate JSON files for JavaScript translations:

wp i18n make-json languages --no-purge

Date and Time Localization

Use WordPress date functions for proper localization:

// WordPress handles localization automatically
echo date_i18n(get_option('date_format'), strtotime($date));

// Time format
echo date_i18n(get_option('time_format'), current_time('timestamp'));

// Custom format
echo date_i18n('F j, Y', strtotime($date));

Number Formatting

Use number_format_i18n() for locale-aware number formatting:

// Formats according to user's locale
echo number_format_i18n(1234.56); // 1,234.56 in English, 1.234,56 in German

// With specific decimals
echo number_format_i18n(1234.56789, 2); // 1,234.57

RTL Language Support

Add RTL stylesheet support for languages like Arabic and Hebrew:

function myplugin_enqueue_styles() {
    wp_enqueue_style('myplugin-style',
        plugins_url('css/style.css', __FILE__));

    // Load RTL stylesheet if needed
    if (is_rtl()) {
        wp_enqueue_style('myplugin-rtl',
            plugins_url('css/rtl.css', __FILE__));
    }
}
add_action('wp_enqueue_scripts', 'myplugin_enqueue_styles');

Or use automatic RTL generation:

wp_style_add_data('myplugin-style', 'rtl', 'replace');

Testing Translations

Test your plugin in different languages:

Change WordPress language in Settings > General
Install a language pack from Settings > General
Use a plugin like Loco Translate for quick testing
Verify all strings are translatable
Check RTL layout if supporting those languages

WordPress.org Translation Platform

For plugins hosted on WordPress.org:

Submit your plugin with POT file included
Translators use translate.wordpress.org
Language packs are automatically generated
Users receive translations through WordPress updates

Contributors can help translate at: https://translate.wordpress.org/projects/wp-plugins/your-plugin-slug

Translation Workflow Best Practices

During Development:

Wrap all user-facing strings immediately
Use consistent text domain throughout
Add translator comments for context
Never use variables as text domain

Before Release:

Generate POT file
Test with at least one translation
Verify all strings are translatable
Check for missing text domains

After Release:

Update POT file with each version
Notify translators of new strings
Keep existing string IDs stable
Provide context for new additions

Performance Considerations

Translation loading has minimal performance impact when done correctly:

// Load translations only when needed
if (is_admin()) {
    load_plugin_textdomain('my-awesome-plugin', false, dirname(plugin_basename(__FILE__)) . '/languages');
}

// Cache expensive translations
$translated = wp_cache_get('myplugin_cached_string', 'myplugin');
if (false === $translated) {
    $translated = __('Expensive string', 'my-awesome-plugin');
    wp_cache_set('myplugin_cached_string', $translated, 'myplugin', HOUR_IN_SECONDS);
}

Complete Example

Here’s a complete translatable plugin snippet:

function myplugin_display_stats($user_id) {
    $posts = count_user_posts($user_id);
    $comments = get_comments(array('user_id' => $user_id, 'count' => true));

    $output = '';

    /* translators: %s: user display name */
    $output .= '' . sprintf(
        esc_html__('Statistics for %s', 'my-awesome-plugin'),
        get_userdata($user_id)->display_name
    ) . '
';

    /* translators: %d: number of posts */
    $output .= '' . sprintf(
        esc_html(_n('%d post published', '%d posts published', $posts, 'my-awesome-plugin')),
        number_format_i18n($posts)
    ) . '
';

    /* translators: %d: number of comments */
    $output .= '' . sprintf(
        esc_html(_n('%d comment written', '%d comments written', $comments, 'my-awesome-plugin')),
        number_format_i18n($comments)
    ) . '
';

    $output .= '
';

    return $output;
}

Internationalization ensures your plugin reaches users worldwide. With proper i18n implementation, translators can easily localize your plugin without modifying a single line of code.

External Links

Call to Action

Supercharge your development! ACF Copilot Pro generates ACF field groups with AI, exports to PHP, and accelerates custom field workflows—try it free!

The post WordPress Plugin Internationalization: Making Plugins Translation-Ready appeared first on Developry Plugins.

WordPress Plugin Security Best Practices: Prevent Common Vulnerabilities

Krasen Slavov — Tue, 20 Jan 2026 09:00:00 +0000

Plugin security vulnerabilities endanger millions of WordPress sites. As a plugin developer, you’re responsible for protecting user data, preventing attacks, and maintaining WordPress ecosystem trust. This guide covers essential security practices every plugin developer must follow.

Why Plugin Security Matters

WordPress powers 43% of websites globally. Attackers target plugins because:

Plugins often handle sensitive data
Security vulnerabilities affect thousands of sites using the same plugin
Poorly coded plugins provide entry points to otherwise secure sites
Plugin vulnerabilities appear in major security databases

A single SQL injection vulnerability in your plugin could compromise thousands of WordPress installations. Security isn’t optional—it’s your primary responsibility as a developer.

Cross-Site Scripting (XSS) Prevention

XSS attacks inject malicious JavaScript into pages, stealing cookies, redirecting users, or modifying content.

Always escape output:

// HTML context
echo '' . esc_html( $user_input ) . '
';

// Attribute context
echo '( $class_name ) . '">';

// URL context
echo '( $link ) . '">Link';

// JavaScript context
echo '';

Allow specific HTML with wp_kses():

$allowed_html = array(
    'a' => array(
        'href' => array(),
        'title' => array()
    ),
    'strong' => array(),
    'em' => array()
);
echo wp_kses( $user_content, $allowed_html );

Never output unescaped user data. Ever.

SQL Injection Prevention

SQL injection allows attackers to execute arbitrary database queries.

Always use prepared statements:

global $wpdb;

// WRONG - vulnerable to SQL injection
$user_id = $_GET['user_id'];
$results = $wpdb->get_results( "SELECT * FROM {$wpdb->users} WHERE ID = $user_id" );

// CORRECT - using prepare()
$user_id = intval( $_GET['user_id'] );
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->users} WHERE ID = %d",
        $user_id
    )
);

Placeholders for different data types:

// %d for integers
$wpdb->prepare( "SELECT * FROM table WHERE id = %d", $id );

// %s for strings
$wpdb->prepare( "SELECT * FROM table WHERE name = %s", $name );

// %f for floats
$wpdb->prepare( "SELECT * FROM table WHERE price = %f", $price );

// Multiple values
$wpdb->prepare(
    "SELECT * FROM table WHERE id = %d AND name = %s",
    $id,
    $name
);

Never concatenate variables into SQL queries.

CSRF Protection with Nonces

CSRF attacks trick users into executing unwanted actions.

Create nonces in forms:

"post">
    <?php wp_nonce_field( 'dprt_save_settings', 'dprt_nonce' ); ?>
    "text" name="setting_value">
    "submit" value="Save">

Verify nonces before processing:

if ( isset( $_POST['submit'] ) ) {
    if ( ! isset( $_POST['dprt_nonce'] ) || ! wp_verify_nonce( $_POST['dprt_nonce'], 'dprt_save_settings' ) ) {
        wp_die( 'Security check failed' );
    }

    // Process form data
}

For admin pages, use check_admin_referer():

check_admin_referer( 'dprt_save_settings', 'dprt_nonce' );

For AJAX:

// JavaScript
$.post( ajaxurl, {
    action: 'dprt_save',
    nonce: dprt_ajax.nonce,
    data: formData
});

// PHP
function dprt_ajax_save() {
    check_ajax_referer( 'dprt_ajax_nonce', 'nonce' );
    // Process request
}

Every form submission, AJAX request, and state-changing action requires nonce verification.

User Capability Checks

Verify users have permission before allowing actions:

// Check specific capability
if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( 'Unauthorized access' );
}

// Check for specific post
if ( ! current_user_can( 'edit_post', $post_id ) ) {
    wp_die( 'You cannot edit this post' );
}

// Check multiple capabilities
if ( ! current_user_can( 'edit_posts' ) && ! current_user_can( 'edit_pages' ) ) {
    return;
}

Common capabilities:

manage_options – Administrators only
edit_posts – Can edit posts
publish_posts – Can publish posts
edit_others_posts – Can edit posts by other users

Data Sanitization

Clean all user input before processing:

// Text fields
$text = sanitize_text_field( $_POST['text_field'] );

// Textareas
$content = sanitize_textarea_field( $_POST['content'] );

// Email addresses
$email = sanitize_email( $_POST['email'] );

// URLs
$url = esc_url_raw( $_POST['url'] );

// File names
$filename = sanitize_file_name( $_FILES['file']['name'] );

// HTML class names
$class = sanitize_html_class( $_POST['class'] );

// Keys
$key = sanitize_key( $_POST['key'] );

// Integers
$number = absint( $_POST['number'] );

Sanitize input, escape output. This principle prevents most vulnerabilities.

File Upload Security

File uploads are high-risk operations:

function dprt_handle_file_upload() {
    if ( ! isset( $_FILES['file'] ) ) {
        return;
    }

    // Verify nonce
    check_admin_referer( 'dprt_upload', 'nonce' );

    // Check capability
    if ( ! current_user_can( 'upload_files' ) ) {
        wp_die( 'Insufficient permissions' );
    }

    // Validate file type
    $allowed_types = array( 'image/jpeg', 'image/png', 'image/gif' );
    $file_type = $_FILES['file']['type'];

    if ( ! in_array( $file_type, $allowed_types ) ) {
        wp_die( 'Invalid file type' );
    }

    // Use WordPress upload handler
    $upload = wp_handle_upload(
        $_FILES['file'],
        array( 'test_form' => false )
    );

    if ( isset( $upload['error'] ) ) {
        wp_die( $upload['error'] );
    }

    // File uploaded successfully
    $file_url = $upload['url'];
}

Never trust uploaded files. Validate type, size, and content.

Preventing Direct File Access

Prevent users from accessing plugin files directly:


// At the top of every PHP file
if ( ! defined( 'ABSPATH' ) ) {
    exit; // Exit if accessed directly
}

This prevents attackers from executing PHP files outside WordPress context.

Secure AJAX Implementation

AJAX requests need the same security as form submissions:

// Enqueue script with nonce
function dprt_enqueue_ajax_script() {
    wp_enqueue_script( 'dprt-ajax', plugin_dir_url( __FILE__ ) . 'ajax.js', array( 'jquery' ) );
    wp_localize_script( 'dprt-ajax', 'dprtAjax', array(
        'ajaxurl' => admin_url( 'admin-ajax.php' ),
        'nonce' => wp_create_nonce( 'dprt_ajax' )
    ) );
}

// AJAX handler
function dprt_ajax_handler() {
    // Verify nonce
    check_ajax_referer( 'dprt_ajax', 'nonce' );

    // Check capabilities
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_send_json_error( 'Insufficient permissions' );
    }

    // Sanitize input
    $data = sanitize_text_field( $_POST['data'] );

    // Process and respond
    wp_send_json_success( array( 'result' => $processed_data ) );
}
add_action( 'wp_ajax_dprt_action', 'dprt_ajax_handler' );

Secure Configuration

Never hardcode sensitive information:

// BAD - hardcoded API key
$api_key = 'sk_live_123456789';

// GOOD - use constants or options
define( 'DPRT_API_KEY', 'sk_live_123456789' ); // In wp-config.php
$api_key = defined( 'DPRT_API_KEY' ) ? DPRT_API_KEY : get_option( 'dprt_api_key' );

Store sensitive data in wp-config.php or use environment variables.

Security Checklist

Before releasing your plugin:

Conclusion

Security isn’t a feature—it’s a requirement. Sanitize all input, escape all output, verify nonces, check capabilities, and use prepared statements. These practices protect users and maintain WordPress ecosystem trust. Make security your default mindset, not an afterthought.

Secure communication
Using HTTPS for API calls
SSL/TLS certificate validation
Third-party library security
Keeping dependencies updated
Vulnerability scanning tools
Security auditing and code review
Common security mistakes developers make
Security checklist for plugin release
Responsible disclosure of vulnerabilities

Includes code examples, security patterns, and testing procedures for building secure, trustworthy WordPress plugins.

External Links

Call to Action

Supercharge your development! ACF Copilot Pro generates ACF field groups with AI, exports to PHP, and accelerates custom field workflows—try it free!

The post WordPress Plugin Security Best Practices: Prevent Common Vulnerabilities appeared first on Developry Plugins.

WordPress Plugin Testing: PHPUnit and Automated Testing Guide

Krasen Slavov — Thu, 15 Jan 2026 09:00:00 +0000

Automated testing ensures your WordPress plugin works reliably across updates, prevents regressions, and gives you confidence to refactor code. PHPUnit combined with the WordPress test framework provides a robust solution for testing plugin functionality.

Why Test WordPress Plugins

Manual testing becomes impractical as plugins grow. Automated tests catch bugs before users do, document expected behavior, and enable safe refactoring. Tests save time in the long run by preventing regressions and reducing debugging sessions.

Well-tested plugins are more maintainable, easier to collaborate on, and inspire user confidence. Professional development includes comprehensive testing as a standard practice.

Understanding Test Types

Unit Tests: Test individual functions or methods in isolation. Fast to run and pinpoint specific issues.

Integration Tests: Test how components work together, including WordPress functions, database operations, and plugin interactions.

Acceptance Tests: Test complete user workflows from end to end. Slower but verify real-world usage.

For WordPress plugins, you’ll primarily write integration tests since most functionality interacts with WordPress core.

Setting Up PHPUnit for WordPress

Install PHPUnit and set up the WordPress test suite using WP-CLI:

# Navigate to your plugin directory
cd wp-content/plugins/my-plugin

# Generate test scaffolding
wp scaffold plugin-tests my-plugin

# Install test suite
bash bin/install-wp-tests.sh wordpress_test root '' localhost latest

This creates the necessary directory structure:

my-plugin/
├── bin/
│   └── install-wp-tests.sh
├── tests/
│   ├── bootstrap.php
│   └── test-sample.php
├── phpunit.xml.dist
└── .phpcs.xml.dist

Writing Your First Test

Create a test file in the tests/ directory:


class Test_MyPlugin_Functions extends WP_UnitTestCase {

    public function test_plugin_activated() {
        $this->assertTrue(is_plugin_active('my-plugin/my-plugin.php'));
    }

    public function test_custom_function_returns_expected_value() {
        $result = myplugin_get_greeting('John');
        $this->assertEquals('Hello, John!', $result);
    }

    public function test_custom_post_type_registered() {
        $this->assertTrue(post_type_exists('myplugin_item'));
    }
}

Run tests from your plugin directory:

phpunit

PHPUnit Assertions

Common assertions for testing WordPress plugins:

// Equality
$this->assertEquals($expected, $actual);
$this->assertSame($expected, $actual); // Strict comparison

// Boolean
$this->assertTrue($condition);
$this->assertFalse($condition);

// Null and Empty
$this->assertNull($value);
$this->assertEmpty($array);
$this->assertNotEmpty($array);

// Arrays and Strings
$this->assertContains('needle', $haystack);
$this->assertCount(5, $array);
$this->assertStringContainsString('word', $string);

// Instances and Types
$this->assertInstanceOf(WP_Post::class, $post);
$this->assertIsArray($value);
$this->assertIsString($value);

// WordPress-specific
$this->assertWPError($result);
$this->assertNotWPError($result);

Testing WordPress Functions

Test interactions with WordPress core:

class Test_Post_Functions extends WP_UnitTestCase {

    public function test_create_custom_post() {
        $post_id = wp_insert_post(array(
            'post_title' => 'Test Post',
            'post_type' => 'myplugin_item',
            'post_status' => 'publish'
        ));

        $this->assertGreaterThan(0, $post_id);
        $this->assertEquals('myplugin_item', get_post_type($post_id));
    }

    public function test_post_meta_saved_correctly() {
        $post_id = $this->factory()->post->create();

        add_post_meta($post_id, '_myplugin_rating', 4.5);

        $rating = get_post_meta($post_id, '_myplugin_rating', true);
        $this->assertEquals(4.5, $rating);
    }
}

Using Factories for Test Data

WordPress test framework includes factories for generating test data:

class Test_With_Factories extends WP_UnitTestCase {

    public function test_user_can_edit_own_post() {
        // Create test user
        $user_id = $this->factory()->user->create(array(
            'role' => 'author'
        ));

        // Create test post owned by user
        $post_id = $this->factory()->post->create(array(
            'post_author' => $user_id
        ));

        wp_set_current_user($user_id);

        $this->assertTrue(current_user_can('edit_post', $post_id));
    }

    public function test_category_assignment() {
        $category_id = $this->factory()->category->create(array(
            'name' => 'Test Category'
        ));

        $post_id = $this->factory()->post->create();

        wp_set_post_categories($post_id, array($category_id));

        $categories = wp_get_post_categories($post_id);
        $this->assertContains($category_id, $categories);
    }
}

Available factories:

$this->factory()->post – Posts
$this->factory()->user – Users
$this->factory()->comment – Comments
$this->factory()->term – Terms
$this->factory()->category – Categories
$this->factory()->tag – Tags

setUp() and tearDown() Methods

Prepare test environment before each test and clean up after:

class Test_With_Setup extends WP_UnitTestCase {

    protected $plugin;
    protected $test_post_id;

    public function setUp(): void {
        parent::setUp();

        // Runs before each test
        $this->plugin = new MyPlugin();
        $this->test_post_id = $this->factory()->post->create();
    }

    public function tearDown(): void {
        // Runs after each test
        wp_delete_post($this->test_post_id, true);
        unset($this->plugin);

        parent::tearDown();
    }

    public function test_plugin_initialized() {
        $this->assertInstanceOf(MyPlugin::class, $this->plugin);
    }

    public function test_post_exists() {
        $this->assertNotNull(get_post($this->test_post_id));
    }
}

Testing Hooks and Filters

Verify actions and filters execute correctly:

class Test_Hooks extends WP_UnitTestCase {

    public function test_action_adds_meta_box() {
        global $wp_meta_boxes;

        do_action('add_meta_boxes');

        $this->assertArrayHasKey('myplugin_meta_box',
            $wp_meta_boxes['post']['normal']['high']);
    }

    public function test_filter_modifies_title() {
        add_filter('the_title', 'myplugin_modify_title');

        $post_id = $this->factory()->post->create(array(
            'post_title' => 'Original Title'
        ));

        $title = apply_filters('the_title', get_the_title($post_id));

        $this->assertStringContainsString('Modified', $title);
    }

    public function test_custom_filter_value() {
        $value = apply_filters('myplugin_custom_filter', 10);

        // Default value
        $this->assertEquals(10, $value);

        // Add filter
        add_filter('myplugin_custom_filter', function($val) {
            return $val * 2;
        });

        $filtered_value = apply_filters('myplugin_custom_filter', 10);
        $this->assertEquals(20, $filtered_value);
    }
}

Testing AJAX Functionality

Test AJAX handlers using WordPress test helpers:

class Test_AJAX extends WP_Ajax_UnitTestCase {

    public function test_ajax_like_post() {
        $post_id = $this->factory()->post->create();

        $_POST['action'] = 'myplugin_like_post';
        $_POST['post_id'] = $post_id;
        $_POST['nonce'] = wp_create_nonce('myplugin_like_nonce');

        try {
            $this->_handleAjax('myplugin_like_post');
        } catch (WPAjaxDieContinueException $e) {
            // Expected exception
        }

        $response = json_decode($this->_last_response);

        $this->assertTrue($response->success);
        $this->assertEquals(1, $response->data->likes);
    }
}

Testing Database Operations

Test custom database tables and queries:

class Test_Database extends WP_UnitTestCase {

    public function test_custom_table_created() {
        global $wpdb;

        myplugin_create_custom_table();

        $table_name = $wpdb->prefix . 'myplugin_data';
        $this->assertEquals($table_name,
            $wpdb->get_var("SHOW TABLES LIKE '$table_name'"));
    }

    public function test_insert_custom_data() {
        global $wpdb;

        $table_name = $wpdb->prefix . 'myplugin_data';

        $result = $wpdb->insert($table_name, array(
            'name' => 'Test Item',
            'value' => 100
        ));

        $this->assertNotFalse($result);
        $this->assertEquals(1, $wpdb->insert_id);
    }
}

Mocking External API Calls

Use pre_http_request filter to mock external APIs:

class Test_External_API extends WP_UnitTestCase {

    public function test_api_call_returns_data() {
        // Mock the HTTP request
        add_filter('pre_http_request', function($response, $args, $url) {
            if (strpos($url, 'api.example.com') !== false) {
                return array(
                    'response' => array('code' => 200),
                    'body' => json_encode(array(
                        'status' => 'success',
                        'data' => array('value' => 42)
                    ))
                );
            }
            return $response;
        }, 10, 3);

        $result = myplugin_fetch_external_data();

        $this->assertEquals(42, $result['value']);
    }
}

Code Coverage Analysis

Generate code coverage reports to identify untested code:

phpunit --coverage-html coverage/

View the HTML report in coverage/index.html. Aim for at least 70% coverage for critical code paths.

Configure coverage in phpunit.xml:

 processUncoveredFiles="true">
    
         suffix=".php">./src
    
    
        ./vendor
        ./tests

Continuous Integration with GitHub Actions

Automate testing on every commit:

# .github/workflows/test.yml
name: PHPUnit Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        php: ["7.4", "8.0", "8.1"]
        wordpress: ["latest", "6.0"]

    steps:
      - uses: actions/checkout@v2

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php }}

      - name: Install dependencies
        run: composer install

      - name: Install WordPress Test Suite
        run: bash bin/install-wp-tests.sh wordpress_test root root localhost ${{ matrix.wordpress }}

      - name: Run PHPUnit
        run: phpunit

Test-Driven Development (TDD)

Follow the Red-Green-Refactor cycle:

Red: Write a failing test for new functionality
Green: Write minimal code to make the test pass
Refactor: Improve code while keeping tests green

Example TDD workflow:

// Step 1: Write failing test
public function test_calculate_discount() {
    $result = myplugin_calculate_discount(100, 10);
    $this->assertEquals(90, $result);
}

// Step 2: Implement function
function myplugin_calculate_discount($price, $discount) {
    return $price - $discount;
}

// Step 3: Refactor
function myplugin_calculate_discount($price, $discount_percent) {
    return $price * (1 - $discount_percent / 100);
}

Best Practices

Test Organization: Group related tests in classes. Use descriptive test method names that explain what’s being tested.

Independence: Each test should run independently. Don’t rely on test execution order or shared state.

Speed: Keep tests fast. Use transactions to roll back database changes automatically. Mock external dependencies.

Clarity: Write clear assertions with helpful failure messages. One logical assertion per test method.

Maintenance: Update tests alongside code changes. Treat test code with the same care as production code.

Automated testing transforms plugin development from reactive debugging to proactive quality assurance. Invest time in testing now to save exponentially more time later.

Why testing WordPress plugins matters
Types of tests: unit, integration, acceptance
Understanding PHPUnit testing framework
Installing PHPUnit for WordPress
WordPress core test suite setup
Creating test scaffolding with WP-CLI
wp scaffold plugin-tests command
Test directory structure
bootstrap.php configuration
Writing your first PHPUnit test
Test case classes extending WP_UnitTestCase
Test method naming conventions
Assertions in PHPUnit
assertEquals(), assertTrue(), assertFalse()
assertCount(), assertEmpty(), assertContains()
Testing WordPress functions and hooks
Testing actions and filters
Mock objects and method stubs
WordPress factory for test data
Creating test posts, users, and terms
setUp() and tearDown() methods
Database transactions in tests
Test fixtures and sample data
Testing AJAX functionality
Testing custom post types
Testing meta boxes and custom fields
Testing shortcodes
Testing widgets
Testing REST API endpoints
Testing database queries
Testing caching logic
Code coverage analysis
Generating coverage reports
Improving test coverage
Test-driven development (TDD) workflow
Writing tests before code
Red-Green-Refactor cycle
Continuous integration setup
GitHub Actions for WordPress testing
Travis CI configuration
GitLab CI/CD pipelines
Automated testing on pull requests
Testing multiple PHP versions
Testing multiple WordPress versions
Integration testing best practices
Mocking external API calls
Performance testing
Debugging failing tests
Common testing pitfalls
Real-world testing examples

Includes complete test examples, CI/CD configurations, and best practices for building reliable, well-tested WordPress plugins with comprehensive test coverage.

External Links

Call to Action

Supercharge your development! ACF Copilot Pro generates ACF field groups with AI, exports to PHP, and accelerates custom field workflows—try it free!

The post WordPress Plugin Testing: PHPUnit and Automated Testing Guide appeared first on Developry Plugins.

WordPress Plugin Development Guide Archives - Developry Plugins

WordPress Plugin Development from Scratch: Complete Beginner’s Guide

What Are WordPress Plugins?

Prerequisites and Setup

Your First Plugin File

Understanding WordPress Hooks

Common Hooks for Beginners

My Plugin Settings

Plugin Activation and Deactivation

The Options API

Plugin Security Basics

Organizing Plugin Files

Debugging Your Plugin

Building a Complete Example Plugin

Manage Quotes

Existing Quotes

Common Beginner Mistakes

Next Steps

Conclusion

External Links

Call to Action

WordPress Plugin Internationalization: Making Plugins Translation-Ready

Understanding i18n vs l10n

Setting Up Your Text Domain

Translation Functions

Escaped Translation Functions

' . esc_html__('Dashboard', 'my-awesome-plugin') . '

Translating Dynamic Content

Translator Comments

Avoiding Common Mistakes

Creating POT Files

Translation File Structure

Creating Translations with Poedit

JavaScript Internationalization

Date and Time Localization

Number Formatting

RTL Language Support

Testing Translations

WordPress.org Translation Platform

Translation Workflow Best Practices

Performance Considerations

Complete Example

' . sprintf( esc_html__('Statistics for %s', 'my-awesome-plugin'), get_userdata($user_id)->display_name ) . '

External Links

Call to Action

WordPress Plugin Security Best Practices: Prevent Common Vulnerabilities

Why Plugin Security Matters

Cross-Site Scripting (XSS) Prevention

SQL Injection Prevention

CSRF Protection with Nonces

User Capability Checks

Data Sanitization

File Upload Security

Preventing Direct File Access

Secure AJAX Implementation

Secure Configuration

Security Checklist

Conclusion

External Links

Call to Action

WordPress Plugin Testing: PHPUnit and Automated Testing Guide

Why Test WordPress Plugins

Understanding Test Types

Setting Up PHPUnit for WordPress

Writing Your First Test

PHPUnit Assertions

Testing WordPress Functions

Using Factories for Test Data

setUp() and tearDown() Methods

Testing Hooks and Filters

Testing AJAX Functionality

Testing Database Operations

Mocking External API Calls

Code Coverage Analysis

Continuous Integration with GitHub Actions

Test-Driven Development (TDD)

Best Practices

External Links

Call to Action