How to Create a WordPress Plugin: Step-by-Step Guide

To create a WordPress plugin, start with one PHP file, add a valid plugin header, then attach your functionality to WordPress through hooks. From there, separate your logic into focused files, validate and sanitize inputs, escape output, use WordPress APIs instead of reinventing core behavior, and test the plugin on a staging site before distribution.

TL;DR: A WordPress plugin can be as simple as a single PHP file inside wp-content/plugins/your-plugin/. The safest development path is: define the feature, create the plugin folder and header, add hooks, build the feature with WordPress APIs, add security checks, test activation/deactivation, and package the folder as a ZIP.

Once your ZIP is ready, use the WordPress plugin installation guide to test the package through the dashboard, ZIP upload, SFTP, or WP-CLI.

Prefer a ready-made business plugin?

The Best Plugins for WordPress in One Bundle

View product

Explore WordPress-native tools before building from scratch

If your goal is CRM, project management, invoicing, support, or documentation, check whether an existing plugin already solves the workflow before committing to custom development.

Browse GrowthPlugins products

What is a WordPress plugin?

A WordPress plugin is code that extends or changes WordPress without editing WordPress core files. That separation matters because WordPress core is updated independently. Custom functionality should live in a plugin so updates do not overwrite your work.

If you want a broader primer before building, see what a WordPress plugin is and how plugins extend WordPress.

The official WordPress Plugin Developer Handbook recommends this plugin-based approach and provides the core development reference for headers, hooks, security, settings, privacy, and distribution.

What you need before you start

• A local or staging WordPress installation.
• Access to the site files through your local environment, SFTP, SSH, or hosting file manager.
• A code editor such as Visual Studio Code, PhpStorm, or another editor you are comfortable with.
• Basic PHP knowledge.
• A clear definition of what the plugin should and should not do.

Step 1: define the plugin’s job

Before writing code, describe the plugin in one sentence. For example: “Add a simple internal project status box to WordPress posts.” If the description needs five sentences, the first release is probably too broad.

Write down:

• The user who needs the feature.
• The screen or workflow where it appears.
• The data it reads or stores.
• The permissions required.
• What should happen on activation, deactivation, and uninstall.

Step 2: create the plugin folder and main PHP file

Inside your WordPress installation, open wp-content/plugins/ and create a directory for the plugin. Use a unique, lowercase slug with hyphens.

wp-content/
└── plugins/
    └── my-business-plugin/
        └── my-business-plugin.php

The official Plugin Basics documentation recommends keeping your plugin files together in a dedicated directory, even when the first version contains only one PHP file.

Step 3: add a valid plugin header

WordPress detects plugins through a specially formatted comment in the main PHP file. The minimum required field is the plugin name, although a real project should include useful metadata.

<?php
/**
 * Plugin Name: My Business Plugin
 * Description: Adds a simple business workflow to WordPress.
 * Version: 1.0.0
 * Author: Your Name
 * Text Domain: my-business-plugin
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

The current header fields and requirements are documented in the official Plugin Header Requirements.

Step 4: use hooks instead of editing WordPress core

WordPress plugins interact with the platform primarily through actions and filters. Actions let your plugin run code at defined points. Filters let your plugin modify a value before WordPress uses or displays it.

Simple action example

function my_business_plugin_register_assets() {
    wp_register_style(
        'my-business-plugin',
        plugins_url( 'assets/plugin.css', __FILE__ ),
        array(),
        '1.0.0'
    );
}
add_action( 'wp_enqueue_scripts', 'my_business_plugin_register_assets' );

Simple filter example

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

Do not change a site-wide behavior such as excerpt length unless that is genuinely the plugin’s intended responsibility. The example demonstrates the filter pattern; production behavior should remain tightly scoped.

Step 5: add activation, deactivation, and uninstall logic only when needed

Activation hooks are useful for one-time setup such as creating default options. Deactivation should usually clean temporary state rather than delete user data. Permanent deletion belongs in a deliberate uninstall routine.

function my_business_plugin_activate() {
    if ( false === get_option( 'my_business_plugin_version', false ) ) {
        add_option( 'my_business_plugin_version', '1.0.0' );
    }
}
register_activation_hook( __FILE__, 'my_business_plugin_activate' );

Avoid deleting business data automatically on deactivation. Site owners often deactivate plugins temporarily for debugging.

Step 6: store settings with WordPress APIs

For normal plugin settings, use WordPress APIs instead of building raw database queries. The Settings API provides a consistent structure for registering, validating, and displaying settings in the admin area.

Step 7: sanitize input, validate data, and escape output

Security is not a final polish step. It should be part of every form, request, and output path. WordPress’s plugin review guidance emphasizes three related practices: sanitize incoming values, validate that values are acceptable, and escape values when they are output.

The official Plugin Review common issues guide includes practical examples and also recommends processing only the request fields your plugin actually needs.

$name = isset( $_POST['customer_name'] )
    ? sanitize_text_field( wp_unslash( $_POST['customer_name'] ) )
    : '';

if ( current_user_can( 'manage_options' ) ) {
    echo '<p>' . esc_html( $name ) . '</p>';
}

Step 8: use nonces and capability checks for privileged actions

A nonce helps verify that a request came from the expected WordPress flow. It does not replace authorization. For admin actions, check both the nonce and the user’s capability.

if (
    ! isset( $_POST['my_business_nonce'] ) ||
    ! wp_verify_nonce(
        sanitize_text_field( wp_unslash( $_POST['my_business_nonce'] ) ),
        'my_business_save'
    )
) {
    wp_die( 'Invalid request.' );
}

if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( 'Insufficient permissions.' );
}

Step 9: keep the plugin structure simple as it grows

Once the main file becomes difficult to scan, split code by responsibility rather than creating a complicated architecture prematurely.

my-business-plugin/
├── my-business-plugin.php
├── includes/
│   ├── class-admin.php
│   └── class-workflow.php
├── assets/
│   ├── admin.css
│   └── admin.js
└── languages/

A small plugin does not need a framework simply because frameworks exist. Add structure when it improves maintenance, testing, or separation of responsibilities.

Step 10: test the plugin before packaging it

At minimum, test these scenarios on a staging environment:

• Fresh activation on a site where the plugin has never been installed.
• Deactivation and reactivation.
• A user without administrator permissions.
• Empty, invalid, and unexpected form values.
• Compatibility with the current WordPress version and your supported PHP versions.
• Front-end and admin screens with debugging enabled.
• Uninstall behavior, especially if your plugin stores persistent business data.

Step 11: package the plugin as a ZIP

When the plugin is ready to install elsewhere, compress the plugin directory itself:

my-business-plugin.zip
└── my-business-plugin/
    ├── my-business-plugin.php
    ├── includes/
    └── assets/

Install the ZIP on a clean staging site and run the setup again. A plugin that works only in the original development environment is not ready to distribute.

Should you build a plugin or use an existing one?

Custom plugin development is justified when your workflow is genuinely unique, the required integration is not available, or owning the code provides strategic value. Using an existing plugin is usually faster when the problem is common and the available solution is actively maintained.

If the feature you need is a common business workflow, you can also review GrowthPlugins products before starting a custom build.

Conclusion

The safest way to create a WordPress plugin is to begin small and stay close to WordPress conventions. Use a valid plugin header, actions and filters, WordPress APIs, capability checks, nonces, sanitization, validation, and output escaping. Test the full lifecycle on staging, then package the plugin and test the ZIP on a clean installation.

The code for a first plugin can be simple. The discipline around security, compatibility, and maintenance is what makes it production-ready.

FAQ

Can I create a WordPress plugin with only one PHP file?

Yes. A valid plugin can begin as a single PHP file with a plugin header and the code needed for its feature. Split it into additional files as the plugin grows.

Do I need to edit WordPress core to create a plugin?

No. You should not edit WordPress core for plugin functionality. Use hooks and WordPress APIs so core updates do not overwrite your changes.

What programming language is used for WordPress plugins?

PHP is the core server-side language for WordPress plugins. Plugins may also use JavaScript, CSS, HTML, and build tools depending on the interface and functionality.

Do all WordPress plugins need a settings page?

No. Add settings only when users actually need configuration. A small plugin can work entirely through hooks with no admin settings screen.

How should I secure a WordPress plugin form?

Check the user’s capability, verify a nonce for privileged requests, sanitize and validate incoming data, and escape values when rendering output. Use the WordPress security APIs designed for those tasks.

Sources

• WordPress Plugin Developer Handbook
• WordPress Plugin Basics
• WordPress Plugin Header Requirements
• WordPress Settings API
• WordPress Plugin Review Common Issues