Custom plugins/Manipulated plugins: Always a terrible idea to inherit these types of WP sites that discourage updates?

So I have been working on WP sites for a little bit now and I think I’m getting to the point where I’m starting to get to a wider range of clients with unique site builds. One site I was assigned to lately was a WP site that dealt with Automobile inventory and its biggest plugin really drove the sites functionality(a car inventory plugin). The site started having issues with things not working and it seemed like an update to the plugin would solved issues(it was 4 versions behind) but their old developer manipulated the plugin and put specific instructions to not update the plugin because its been altered. How do you work with something like that?

The other case is with a new site I just got that involves a custom plugin that the previous developer built that handles the process section the of the site(people picking packages and paying for them) it’s using a deprecated call to the database that my host(WPengine) cant work with. When communicating that to my client after talking to WPengine support, the client tells me that the developer told him not to update his plugins because it could cause issues to his site.

I have been under the impression you should always be able to update your plugins and you should never manipulate plugins from other authors because it’s bad practice and updates overwrite your changes. I’m just looking for some advice with these types of situations. Should I be staying away from sites like above or should I just be suggesting rebuilds or are there exceptions to the “no manipulation” rule. Or am I just totally off base and its ok to dabble with edited plugins as long as you know what you’re doing?

Solutions Collecting From Web of "Custom plugins/Manipulated plugins: Always a terrible idea to inherit these types of WP sites that discourage updates?"

There seems to be two separate question here:

Should one do this?

Not under most circumstances. Modifying third party extensions de-facto forks it with all implications of future maintenance and/or merging upstream (from original) changes.

Without long term commitment it’s just not practical and promptly falls apart, like in the cases you witnessed.

Should one get involved with this?

There are several possibilities here:

  1. Fix outstanding issue in modified plugin. This gets rid of immediate problem, but essentially just digs client’s site deeper into the hole.
  2. Extract the custom changes and make them work properly with original plugin without update issues. This is about optimal, but can be harder to sell than previous option.
  3. Commit to the proper maintenance of the fork. This is very unlikely, unless you will be with the client for a lot of time (and money :).

From here it’s more business than technical. It is your decision if you enjoy this kind of work. It is client decision what they want to do with their site in the end.

If the original plugin has some form of GPL license, it is okay to manipulate it as long as you honour the license. So, there is nothing legally wrong with editing a plugin, a theme or even WP core.

However, if you do this, you take over responsibility for updates from the original builders. In a way, you have become the author of a new plugin. If you don’t maintain it, it gets outdated and at some point will no longer work or have serious (security) issues.

Decent developer behaviour would be to separate the original and your modifications as much as possible (use action hooks and child themes), and to document them well for future developers.

So, in principle there is nothing wrong with the practice. The key, however, is not so much “knowing what you are doing” as “making sure that others will know what you have been doing”.