Plugins children or dependents? – The correct way to customize plugins

One of the most common development tasks for the WordPress programmer is the modification and customization of plugins to create applications adapted to the needs of the client but there are many ways to do it wrong and many to do it well .

The most usual way to do it wrong is any variation of modify the plugin " bareback " add, delete, modify the plugin code and give it to your client as is.

And yes, the beauty of open source, Open Source, and that WordPress is GPL is that you always have the code there to modify it, but the problem is that if you modify the plugin and give it tuned to a client you will deny the updates of the original plugin generating ole a security problem and another of loss of future functionalities.

It is good that you can always do your plugin maintenance, for a small fee, but even for you the updates will be hell, because you will have to do them manually, reviewing each line of code, the dependencies with your modifications, etc., etc.

Are we talking about child plugins?

 son ​​plugins and plugins father

Plugins children ?

There is the concept and development of child themes but, in principle, the same concept does not exist for plugins so there is no such thing as what we might call a child plugin or a structured and unified mode of do what. It has been proposed but has not prospered so far.

Perhaps the most promising advance came from the part of Plugin Dependencies a meta-plugin that even offers an interface from the than checking the dependencies of a child plug-in on a parent, even using this terminology. The plugin warns of the dependencies when activated and even allows to deactivate father and son in unison.

An example of use they show it in the same page of the plugin …

What does this child plugin do?

  • Prevents BuddyPress Debug from being activated if BuddyPress and Debug Bar are not active before.
  • When either BuddyPress or Debug Bar is deactivated, BuddyPress Debug will also be disabled.

The problem is that few plugins include dependency information, but the idea is good, and maybe one day it will develop.

However, it is not as simple as the son themes, because they all have a similar structure, while the plugins are each of his father and his mother.

So how do we do it? It is more can you?

Yes, and there are several ways to customize plugins let's see them …

Contact the developer

From obvious to very few people it occurs to you that there is no simpler way to customize a plugin than to contact the developer, suggest your modifications and incorporate them into a new version, even with your help.

Do a fork

Another possibility, which can, and should, previously pass through the previous method, is to make your own version of the plugin, a fork that includes those modifications that you have detected and want to add.

good thing about this method is that if you upload your fork to the official directory of plugins other users will enjoy your good ideas and work. In step you gain prestige in the community and to your present and future customers.

The bad thing about this method is that you acquire a commitment to its maintenance, something not always possible.

Create a dependent plugin with hooks

We have finally arrived at something viable and correct!

The correct way to customize a plugin is to create another plugin child dependent on parent that, using [19659037] custom hooks use the functions of the parent extending or modifying its functionalities.

And, as you already know, there are two types of hooks or hooks : action hooks and filter hooks . Are we going to it?

What are action hooks and filter hooks?

You've seen, and even used, many of them. Whenever we see a mode of customize WordPress without modifying the files core we do it using action hooks and filter hooks.

Yes, I I refer to all the modifications and customizations that we make using our utilities plugin or adding custom functions to the file functions.php of the topic .

So if the developer of the plugin already included in his code personalized hooks you are in luck. It is a good practice for good developers, although not all of them still use it.

Extending a plugin with hooks

All you need to do is create a separate plugin that runs in conjunction with the plugin you want to customize, and record the callbacks for the custom hooks offered by the original plugin .

Extending plugins with action hooks

The actions are hooks (or hooks if you prefer) that launches the WordPress kernel at specific points of its execution, or when something happens. They are PHP functions that are executed in these execution points, either in WordPress, plugins or themes, and allow you to customize their behavior.


With this we can already interact with the function and use its arguments ($ args1, $ args2) using the hook 'Name- De-tu-Action-Hook '. For example:

Extending plugins with filter hooks

Filters are hooks which launches WordPres to modify text or others elements before adding them to the database or sending them to the browser. Your plugin can specify that one or more of its PHP functions modify specific types of text.

Let's look at an example again:

And, as in the previous case , we can do things with that function, filter the $ output and use its arguments ($ args1, $ args2) using your hook 'Name-Of-Your-Filter-Hook'. So …

Registering callbacks

Surely you have noticed that in the methods seen we are registering callbacks that replace the of the original plugin and replace them with ours.

Then, in our callbacks we call the functions of the other plugin, the father, that we need to recreate the parts of its functions that we want to expand or modify, and we avoid the parts we do not need.


 father son

As you will see, although the concept of child plugins does not exist as such, it is totally feasible to take advantage of the functionalities of an original plugin and expand them with our own plugin that, half nte hooks, take advantage of its base functionalities and add or replace those that we want to modify.

