Mastering Techniques to Customize WordPress Plugins Without Derailing Their Update Process

One of the best things about open-source software is that developers can easily change and add to current plugins to make them work better for their needs. Most of the time, though, they do it by making changes straight to the plugin, which leaves security holes and makes maintenance harder.

If you hack a program to make your changes, you make it so that you have to manually compare your version to the official one and then sync them both in order to upgrade. This is a pain. You could make it easier by using version control to make a patch against the official source code and then updating it every time an update comes out. But that’s still a pain, and coders don’t bother to do that, so they miss out on security patches and new features.

Hooks

Adding action and filter hooks to a plugin is the most popular way to make it expandable. You can then use these hooks in your own plugin. You should look for do_action and apply_filters in the plugin source files if you have a good code editor. For me, sublime or vscode are the best right now. If the plugin author has included those hooks, this is a quick and easy way to change the settings or add your own code.

Functions That Plug In

If the plugin author is smart and is using the global namespace for the plugin functions, then they may have put the functions inside if (function_exists()) lines. You need to make sure that your plugin loads first for this to work, which could be hard. You just need to declare your function with the same name in the same namespace as the plugin’s function. That’s it. Your function will take its place.

Extension

If the person who wrote the plugin is good at object-oriented programming (OOP), they may have written it in a way that makes it open to extensions (although the GOF would say it is definitely closed for change). You should look for a plugin class with a lot of granularity, or methods that do small, very specific jobs that you can override in a class that extends the plugin class. Toscho is right that the class should be built so that it can be overridden and its default version shouldn’t call itself all the time.

Patch or Fork

You can either send the plugin author a patch with your suggested changes if the author uses gitHub or has opened the source in some other way. The best way to do this is to make the plugin MORE flexible or powerful without removing or changing existing features or functionality. Alternatively, you can just download the source, change the plugin header so that it won’t be updated when the original author releases an update, and preferably su You should know that if you submit the plugin to WordPress, you will need to have a site for it and be ready to help people who download it.

Leave a question in the box below if you have one.