It’s very common for developers to customize and extend existing plugins to fit their own needs, which is one of the great advantages of using open-source software. They often do it by making their changes directly to the plugin, though, which creates a security vulnerability and becomes a maintenance hassle.
If you hack a plugin to make your changes, then you create a situation where, in order to upgrade, you have to go through an annoying process of manually diff’ing your version against the canonical one and then syncing them up in both directions. You could make it a little easier by using version control to create a patch against the canonical source, and then refresh it every time an update is released, but it’s still a pain, and developers rarely go to the trouble of doing that, so they miss out on security patches and new features.
Hooks
The most common way to make a plugin extensible is to add hooks (action and filter hooks) that you can then leverage with your own plugin. If you have a good code editor (right now I’m rocking out on sublime or vscode) you should do a search through the plugin source files for: do_action and apply_filters. If the plugin author has provided those hooks, this is a very convenient and easy way for you to over-ride defaults, or inject your own code.
Pluggable Functions
If the plugin author is savvy, but is using the global namespace for the plugin functions, he/she may have wrapped the plugin’s functions within if ( function_exists() ) conditional statements. For this to work to your advantage, you have to make sure your plugin loads first (which may be a challenge). All you have to do is declare your function by the exact same name within the exact same namespace and then your function will replace the one used by the plugin.
Extension
If the plugin author is a good OOP coder, he/she may write the plugin code in a granular enough way that is open for extension (since, as the GOF would say, it is definitely closed for modification). Look for lots of granularity in the plugin class – that is to say methods that perform small, highly specific tasks – that can be overridden in your own class that extends the plugin’s class. Of course, as Toscho mentions, the class needs to be architected in such a way that it can be overridden, and that its default implementation doesn’t invoke itself completely.
Fork or Patch
If the plugin author is using gitHub, or has opened the source in some other way, you can either submit a patch to the author with your proposed modifications (your best bet is to modify the plugin to make it MORE flexible or powerful without removing or changing existing features or functionality), or you can just download the source, modify the plugin header to the extent that it will no longer be updated when the original author pushes an update out, and preferably submit your updated version to the author, or as its own entity directly to WordPress. Be aware that if you do submit the plugin to WP you will need to have a site for it and should be prepared to support it if others download it.
If you have any question then feel free comment below.
