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:

Migrate a multi-site WordPress network from the server

Yesterday I was migrating a WordPress multisite network to a new server and as it has some different aspects to the migration of a WordPress only let's see how it is done, because although there are many common steps with a migration of a single site also has its peculiarities.

Why change a multi-site network server

There may be several reasons, but the reason Most usual to change a multisite network server is usually for memory or space needs .

Do not forget that a multisite network is an environment in which we offer sites, usually free, so there are multiple WordPress installations, each with their plugins, applications and scripts running, and all loading all that activity on a single (usually) database.

Nor is it to dismiss the question of [194] 59009] disk space . In the network settings you can limit the space available for each site, but if your network is successful you just have to multiply the space you grant by the number of sites hosted to stay soon without the precious and expensive gigas that you have on your server.

 settings files network multisite wordpress

In my case the problem was the available memory, because in the previous server I could not adapt to my growing needs the available resources, so I decided that the best thing was to migrate to a WordPress hosting in conditions, that would allow me all the necessary freedom and power, without this supposed a hole in my economy.

But let's go to it, to the server migration. The steps are the following …

0. Before starting

One step prior to all migration of a multisite network is disable all plugins so go to the administrator's desk of the network and disable them all.

1. Downloading files

The first thing is to have a copy of the files of the multisite network . There are many plugins but, in my experience, to migrate a multisite network it is better to do it manually by FTP or from the cPanel file manager.

The files and directories to be saved are the following:

  • Directory / wp-content / and its subdirectories
  • File wp-config.php
  • File .htaccess
  • Any file of your installation that is not WordPress

As the download of files can be of an important size my advice is that you make the copy of files by cPanel that allows you to create a compressed file of the chosen files and directories, that will be downloaded much more quickly, since the download file to file by FTP can be almost eternal.

 compress cpanel wordpress files

It will also be the fastest option for subsequent restoration of the arch ivos.

2. Downloading the database

The next – and last – thing to download is the database, so access the panel of your hosting and load phpMyAdmin. Once in your database go to the tab Export and perform the export of all tables .

Most versions of phpMyADmin will allow you to choose between fast export and the personalized one; I recommend the customized one because you can export it in a compressed file download faster and also faster later restoration.

3. Install WordPress in the new hosting

Once we have contracted our new hosting the first thing is create a clean installation of WordPress which will be the subsequent recipient of our multi-site network.

This installation should not have nothing special, in fact you can use the automatic installer of your hosting (which I suppose that at this point it will offer it, but look for another one). If your hosting provider offers it, it would be a good idea to specify that the installation will be multisite, which will save you a later step that we will see.

4. Upload your copy of the network files to the new installation

Now it's time to restore the files and directories that we copy from our network, so upload them by FTP or cPanel, replacing the directories and files of the new installation with the ones you copied, except the file wp-config.php without taking into account these two possibilities:

  1. If your hosting allowed you to create the new multi-site installation do not replace the new file ] wp-config.php by the old one, because the current one will have the connection information to the database. The new file wp-config.php will already have the multi-site network configuration.
  2. If you could not make the new installation multi-site, do not replace the new file wp-config.php ] by the old one, because the current one will have the connection information to the database. Open to edit the new file wp-config.php and copy the multi-site network configuration of the old one and save the changes.

Come on, let under no circumstances replace the file wp -config.php new by the previous one .

As in step 1 of this guide I recommend that you use cPanel to upload the files because it allows you to upload a ZIP file and decompress it, which will greatly accelerate the process. You can do it by FTP but the process is long and slow.

5. Remove the tables from the new database

Go back to phpMyAdmin from the panel of your brand new hosting and once in your new database select all the tables in the box below the list of tables and , in the drop-down to your right called " For all the selected elements " click on the option " Delete ".

 delete database tables new

You will immediately be shown a screen in which you must confirm the deletion .

 confirm delete tables new database

6 Import your copy of the database

Now that we have emptied the new database it is time for to upload the tables of the database of our network that we previously exported .

Go to phpMyAdmin , select your new database and go to the tab Import where you will have to select the file of the database that we downloaded in step 2.

 import base of wordpress data

The process is fast and automatic, and your tables will be imported into the new database easily. The only problem you might encounter in this step is the size supported by your hosting to import databases. If you exceed it, you will have to ask your hosting provider whether they care about the file or do it yourself, for example with WP-CLI or SSH .

7. Change the DNS servers

Once the physical migration is done you only have go to the management of the domain usually in the domain panel of the previous provider, and make the change of DNS servers from the previous ones to the new ones and wait for them to spread.

How long does it take? It depends. Everything has happened to me. As a general rule, any domain that is not a .es will take much less, even minutes, and .es domains can take from 1 hour in the best cases to several hours or even days in some occasions. The digital divide is called (sic).

One trick I usually use to know when the DNS server change has been made is to upload a text file of type hello to the new host. txt with a text that says " Hello, I'm already in the new hosting " and type in your url from time to time until you see the welcome text.

Final reflections

Una Once the DNS is spread, you should have your multi-site network on the new server without problems and with everything running as before. Also, since there has not been a change of domain, you will not have problems with URLs or redirections.

In any case, you may have some problem with plugin compatibility – mainly – since each server uses different versions of PHP and MySQL, and the plugin that worked well in the previous server can have problems in the new or vice versa.

This is innate with any migration, not only with multisite networks, and remember that you must always make migrations to improve, to have one more server safe and updated so if the plugin is the problem, for not being compatible with more current versions of PHP or MySQL, change plugin, do not deny a migration to a better server by an outdated plugin and vulnerable .

You will only have to go to the settings of your multi-site network and, if you deem it convenient, expand the space available for the sites, install new plugins, themes more advanced or whatever you want to make your users enjoy the advantages of the new server.

 happy move

Any questions or additional advice?

I have made several migrations of multisite networks, and sincerely with this method I have never had any problem, but if you know any better way to do it do not deprive yourself and tell us in the comments.

Likewise, if you do not understand a step or have any doubt, plant it and I will try to help you. [19659066] 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: