Video: I presented on this topic at WordCamp Dayton 2014.
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.
Collaborate With the Developer
Before you try anything else, the first thing to do is to send a message to the developer of the plugin and let them know what kinds of changes you need, and offer to work with them to build them into the core plugin. If they’re open to it, then you can send them a patch with your changes. The great thing about this method is that everyone who uses the plugin will benefit from your work, and you’ll have contributed something back to the developer whose work you’ve benefited from.
The developer may not like the idea, though, or it may not line up with their vision for the plugin, so that won’t always work. There are still plenty of options, though.
Extend Without Modifying
The easiest situation is when you just want to add some new functionality to their plugin, but you don’t need to remove or modify anything that the plugin does. In this case, you can simply write a separate plugin that runs alongside the plugin you’re customizing.
You can see a real-world example of this by looking at the code for Google Authenticator – Encourage User Activation.
Using Custom Hooks
If you do need to change or remove functionality from the plugin, though, there’s a much better way that just hacking it, and it’s something you’re already familiar with: hooks.
Just like WordPress provides hooks to allow plugins to customize and extend it, plugins themselves can provide hooks to allow other plugins to customize them.
So, if you’re lucky, the plugin you want to extend was written by a developer who knew enough and cared enough to include custom hooks that will allow you to extend their plugin. If they did, then your job is pretty easy; you just need to write a separate plugin that runs alongside the plugin you’re customizing, and registers callbacks for the custom hooks that the plugin provides.
Unfortunately, most developers haven’t learned to add custom hooks yet, so you won’t always be able to rely on them. But even without them, there are still two more ways that you can customize the plugin that are better than just hacking it.
Overriding Their Callbacks
The plugin you want to customize integrated with WordPress by registering callback functions for Core hooks. So, you can simply remove their callbacks, and replace them with your own. Then inside your callbacks, you can call functions from the other plugin that you need in order to recreate the parts of their functionality that you want, and avoid the parts that you don’t.
If you’d like to study a real-world example of this method, check out Google Authenticator – Per User Prompt.
Sometimes overriding their hooks isn’t ideal, though, because their functions aren’t modular enough to allow you to call individual pieces that you need without also invoking the things you don’t want. Even in that situation, though, there’s still one more method you can fall back on that’s better than just hacking all your changes into the plugin.
Adding Custom Hooks
If it’d be too much work to replace their Core hook callbacks with your own, you could hack the plugin directly, but instead of putting all your changes into it, simply add the custom hooks that you need, and then put the rest of your functionality in a separate plugin.
Then, you can submit a patch to the plugin’s developer and ask them to include the custom hooks you need in the next release of the plugin. If they do, then you can freely upgrade to new releases and your custom plugin will run cleanly alongside theirs.
But even if they don’t, then you can still upgrade by manually patching your custom hooks into each new release. That’s not ideal, but it’s much better than having to patch in all of your changes, or just not upgrade at all.
Found this from the Child Plugins thread on WP Ideas.
I’ve been looking for some sort of functionality like a child plugin but have come to the realization, like you, that hooks and filters are the best way. That doesn’t solve the problem for the user end like you indicated. Woocommerce is a great example of a plugin that allows overrides. You can copy files from the plugin directory to a directory in your theme, and the plugin will use the theme file instead of the plugin file. They also have hooks and filters to make customization easy as well.
This is a good article, but I’m still convinced that an overriding feature, without modifying the original plugin, would be ideal, at least in the cases I’ve seen.
Is WooCommerce doing that for template files, or for any file in the plugin?
For template files, I agree that plugins should let them be overridden by the theme, and I have my plugin skeleton setup to do that. But for overriding the actual behavior of a plugin, I still think that hooks are the best way to go.
If a plugin allowed it’s regular files to be overriden (via something similar to locate_template()), then that could easily break when the plugin changes versions, etc. Another approach would be to make all functions “pluggable” like Core does with some things, but that’d be impractical for every function in a plugin. I think that being able to unhook specific functions and filter the results of others is the cleanest and most precise way to modify a plugin.
I think it would only be for template files for WC.
I agree with you that hooks and filters would be the way to go. Communicating with the developer seems like the best solution at this point, if there are none built in.