Plugins: modify or write from scratch?
We’re often contacted by clients who’ve found a WordPress plugin that almost meets their needs, but just needs a few changes to make it work in the way they want. We’re always happy to customise existing plugins but would advise that this can lead to issues later on.
Most plugin authors release new versions fairly regularly – for example, to fix bugs, address security issues, add additional features, and to make them compatible with the latest versions of WordPress. A customised plugin is essentially a fork of that plugin, and no longer linked to the original. Therefore any future updates to the original plugin won’t be picked up by the customised version.
This might not be a problem – it really depends on the type of change you want to make and the nature of the plugin.
Small, single-purpose plugins
If the plugin we’re customising has a fairly small codebase and its function is limited to a specific task, e.g. adding a lightbox to images in a gallery, then customising it might be worth considering. The plugin is not integral to the workings of the site in the way that say, an e-commerce plugin would be, so in the unlikely event of something breaking in future, it wouldn’t be a show-stopper.
As the plugin is small, it’s not likely to be a big job to address any future issues. If it does turn out to be a problem, or a security hole is found in the original which needs to be addressed, then it’s likely to be fairly simple to fix. If not, you can easily swap it out and replace with an alternative plugin.
The principal of open-source
There’s often some mileage in taking a small plugin developed for a specific purpose and enhancing or improving it in some way. Indeed, many plugins in the repository have come about for precisely this reason. A developer found a plugin and used it on a project. However, it didn’t quite work how they wanted, so they forked it and developed a better version.
This type of continual refinement and improvement is at the heart of open-source software like WordPress, and has been instrumental to its success.
Larger, ‘site-critical’ plugins
However if your site relies on a larger scale or ‘site-critical’ plugins, then you’d have to think carefully before planning any customisation. Examples of this might be an e-commerce plugin, membership system, or plugins that change the whole architecture of the site, such as BuddyPress.
Although these are still referred to in the WordPress parlance as ‘plugins’, they are actually WordPress systems in their own right, and of a totally different order to a plugin that, for example, adds a custom logo to the WP login screen.
These types of system need to be managed carefully, and we would normally advise against modifying this kind of plugin for your project. The exception would be where you need a heavily customised implementation and want to use one of these plugins as a starting point to save on development cost. This could be the best option for your project, but future development and testing may need to be factored in as new versions of WordPress are released.
Whatever type of plugin you’re looking to change, whether simple or complex, it’s only worth considering in our view if the changes are relatively significant. By ‘significant’, I mean changing the fundamental workings of the plugin or adding whole features that aren’t available in the original.
There are some changes where I would definitely advise against creating a new plugin:
- Bug fixes – if the original plugin has a bug this should be handled in the usual way by contacting the author and hoping it’s addressed in a future release.
- Wording/text changes – it’s not worth creating a separate plugin for something minor like a wording or text change. You’d be best living with it as is, or finding an alternative plugin.
Fortunately, for smaller changes, wording changes, and CSS/design issues that you wish to address, there’s usually an alternative to developing a whole new plugin. Simply by overriding certain functions or styles in your theme, you can often make quite major changes to a plugin, without having to modify the plugin code itself. The principals we would use are the same as for creating child themes – using filters, actions, CSS and function overrides, where needed.
The caveat here is that you’re in the hands of the original author to some extent, as you are when modifying a parent theme. However, if the plugin author has followed best practice when writing the plugin, then it’s normally straightforward to change the plugin as you need.