In this way we will have our custom plugin son ​​dependent on the original plugin father which our client will be able to update normally without losing the customizations that we have added.

We just have to clearly indicate in the documentation the dependency, so that no one can think of uninstalling the plugin father as it is Logically, or will also stop working our customizations, not being an independent plugin, but dependent.


Fortunately there are many good examples that we can learn this type of techniques, here are some dependent plugins:

References for further knowledge:

NOTICE : This publication is from two years ago or more. If it's a code or a plugin it might not work in the latest versions of WordPress, and if it's a news story it might be obsolete. Then do not say we have not warned you.

Loading …

That may also help you:

10 basic skills of the WordPress plugin developer

 developer wordpress

The plugins are great part of the greatness and beauty of WordPress and create your own plugin will give you a knowledge and freedom that you will not find if you simply use what others create.

Now, if you throw yourself into the WordPress plugin development it does not hurt to keep this in mind ] 10 basic tips for creating plugins :

:: 1. Creating the plugin ::

The first step is to create the folder of your plugin in the directory / wp-content / plugins . Once you have created the folder you must place the files of your plugin in that folder. There must be a main plugin file, and the file names must have only letters and hyphens (-) if you want to separate words, do not use other punctuation marks or spaces.

A type name would be something like this: plugin-seo-sencillo.php

The main file of the plugin must have the following structure for WordPress to identify it as a plugin:

Once you save the changes , even if you do not have the plugin yet, you will see it on the WordPress plugins page.

:: 2. Activation and deactivation of the plugin ::

Plugins can be activated by clicking on the link " ] Activate "from the list of plugins. In a basic plugin you do not have to do anything when activating it. But an advanced plugin will require tasks such as launch the plugin settings, create tables, etc., so let's see how we can manage the activation and deactivation of a plugin.

Plugin activation hook

WordPress offers a function called register_activation_hook that is launched when a plugin is activated. We can add custom functions that are executed when activating the plugin using this method. An example would be the following:

You have to define the path of the file that contains the activation function as the first parameter and the name of the function as the second parameter.

If the activation function is inside the main plugin file you can use _FILE_ as in the previous example. Within the activation function you can also perform tasks such as validations, initializations and creation of tables

Plugin deactivation hook

We can manage the deactivation of a plugin with register_deactivation_hook using a similar syntax to that of activation. In the deactivation function you can also perform additional actions such as cleaning plugin resources, settings and tables.

:: 3. Creation of custom tables ::

The structure of the WordPress database and it is very flexible, and you can implement most of the custom features using the tables that are available.

However, sometimes you may prefer to include more advanced systems, such as shopping carts, task management systems , subscriptions, etc.

In these cases you should know how and when create custom tables . The first thing is to take into account the requirements of your project and try to use the table and meta tables wp_options to store the data specific to your project. If you consider that these tables do not have the necessary structure to implement the functionality you need then create custom tables using the following method:

First we check if the table exists before creating it. You can decide to create the table at the time of activation, depending on what you need. In the example you will see that {$ wpdb-> prefix} is used before creating the name of the table. This is because, normally, WordPress tables start with the prefix wp_ . This can be changed when you install WordPress, so it's better not to manually add the prefix wp_ since it could be another, and so we make sure it will adapt to what exists.

Using {$ wpdb -> prefix} you will get the prefix defined in the WordPress installation, so always use this syntax to create the tables.

Even if you use the function $ wpdb-> query to create the tables it is advisable to use the function dbDelta since it compares the current table structure. It is not loaded by default so you must include it at the beginning of the file.

:: 4. Including Scripts and styles ::

Even if you only echo scripts and styles it is recommended to add the scripts using the function wp_enqueue_script . This function checks whether files and dependencies are available with other scripts. The following example shows how to use the function wp_enque_script :

First you use wp_register_style to register the style file and wp_enqueue_style to include the file. You must also indicate the path and unique identifier of the style file. Then the scripts are included using the function wp_enqueue_script . If it depends on other scripts you can mention them in the third parameter. In the example, a dependency of jQuery has been added.

Finally, you can add data that will be used within specific scripts using the function wp_localize_script . You can include the scripts where you want but always use the functions wp_enqueue_scripts and wp_enqueue_styles .

Also make sure to use the action admin_enqueue_script instead of wp_enqueue_script for the admin part.

:: 5. Creating shortcodes ::

The shortcodes are predefined code blocks that you can use anywhere. It is essential to learn how to use shortcodes if you want to be a plugin developer since they add dynamic elements to custom pages.

You can create shortcodes using a syntax like the following: