WordPress Tutorial: How to Create a WordPress Plugin

This is my first WordPress Tutorial. My goal here in this tutorial is to teach you how to create a WordPress plugin in a simple and organized way, with a focus on code isolation and consistency. By the time you’ve finished this tutorial, you’ll have a plugin shell created which you can use essentially as a boiler plate template for all of your future plugin ideas.

Before you get started with this WordPress plugin development tutorial, you need to know the difference between a WordPress Theme and a WordPress Plugin. Once you know the difference between a theme and a plugin, and you’re certain that you want to create a plugin. Then, this article is for you.

WordPress Themes

A WordPress theme is typically intended for front-end output only. However, there can be back-end interaction in terms of controlling what the theme does. Just think about the functionality in your theme. Everything in your theme’s directory should be directly related to what the theme does or how it appears (i.e. Theme Customizer or widgets). You shouldn’t necessarily be providing any kind of specific functionality. Once you start to develop specific functionality, you should consider moving this idea of specific functionality into a WordPress Plugin.

WordPress Themes are files that work together to create the design and functionality of a WordPress site. Each Theme may be different, offering many choices for site owners to instantly change their website look.

Why else should you build a WordPress Theme?

  • – To create a unique look for your WordPress site.
  • – To take advantage of templates, template tags, and the WordPress Loop to generate different website results and looks.
  • – To provide alternative templates for specific site features, such as category pages and search result pages.
  • – To quickly switch between two site layouts, or to take advantage of a Theme or style switcher to allow site owners to change the look of your site.

A WordPress Theme has many benefits, too.

  • – It separates the presentation styles and template files from the system files so the site will upgrade without drastic changes to the visual presentation of the site.
  • – It allows for customization of the site functionality unique to that Theme.
  • – It allows for quick changes of the visual design and layout of a WordPress site.
  • – It removes the need for a typical WordPress site owner to have to learn CSS, HTML, and PHP in order to have a great-looking website.

— WordPress Theme Development Codex

If you’re interested in creating a WordPress Theme, please read through the WordPress Theme Developer Handbook or the Theme Development Codex.

WordPress Plugins

A WordPress Plugin is typically some kind of specific functionality which isn’t already available in WordPress out of the box. This could be something exclusive to the back-end, exclusive to the front-end, or a combination of the two. Plugins will continue to provide the functionality across all themes. Plugins are (usually) not theme specific.

A WordPress Plugin is a program or a set of one or more functions written in the PHP scripting language, that adds a specific set of features or services to the WordPress site. You can seamlessly integrate a plugin with the site using access points and methods provided by the WordPress Plugin Application Program Interface (API). — Plugin Development Codex

If you’re interested in creating a WordPress Plugin, please read through the WordPress Plugin Developer Handbook or the Plugin Development Codex.

Creating a WordPress Plugin

Creating your first WordPress plugin can be a bit overwhelming at first. There’s a lot to read about and, quite honestly, it can be difficult to piece all of that information together. My goal here is to hopefully educate you on assembling a really basic plugin, with organization in mind. Organization is absolutely fundamentally key to producing a WordPress plugin. Especially if this is a plugin you plan to maintain over the years to come.

WordPress Plugins Directory

Plugins are located in the ./wp-content/plugins directory of your WordPress installation.

Step 1 – Name Your WordPress Plugin

WordPress Plugin Name
WordPress Plugin Name

Steps to Create a WordPress Plugin

  1. Name Your WordPress Plugin
  2. Isolate Your Plugin From Other Plugins
  3. Organize Your Plugin Files
  4. Define Directory Paths
  5. Load Plugin Files
  6. Directory Structure
  7. Plugin Activation, Plugin Deactivation, and Plugin Uninstallation
  8. Essential Plugin Files
  9. Security: Protect Plugin Files
  10. Plugin Hierarchy

Think of what you want to do with your plugin and think of a simple name to identify that functionality. This will be the name of your plugin.

For the sake of this tutorial, the plugin name will be “MBE Plugin” with a plugin slug of “mbe-plugin”.

Create a Directory For Your WordPress Plugin

Once you have a name, you need to create a “directory-safe” name of your plugin. This can be referred to as a “plugin slug”. This is something that will be commonly used throughout the development of your plugin. Create a sub-directory in ./wp-content/plugins. This will be the main directory which contains all of the functionality specifically for your plugin.

It should look like this:
./wp-content/plugins/<your-plugin-slug>

This is what mine looks like:
./wp-content/plugins/mbe-plugin

Create the Main WordPress Plugin File

Now that you’ve created a directory to store all of the files which will be related to your plugin, it’s time to create the main plugin file. This is the file which WordPress will look for, in order for WordPress to provide an interface in the back-end for you and/or your users to “activate”, “deactivate” , or “uninstall” your plugin.

This back-end interface would be located at:
your-domain.com/wp-admin/plugins.php

Create a file named index.php and place it in the root of your plugin directory. (./wp-content/plugins/mbe-plugin/index.php)

Provide Basic Plugin Information

Open up index.php and create a block comment. At a minimum, you must provide a Plugin Name attribute to this block comment.

I like to provide as much information about my plugin as possible; I think you should as well.

Here’s an example:

If you log into the back-end of your WordPress website and navigate to your-domain.com/wp-admin/plugins.php, you’ll see your plugin is now visible in the list of plugins. At this point, if you were to activate your plugin… Absolutely nothing would happen, because your plugin has zero functionality. All you’ve done this far is essentially tell WordPress about your plugin, but it’s a step in the right direction

Step 2 – Isolate Your Plugin From Other Plugins

WordPress Plugin Isolation
WordPress Plugin Isolation

Steps to Create a WordPress Plugin

  1. Name Your WordPress Plugin
  2. Isolate Your Plugin From Other Plugins
  3. Organize Your Plugin Files
  4. Define Directory Paths
  5. Load Plugin Files
  6. Directory Structure
  7. Plugin Activation, Plugin Deactivation, and Plugin Uninstallation
  8. Essential Plugin Files
  9. Security: Protect Plugin Files
  10. Plugin Hierarchy

If you currently aren’t practicing using Namespaces, now’s the time to start. If you’re unaware of what a Namespace is, please educate yourself on PHP Namespaces. It really doesn’t take that long to learn, and it’s totally worth it. FAQ: things you need to know about namespaces

In the past, before Namespaces were relevant, WordPress developers used to prefix: function names, class names, variables, etc. with a unique identifier and/or even a conditional check.

Example of a non-prefixed function name:

Example of a prefixed function name using mbe_ as a prefix:

Example of using a conditional check to avoid conflicts:

Using prefixes and/or conditional checks can become tedious over time. It’s not practical, and can eventually pose a problem at some point.

Namespaces greatly reduce the possibility of potential conflicts. They allow you to skip using conditional checks ~90+% of the time, and there’s no need to: prefix function names, class names or variable names. Namespaces isolate your code from all other code (A/K/A the global scope). This allows you to freely name your stuff whatever you want (within the scope of your namespace).

Define a Namespace

Namespaces are so simple to use. All you need to do is specify one line of code at the top of every file in your plugin. I like to try to keep the naming convention similar to my plugin name.

Define your namespace near the top of your index.php file:

Namespaces are case-sensitive, so make sure you’re consistent with your naming convention throughout your plugin files.

Accessing Namespaced Functionality

You should be able to access any function from the global scope as you always have previously, however sometimes, you need to determine the scope of the desired function.

I know I just got done saying there’s no need for prefixes anymore, that’s not entirely true. You might need to prefix your function calls with a backwards slash and/or include the namespace along with your function call. I like to think of namespaces as a “path”. You will notice I try to organize my namespaces similarly to the way I organize my directory and file structure.

For example, if you wanted to use WP_Query in your namespaced plugin, Previously you would have just done WP_Query( array( '' => '' ) ); but now you would need to do: \WP_Query( array( '' => '' ) ); Notice the backwards slash immediately before the class name? That’s because this class name is a part of the global namespace, which is outside of your namespace.

I haven’t quite figured out when it’s necessary to use a backwards slash and when it isn’t. So far, I’ve come to the conclusion that it’s necessary for class names. There have been some functions I’ve had to do this with as well. wp_head(); and wp_footer(); for example, I’ve had to write like: \wp_head(); and \wp_footer(); while inside a namespace.

Ideally though, most functions you should be able to use just as normal, without the need of a backwards slash prefixing the function call. While $this->statement == true; it’s slightly hypocritical and $this->statement !== true;. (I tried to be punny there with a little code humor.)

Let’s say you’ve created a function called get_settings(); within the namespace of your plugin. Now, when you make a call to get_settings();, PHP will attempt to use the function defined in your plugin’s namespace. That’s fine and dandy, but what if you wanted to use the core WordPress function named get_settings();? You would then need to prefix the function call with a backwards slash, like this: \get_settings(); and if you wanted to use your plugin’s function you would just call it as normal like: get_settings();, since it’s defined within your namespace.

Please just read the documentation PHP Namespaces and FAQ: things you need to know about namespaces. It’s explained much better there.

Step 3 – Organize Your Plugin Files

WordPress Plugin Organization
WordPress Plugin Organization

Steps to Create a WordPress Plugin

  1. Name Your WordPress Plugin
  2. Isolate Your Plugin From Other Plugins
  3. Organize Your Plugin Files
  4. Define Directory Paths
  5. Load Plugin Files
  6. Directory Structure
  7. Plugin Activation, Plugin Deactivation, and Plugin Uninstallation
  8. Essential Plugin Files
  9. Security: Protect Plugin Files
  10. Plugin Hierarchy

I’ve developed several WordPress Plugins and WordPress Themes over the years, and I’ve come to the conclusion that organization is KEY. Personally, I like to organize my files by “views” or “scopes”.

Create Sub-directories

With this method of organization, you have: front-end functionality, back-end functionality, and global functionality (both front-end functionality and back-end functionality).

Create the follow sub-directories:

  1. frontend => ./wp-content/plugins/mbe-plugin/frontend
  2. backend => ./wp-content/plugins/mbe-plugin/backend
  3. global => ./wp-content/plugins/mbe-plugin/global

Create Index Files

For each of the above directories, create an index.php file (much like you did for the root of your plugin directory). These files will act as the “master file” which is responsible for that particular “view” or “scope” of your plugin. You’ll want to make sure they’re namespaced appropriately, to avoid conflicting functionality later on.

Contents of ./wp-content/plugins/mbe-plugin/frontend/index.php:

Contents of ./wp-content/plugins/mbe-plugin/backend/index.php:

Contents of ./wp-content/plugins/mbe-plugin/global/index.php:

You’ll notice that in each of the three files, I’ve defined a namespace. Personally, I feel no need to assign a unique namespace for the global “view” or “scope”. In my opinion, the default namespace of the plugin is a sufficient place for the global functionality. The important thing is to separate back-end functionality from front-end functionality.

Step 4 – Define Directory Paths

WordPress Plugin Directory Paths
WordPress Plugin Directory Paths

Steps to Create a WordPress Plugin

  1. Name Your WordPress Plugin
  2. Isolate Your Plugin From Other Plugins
  3. Organize Your Plugin Files
  4. Define Directory Paths
  5. Load Plugin Files
  6. Directory Structure
  7. Plugin Activation, Plugin Deactivation, and Plugin Uninstallation
  8. Essential Plugin Files
  9. Security: Protect Plugin Files
  10. Plugin Hierarchy

Loading files in a WordPress plugin can be a bit tricky. Get the trickery out of the way early on by determining the directory path location of your plugin and defining a PHP Constant to be used later throughout the development of your plugin. Personally, I like to define a few additional constants to also be used later on. Optional for you, but I’ve found them to be nice to have.

Contents of ./wp-content/plugins/mbe-plugin/index.php:

Define a PATH constant for each “view” or “scope” of your plugin as well.

Contents of ./wp-content/plugins/mbe-plugin/frontend/index.php:

Output of: \MBE_PLUGIN\FRONTEND\PATH
Would produce: ./wp-content/plugins/mbe-plugin/frontend

Contents of ./wp-content/plugins/mbe-plugin/backend/index.php:

Output of: \MBE_PLUGIN\BACKEND\PATH
Would produce: ./wp-content/plugins/mbe-plugin/backend

Contents of ./wp-content/plugins/mbe-plugin/global/index.php:

You’ll notice in the global ./mbe-plugin/global/index.php file, that the constant is GLOBAL_PATH instead of PATH. That’s because the global files use the same namespace as the main plugin ./mbe-plugin/index.php file. There’s already a constant named PATH defined in the main plugin ./mbe-plugin/index.php file.

If you were to define PATH again under the global ./mbe-plugin/global/index.php file, it would conflict with the PATH constant defined in the main plugin ./mbe-plugin/index.php file. Simple remedy that makes logical sense is to just label it as GLOBAL_PATH.

If you were to output \MBE_PLUGIN\PATH, it would output the path to the root of your plugin directory. If you were to output \MBE_PLUGIN\GLOBAL_PATH, it would output the path to the global files directory of your plugin.

Output of: \MBE_PLUGIN\PATH
Would produce: ./wp-content/plugins/mbe-plugin

Output of: \MBE_PLUGIN\GLOBAL_PATH
Would produce: ./wp-content/plugins/mbe-plugin/global

Step 5 – Load Plugin Files

WordPress Plugin Load Files
WordPress Plugin Load Files

Steps to Create a WordPress Plugin

  1. Name Your WordPress Plugin
  2. Isolate Your Plugin From Other Plugins
  3. Organize Your Plugin Files
  4. Define Directory Paths
  5. Load Plugin Files
  6. Directory Structure
  7. Plugin Activation, Plugin Deactivation, and Plugin Uninstallation
  8. Essential Plugin Files
  9. Security: Protect Plugin Files
  10. Plugin Hierarchy

In order to implement organizational tactics, you need to conditionally determine and load the files appropriately. This can be done very easily in your main plugin file.

Example of conditionally loading plugin files:

You’ll notice a few things here:

  1. I used an action hook plugins_loaded. The reason for this is that it ensures your plugin functionality is completely available at the same time as all other plugins. This also adds flexibility for you and/or other WordPress developers by allowing them to essentially disable your plugin temporarily or permanently, without deactivating your plugin from WordPress itself.
  2. I used an anonymous function as an attached callback function to the plugins_loaded hook. I did this for a specific reason. I don’t want this function to easily be unhooked from the plugins_loaded action hook. I want to make it possible, but not a simple task. This adds a small level of protection for your plugin, while still allowing flexibility.
  3. I defined two custom action hooks. mbe-plugin-load (at the start of the function) and mbe-plugin-loaded (at the end of the function). This allows for you and other WordPress developers to execute functionality before your plugins has been loaded, and/or after your plugin has been loaded.

Note: None of your plugin functionality starts until the core WordPress action hook plugins_loadedhas been fired. This means that none of your functionality will be available during plugin activation for example, because the plugin hasn’t loaded yet. More information on this in Step 7.

Step 6 – Directory Structure

WordPress Plugin Directory Structure
WordPress Plugin Directory Structure

Steps to Create a WordPress Plugin

  1. Name Your WordPress Plugin
  2. Isolate Your Plugin From Other Plugins
  3. Organize Your Plugin Files
  4. Define Directory Paths
  5. Load Plugin Files
  6. Directory Structure
  7. Plugin Activation, Plugin Deactivation, and Plugin Uninstallation
  8. Essential Plugin Files
  9. Security: Protect Plugin Files
  10. Plugin Hierarchy

I like to create an “includes” directory under each “view” or “scope” directory. The includes directory can be labeled as inc instead of includes. This is just a personal preference, because if you were to spell everything out in full, your file paths can end up becoming rather long. I try to keep directory names short if possible. When you’re programming your code, you should have the opposite mentality. Spell it out the long way (without getting too long of course), it helps to better identify what your code is expected to do.

Create an “includes” directory for each  “view” or “scope”:

  1. frontend => ./wp-content/plugins/mbe-plugin/frontend/inc
  2. backend => ./wp-content/plugins/mbe-plugin/backend/inc
  3. global => ./wp-content/plugins/mbe-plugin/global/inc

Planning Ahead

As you continue to develop your plugin, you’ll begin to add additional files of various types / extensions. It’s important to always keep organization in mind as you add these additional files to your plugin.

Create the following sub-directories in each of the includes directories as a starting point. You may or may not use all of these directories in your plugin.

FRONTEND
  1. classes => ./wp-content/plugins/mbe-plugin/frontend/inc/class
  2. styles => ./wp-content/plugins/mbe-plugin/frontend/inc/css
  3. images => ./wp-content/plugins/mbe-plugin/frontend/inc/img
  4. scripts => ./wp-content/plugins/mbe-plugin/frontend/inc/js
BACKEND
  1. classes => ./wp-content/plugins/mbe-plugin/backend/inc/class
  2. styles => ./wp-content/plugins/mbe-plugin/backend/inc/css
  3. images => ./wp-content/plugins/mbe-plugin/backend/inc/img
  4. scripts => ./wp-content/plugins/mbe-plugin/backend/inc/js
GLOBAL
  1. classes => ./wp-content/plugins/mbe-plugin/global/inc/class
  2. styles => ./wp-content/plugins/mbe-plugin/global/inc/css
  3. images => ./wp-content/plugins/mbe-plugin/global/inc/img
  4. scripts => ./wp-content/plugins/mbe-plugin/global/inc/js

Step 7 – Plugin Activation, Plugin Deactivation, and Plugin Uninstallation

WordPress Plugin Activation, WordPress Plugin Deactivation, WordPress Plugin Uninstallation
WordPress Plugin Activation, WordPress Plugin Deactivation, WordPress Plugin Uninstallation

Steps to Create a WordPress Plugin

  1. Name Your WordPress Plugin
  2. Isolate Your Plugin From Other Plugins
  3. Organize Your Plugin Files
  4. Define Directory Paths
  5. Load Plugin Files
  6. Directory Structure
  7. Plugin Activation, Plugin Deactivation, and Plugin Uninstallation
  8. Essential Plugin Files
  9. Security: Protect Plugin Files
  10. Plugin Hierarchy

Often times, your plugin will need to perform specific tasks when: your plugin has been activated, when your plugin has been deactivated, or when your plugin uninstalls itself.

Plugin Activation

When your plugin is activated, you might want to check if this is the first time your plugin has been activated; If so, then perform your plugin “setup” or “installation” tasks. Maybe you’ve modified your plugin in a new version by altering database interaction. When the user updates your plugin, it will trigger the activation event, you can then automatically perform your necessary “upgrade” tasks at this time as well.

An example of a task to perform on plugin activation might be that you’ve added a custom post type. Now you need to flush the rewrite rules using flush_rewrite_rules(); , in order for your custom post type objects to load appropriately on the front-end.

Create the Plugin Activation File and Functionality

Since the plugin activation event only occurs from back-end user interaction, the file should be created within the back-end includes directory.

Create a file named activation.php in the back-end includes directory of your plugin.

Contents of ./wp-content/plugins/mbe-plugin/backend/inc/activation.php:

Plugin Deactivation

When your plugin is deactivated, you might want to clean up after yourself to avoid possibly breaking functionality on the user’s WordPress website.

An example of this might be that you’ve added a custom post type on plugin activation and modified the rewrite rules. Now you need to flush the rewrite rules using flush_rewrite_rules(); , in order prevent 404 not found errors or 500 internal server errors, since the custom post type will no longer exist after plugin deactivation.

Note: You’ll likely want to keep database settings and potentially some files on the user’s WordPress installation, so that the WordPress user can resume where they left off the next time your plugin is activated again. This event doesn’t usually tend to be treated as a point of uninstalling your plugin. There’s another specific event triggered which you should use for uninstalling your plugin completely.

Create the Plugin Deactivation File and Functionality

Since the plugin deactivation event only occurs from back-end user interaction, the file should be created within the back-end includes directory.

Create a file named deactivation.php in the back-end includes directory of your plugin.

Contents of ./wp-content/plugins/mbe-plugin/backend/inc/deactivation.php:

Plugin Uninstallation

Providing the WordPress user with the ability to uninstall your plugin is huge, and honestly, should be mandatory for all WordPress plugins. If the WordPress user wants to uninstall your plugin. That means they likely don’t plan on using your plugin ever again, or at least not for the foreseeable future. That means you should remove EVERYTHING which is directly related to your plugin. This includes: directories, files, and ALL database entries.

Create the Plugin Uninstallation File and Functionality

Since the plugin uninstallation event only occurs from back-end user interaction, the file should be created within the back-end includes directory. Create a file named uninstallation.php in the back-end includes directory of your plugin.

Contents of ./wp-content/plugins/mbe-plugin/backend/inc/uninstallation.php:

Register Events For: Activation, Deactivation, and Uninstallation

In order for your functionality to be triggered upon these events, you need to register your actions with WordPress. I personally like to register these actions in the main plugin file, because these events are triggered based off this file (with the exception of the uninstallation – You can either register an event using a hook, or you can optionally add a file called uninstall.php in the root directory of your plugin ./wp-content/plugins/mbe-plugin/uninstall.php).

To keep things simple and consistent, I recommend registering an action hook in the main plugin file for each of these events.

You’ll notice a couple of things here:

  1. I used anonymous functions for each event. This is for the sake of clean code in the main plugin file, and again, to allow the functionality to be unhooked, but not very easily.
  2. I defined the uninstallation event inside the activation event. This is because you only want to register the uninstallation functionality when the plugin is activated, not on every page load.
  3. I demonstrated usage of a prefixed namespace function call. Namespaces are semi-relative, so I don’t need to specify the entire fully qualified namespace. However, if you wanted to go up or down one or two namespace levels, then you would need to specify the fully qualified namespace as a prefix to the function call.

Note: Your actual functionality for each of these events is contained within the function specified in the appropriate included file.

  1. activate => ./wp-content/plugins/mbe-plugin/backend/inc/activation.php
  2. deactivate => ./wp-content/plugins/mbe-plugin/backend/inc/deactivation.php
  3. uninstall => ./wp-content/plugins/mbe-plugin/backend/inc/uninstallation.php

Step 8 – Essential Plugin Files

WordPress Plugin Essential Files
WordPress Plugin Essential Files

Steps to Create a WordPress Plugin

  1. Name Your WordPress Plugin
  2. Isolate Your Plugin From Other Plugins
  3. Organize Your Plugin Files
  4. Define Directory Paths
  5. Load Plugin Files
  6. Directory Structure
  7. Plugin Activation, Plugin Deactivation, and Plugin Uninstallation
  8. Essential Plugin Files
  9. Security: Protect Plugin Files
  10. Plugin Hierarchy

The more you develop with WordPress, the more you will come to realize that hooks are absolutely EVERYWHERE in the WordPress ecosystem. There are two types of hooks in WordPress: action hooks and filter hooks. Whether you use an action hook or a filter hook; they both require an attached callback function, in order to trigger additional functionality on any particular event.

Before you know it, you’ll have SEVERAL hooks used through out your plugin. For every hook you’ll have at least one function, plus any other extended functionality you have.

If you’re not careful, your code can spiral out of control and things can get quite messy very rapidly. That’s why it’s so important to stay on top of your organization.

Create a file named hooks.php and file named functions.php under each includes directory.

FRONTEND

  1. hooks.php => ./wp-content/plugins/mbe-plugin/frontend/inc/hooks.php
  2. functions.php => ./wp-content/plugins/mbe-plugin/frontend/inc/functions.php

Contents of front-end hooks.php:

Contents of front-end functions.php:

BACKEND

  1. hooks.php => ./wp-content/plugins/mbe-plugin/backend/inc/hooks.php
  2. functions.php => ./wp-content/plugins/mbe-plugin/backend/inc/functions.php

Contents of back-end hooks.php:

Contents of back-end functions.php:

GLOBAL

  1. hooks.php => ./wp-content/plugins/mbe-plugin/global/inc/hooks.php
  2. functions.php => ./wp-content/plugins/mbe-plugin/global/inc/functions.php

Contents of global hooks.php:

Contents of global functions.php:

Load hooks.php and functions.php for each “view” or “scope”

At this point, you’ve prepared your files, but they don’t do anything, because they haven’t been included yet. You need to load the files from each “master file” created in Step 3.

Contents of ./wp-content/plugins/mbe-plugin/frontend/index.php:

Contents of ./wp-content/plugins/mbe-plugin/backend/index.php:

Contents of ./wp-content/plugins/mbe-plugin/global/index.php:

Now every time you want to hook into something, you can place the hook in the appropriate hooks.php file and define the callback function in the appropriate functions.php file.

Step 9 – Security: Protect Plugin Files

WordPress Plugin Security
WordPress Plugin Security

Steps to Create a WordPress Plugin

  1. Name Your WordPress Plugin
  2. Isolate Your Plugin From Other Plugins
  3. Organize Your Plugin Files
  4. Define Directory Paths
  5. Load Plugin Files
  6. Directory Structure
  7. Plugin Activation, Plugin Deactivation, and Plugin Uninstallation
  8. Essential Plugin Files
  9. Security: Protect Plugin Files
  10. Plugin Hierarchy

I like to practice security in my plugins. That is by determining when and/or how your plugin files are accessed.

Deny Direct Access to Plugin Files

This method of security will prevent anyone from directly accessing any of your plugin files. It’s only a small chunk of code to place near the top of all plugin files.

The above code will kill PHP if anyone directly accesses your plugin file. Add this code to all plugin files.

Deny Frontend Files From the Backend

You don’t want your front-end files to be included anywhere in the back-end.

Unlike denying direct access to files, you don’t want to kill PHP. Instead, just return and let PHP continue.

Deny Backend Files From the Frontend

You don’t want your back-end files to be included anywhere in the front-end.

Unlike denying direct access to files, you don’t want to kill PHP. Instead, just return and let PHP continue.

Apply Basic Security Protection to all Plugin Files

Contents of: ./wp-content/plugins/mbe-plugin/index.php:

Contents of: ./wp-content/plugins/mbe-plugin/frontend/index.php:

Contents of: ./wp-content/plugins/mbe-plugin/backend/index.php:

Contents of: ./wp-content/plugins/mbe-plugin/global/index.php:

Contents of: ./wp-content/plugins/mbe-plugin/frontend/inc/functions.php:

Contents of: ./wp-content/plugins/mbe-plugin/frontend/inc/hooks.php:

Contents of: ./wp-content/plugins/mbe-plugin/backend/inc/functions.php:

Contents of: ./wp-content/plugins/mbe-plugin/backend/inc/hooks.php:

Contents of: ./wp-content/plugins/mbe-plugin/global/inc/functions.php:

Contents of: ./wp-content/plugins/mbe-plugin/global/inc/hooks.php:

Contents of: ./wp-content/plugins/mbe-plugin/backend/inc/activation.php:

Contents of: ./wp-content/plugins/mbe-plugin/backend/inc/deactivation.php:

Contents of: ./wp-content/plugins/mbe-plugin/backend/inc/uninstallation.php:

Step 10 – Plugin Hierarchy

WordPress Plugin Hierarchy
WordPress Plugin Hierarchy

Steps to Create a WordPress Plugin

  1. Name Your WordPress Plugin
  2. Isolate Your Plugin From Other Plugins
  3. Organize Your Plugin Files
  4. Define Directory Paths
  5. Load Plugin Files
  6. Directory Structure
  7. Plugin Activation, Plugin Deactivation, and Plugin Uninstallation
  8. Essential Plugin Files
  9. Security: Protect Plugin Files
  10. Plugin Hierarchy

Just to summarize everything, the end result is your plugin structure should look similar to the following outline:

  • mbe-plugin
    • frontend
      • inc
        • class
        • css
        • img
        • js
        • functions.php
        • hooks.php
      • index.php
    • backend
      • inc
        • class
        • css
        • img
        • js
        • activation.php
        • deactivation.php
        • functions.php
        • hooks.php
        • uninstallation.php
      • index.php
    • global
      • inc
        • class
        • css
        • img
        • js
        • functions.php
        • hooks.php
      • index.php
    • index.php

Conclusion

If you read through all of the steps in this tutorial on how to create a WordPress plugin and practiced this with your own plugin name; You should have a very good start on your plugin. This tutorial wasn’t meant to produce a plugin that actually does anything. It’s more or less just a plugin skeleton or plugin boiler plate template, which you can use for pretty much ANY WordPress plugin. The idea here is to get you going with WordPress plugin development practicing: organization, simplicity, isolation, and consistency.

I purposely didn’t include a simple .zip download of these files or a gist because I want you to actually read, and follow along. I feel like you’ll obtain much more of an understanding about creating a WordPress Plugin if you assemble this bits and pieces step by step. If you just download and search/replace, that doesn’t really teach you much.

Resources

I thought it would be helpful to include a list of useful resources to accompany some of the functionality used to compose this plugin shell.

  1. WordPress Plugin Development Handbook
  2. WordPress Plugin Development Codex
  3. WordPress Plugin API
  4. WordPress Coding Standards
  5. WordPress Hooks
  6. WordPress Action Hooks
  7. WordPress Filter Hooks
  8. PHP Namespaces
  9. FAQ: things you need to know about namespaces
  10. PHP Callback Functions
  11. PHP Anonymous Functions
  12. PHP Constants
  13. PHP Magic Constants
  14. WordPress Hooks Database
  15. Advanced WordPress Hooks

 


SOCIALIZE

I’d love to hear what you think of this WordPress plugin development tutorial in the comments. If there’s any portion of this WordPress tutorial that lacks detail or seems unclear, please let me know. The odds are: if you feel that way, someone else probably does too.

If you enjoyed this article, please subscribe to my blog. I try to post educational / informative information about WordPress and much of what relates to Web Design and Website Development in general.

Leave a Reply