WordPress Tutorial: How to Create a WordPress Plugin

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

Leave a Reply