What Do You Do With a WordPress Plugin That’s No Longer Being Updated?

The latest installment of our WordPress Q & A Sessions is about older plugins and what you should do with them.

Updating old WordPress plugins by yourself, when the developer doesn't
Is this . . . the end?

Today’s question comes from Katrina, a WPMU reader and owner of the site Kat’s Cafe. She asks . . .

How should one deal with an older (but much-loved) plugin that is no longer being updated by the developer? Should you simply uninstall it and find a replacement? Or should you try to do some updating yourself?

What’s the safest way to tweak a plugin, without putting your site at risk?


This is a dilemma that most WordPress users have faced at least once or twice. When a plugin has been abandoned by its developer, do you uninstall and say goodbye, or take matters into your own hands?

Tell us – how would you approach this situation? Can you offer Katrina any advice? Have you ever tweaked or customized one of your WordPress plugins? Please leave a comment at the end of this article and throw your two cents in.

The conversation continues! Send us a question about your very own WordPress dilemma, and you could win yourself a $159 membership at WPMU DEV: home of the best WordPress innovation on the market.

Photo: Minifig.

13 Responses

    • I liked the suggestions below. I have had success emailing a plugin developer before when I had a compatibility problem and they had stopped updating the plugin, but it was for a fairly basic pop-up box a client needed. Since that was the first time I had encountered that problem, I’ve paid close attention to the plugins I use and try to stay with plugins that show robust development.

      I also have NO problem paying for a premium plugin or donating to a developer to help offset the cost of a plugin. Like all professionals, developers need to be recognized, paid, or otherwise compensated for the time and effort they have put into their project as well.

      Thanks so much for including my question, and to those of you below who have answered it as well!

  • It doesn’t hurt to contact the developer directly and request maintenance. Developers of open source projects like these tend to do so only for the public visibility – and if nobody is rating or promoting their plugins, they are more likely to abandon them.

    • Design Lord, Child of Thor

      To add on to Shawn’s answer, why not offer to pay the developer for updates? After all, if the plugin is critical to your site, investing a few hundred dollars to include a new feature or get a bug fixed is a good deal. We should remember that we’re not *entitled* to updates. It takes the developer time to work on his plugin and that should be adequately compensated.

  • There’s the additional security/vulnerability risks that need to be considered if a plugin is no longer being updated.

    There are various variables involved but the upshot is – what might be secure now may not be secure in future. Obviously plugins are generally patched for new vulnerabilities when they are discovered, this wont be the case with a plugin that is no longer being worked on. This wont affect every unsupported plugin but it’s something to consider nevertheless.

  • I’ve developed 3 plugins (all of them currently active) and maintained on my own for one year a plugin that was completely abandoned.

    I think we usually face 2 different scenarios:

    A: A new WordPress version comes out, you update the WordPress core and the plugin is not 100% compatible or it’s completely broken.

    B: You’re using WordPress version x.y, the author of the plugin states it is compatible with that version and you find a bug.

    If I were in scenario A, I would contact the author and offer to pay him for a fix. If the author even refuses my money I’d weigh up the cost of patching it myself vs the cost of looking for an alternate solution, testing it and adopting it.

    However, if I were in scenario B I would contact the author and request him politely to fix the bug I’ve encountered. If the author refuses, I’d fix it myself and would not look for an alternate solution until a site redesign/update is needed at least.

    • The problem with fixing the bugs yourself is that if the author ever opts to fix the bugs or release a new version, your changes won’t necessarily be incorporated. I wrote a couple fixes for the “Register IP – MultiSite” plugin last year and attempted to contact the author a couple times. No response, and no updates for 3.0 thru 3.2, so I pushed my own changes to quite a few of my sites where I needed the changes and added functionality.

      Then he released updates, but the updates ONLY added compatibility to 3.3, and didn’t incorporate the filters I coded up for converting the IPs to links thru DNSstuff.

      Not a big deal on its own, but since the version number was incremented and it was based on the released version, my features were gradually being overwritten by the clients as they “upgraded” their plugins to the “current” version when it was finally released.

      Other options?

      I could have forked it, but all I really wanted was an output hook added – and I couldn’t get thru to the developer. I had no interest in maintaining it myself, either. Seems silly to fork it for only 6 new lines.

      I had already tried posting the code I wanted integrated into the plugin in a comment on the authors blog – and it was never incorporated.

      Since I couldn’t even reach the developer, offering him a bribe to add my code couldn’t work.

      • I see your point Shawn and that’s why we cap what our clients can do within the wordpress admin.

        In the case of plugins, we take 2 approaches depending on the client:

        A: Disable Plugin and Theme Update, Installation & Editor: setting the constant DISALLOW_FILE_MODS to true.

        B: If the client wants all admin functionality including plugin management and you are quite sure that if your client updates a specific plugin (the one you fixed or modified) or modifies its settings the site will break somehow, we hide that plugin from the plugins list or the menu the plugin added to the admin bars.

        This way you get in control of what your client can or cannot do.

      • “if the author ever opts to fix the bugs or release a new version, your changes won’t necessarily be incorporated”

        That’s a very good point to consider. It’s probably a wise idea to try (if possible) to get in touch with the original developer first, and find out if they’ve completely abandoned the plugin, or just put it on ice for the time being.

        Thanks for the comments – very interesting stuff.


  • New Recruit

    I have used defunct plugins with some success. I am currently using BP-Registration-Options which has not been updated for the latest WP and BP releases. In this case, the fix was easy, I just replaced a function call with the newer syntax (which was posted online) and the plugin works again.

    If the plugin causes a warning you can use this warning to track down the source of the error. The error message will include the path to the file and the line(s) of code that are offending.

    I tend to do some googling the plugin name and the WP version that I am trying to run it on to see if there are others who have updated the plugin themselves and have a fix posted to git hub or somewhere before I start trying to fix the code myself. Then I will google the function call or maybe the entire line of code to see if it has been changed in WP core.

Comments are closed.