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.

Example:

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.

Conclusion

 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.

Examples?

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: