When working on WordPress Plugins that are going to be used by others, you may want to enable other developers to create their WordPress extensions for your plugin. That will make your plugin grow even more.
Previously I have written about 5 Ways to Make your WordPress Plugin Really Extensible and also how to use OOP for Better Conversions in WordPress Plugins. Both can be applied here.
The bottom line is, your plugin must be extensible so you can allow other developers to write WordPress extensions for your plugin. Some might do it still even if your plugin is not extensible, but that is only if they need to do it for a client. That is why I have also written how to extend non extensible plugins.
If your plugin is not yet extensible, don’t worry. That is easy to fix. I recommend you to read this article to the end so you can have a basic idea of how to extend your plugin.
Helper Functions for WordPress Extensions
Let’s first create the helper functions. You can add as many as you want here if you’re going to build something complex. There are two helper functions:
- a function to get all the registered extensions
- a function to get active extensions
The first function will call a WordPress filter so other developers (or even you) can create extensions and register them through a filter.
That’s it. Pretty simple, right? At the end of this article, you will also see an example of registering one extension.
To get all the active extensions, we just need to call an option that stores all our active integrations. This function will help us to call only the extensions that a user has activated.
WordPress Extensions Admin Page
How will our plugin users know there are any extensions? The easiest possible way is to create an admin page for them. If we have a parent admin page such as a custom post type, we can easily add a submenu page. I will assume that scenario here.
Now that we have registered our admin page, let’s also create the layout of our page. I will use mostly the layout that is used on the Add New Plugin page where you can search for plugins.
The idea here is to get all the registered extensions and all the active ones. We are then iterating through each registered extension and instantiate it. When instantiated, we can get all the information we need from the object itself.
The array of active extensions is passed to the method
buttons of our object. We are doing that because we will have a method
buttons inherited from the abstract class. After that, each extension can easily create their own buttons if needed (or just leave them as they are). Inside that method, we can then know which button to show: activate or deactivate.
The Abstract Class
This class will be used for all the extensions because it has the inherited attributes and the method
buttons. At the bottom of this article, I will also show a simple extension plugin example.
As you can see, here is the method
buttons that is used to show the activate and deactivate buttons. This method can also be overwritten with various buttons if the extension requires them.
So what now? We now need to have a way to activate or deactive them. We will do that using AJAX. So let’s also enqueue our script.
The Activation Script
To be able to conditionally load the script, you need to know the value of the
$hook_suffix. You can do that just by uncommenting the line 14 and read the output.
Activating our WordPress Extensions
That’s it. Now, if everything was OK our button will become a deactivate button. But, this won’t work without the backend processing our AJAX request. Let’s register our activation script in the backend.
This script might seem a bit longer, but I’ve put enough comments inside so you can understand what is going on at each line. So, be sure to read them.
Deactivating our Extensions
Great, we are sending an AJAX request to our site for a deactivation. Let’s hook into it and process that request:
Awesome job! We are now able to activate and deactive our extensions. Almost there!
Loading Active Extensions
Just by activating or deactivating our extensions we are not doing anything is we are not loading them. To load extensions for your plugin, you should have a hook such as
do_action('myplugin_loaded'); or you could call this activation script somewhere in your plugin. I would recommend after you’ve loaded or included all your core files (especially after you have included the abstract class).
We are using the method
load() so that this is triggered only when an extension is activated. It is also a preferred way of hooking. Much better than creating hooks in the constructor method. Learned that from Carl Alexander.
WordPress Extension Example
You have a complete system of enabling extensions for your main plugin. That is great. But let’s also create an example extension. I also recommend having a simple example somewhere so other developers can start immediately building their own extension.
This simple extension is an example on how a MailChimp extension could be used to subscribe users. The
load method is filled with everything you need to enhance a part of your plugin.
At the bottom of the file we are registering our extension by adding it through the previously defined filter. That’s the power of the WordPress hooks.
I have created a complete (and a bit refactored) code that you can easily include in your own plugin and in under 10 minutes start enabling extensions for your plugin.
The WordPress Plugin API (or Hooks) is really great and this is an example on how they can be used to provide a way for other developers to extend your plugin. I am using that approach on my two new plugins and I can tell already that I love it. It is really easy for me to just create an extension and include it inside of my plugin as a separate module.Become a Sponsor
I have looked at this code so many times and I have also implemented it in test plugins, but there is one thing that I can’t understand or get working.
I can’t get the extension plugin to recognize the abstract class I required in the main plugin. Whenever I try to extend the abstract class in the extension plugin, I get a ” Fatal error: Class ‘Abstract_Example_Extension’ not found…” error. The only way I can get around this is by including/requiring the full path to the abstract class file that is in the main plugin.
Can you explain this comment “// You can define this class after a hook such as plugins_loaded to be sure.”?