Cancel

Jeff Chandler

Nearly Half of the WordPress Plugins in the Directory Are Not Updated After Two Years

Luca Fracassi, founder of Addendio, an alternative search engine for the WordPress plugin and theme directories published an in-depth look at the WordPress plugin directory. The post includes data that shows the number of plugins added to the directory per year, what year the plugins were last updated, and other metrics.

My favorite data point is the number of plugins approved per year. Based on this data, it looks like it’s going to be another record year for the directory. The five active team members including, Mika Epstein, Pippin Williamson, and Samuel Wood have their work cut out for them.

Number of Plugins Added Per Year
Number of Plugins Added Per Year

According to the data, about 22K plugins have been updated in the last 24 months representing a little more than half the directory. This means that approximately half of the plugins in the directory are displaying a notice that the plugin hasn’t been updated in two years.

Update Notice After Two Years of No Updates
Update Notice After Two Years of No Updates

Fracassi says that based on the data, “Two out of ten plugins are updated after three years. If you pick a free plugin that is released today, there’s a 80-90% chance that in three years time you won’t have any more updates.”

There are a number of possibilities as to why a plugin doesn’t get updated for two years or more.

  1. The developer burns out or moves on.
  2. The plugin doesn’t need an update.
  3. Lack of donations.
  4. Support is too much of a burden.
  5. No time.

The data doesn’t spell doom and gloom for users but it clearly shows that many plugins within the directory don’t have a long shelf life. I encourage you to read Fracassi’s post and review the data he’s collected. Also check out our guide on how to choose a WordPress plugin.

Category:
Tags: ,
85

85 responses to “Nearly Half of the WordPress Plugins in the Directory Are Not Updated After Two Years”

  1. I thought WordPress was going to implement something with the repository where very old plugins would be automatically removed from the repository? IMO 3 year old plugins should be moved to some kind of archived repository or something like that – as least hidden from the main repository.

    • Since WordPress has the “mantra”, plugins not options, there are a couple of plugins that all they do is disable a feature. They will never change. Detecting those and disabling the 2 year notice is probably a good idea.
      Running a search and removing all plugins that use deprecated methods will most likely yield good candidates for archive mode.

      • Maybe once the plugin hits the 2 year mark an email gets sent out to the author to ensure that the plugin is still being monitored. Even though the plugin may be doing one very specific and simple task things change, functions get deprecated, standards get updated. Then the author will have to reply or respond back that they indeed are still active and do monitor the plugin.

        If there isn’t a reply after a certain period of time the plugin should be considered abandoned.

        • I disagree with your “reply or be removed” suggestion because, as you concede, a plugin could be doing something simple. It could be doing it in a future-proof manner. If the developer is no longer monitoring that email address it would be unfair to deprive people of the plugin.

        • Agreed.

          At least there is that warning, but I see no reason that even if the plugin doesn’t need any changes, that it shouldn’t be looked at and verified every 2 years.

    • Plugins that have not been updated in more than two years do not show up in search results.

      One exception: exact name matches. An exact name/slug match on the search will show the plugin regardless of age.

      • Worth noting that that doesn’t “hide” them at all though — they still show up in external search engine results. I don’t know the stats, but I could easily see half or more of plugin page visits coming from Google.

        Would adding a noindex tag to old plugins be overkill?

  2. The more time that goes on without a plugin being updated, the lower the chance of it being updated, but… there are also a number of other reasons that plugins don’t get updated, and some (but not all) of these are due to strengths of WordPress and the ecosystem, rather than just weaknesses in the repo or the developer.

    Moving on isn’t always bad, it can just be the recognition that things have changed in the landscape over time. In the years after a plugin is released, core continues to evolve, and features can make their way into core that make the plugin obsolete. There are also many plugins that exist for the same type of functionality, and at the time of creation maybe there isn’t a clear winner (not that a single one is needed). Common examples would be galleries, sliders, custom fields, term meta, social buttons. Over time, a handful gain marketshare, and it only makes sense that others fall by the wayside, unless they contain niche functionality that truly differentiates itself and is used by a group that needs what it is offering.

    With best practices and use of OOP only becoming more popular in the last few of years within the wider WP community, I’d be surprised if many of these old plugins make use of them, and over time I think it likely that many of those plugins reach a point where it becomes difficult to iterate without breaking the world for others.

    At the same time, it’s not fair for me to jump to that conclusion without seeing data to back it up.

    It’d also be interesting to see the percentage of plugins that are never updated after being added to the repository, as these probably skew the data quite a bit. Not that these plugins should be discarded from the statistics, but this is also a group of plugins that were never actively maintained/updated to begin with.

    • At the moment, all the talk seems to be of “coping” and “not coping” and “the valiant job that’s being done by unpaid volunteers”.

      Not to take anything away from them, at all, but I think the suppository could become vastly more important, helpful, and valuable, if only there was the will to make it so.

      The amount of real, live, market information being generated every day is so incredibly large and important that it beggars belief there isn’t one single person associated with with Automattic or WordPress Org that has the sense to find a #1 and tell him/her “make it so”.

      I guess there’s none so blind as don’t want to see.

  3. I agree that there are lots of reasons why this could occur, not all of which are necessarily bad on their own. However, I think we could use a few metrics combined to narrow in on potentially unsupported or poorly coded plugins: length of time since last update, length of time since last support response from plugin author(s), plugin author activity (or lack thereof), and depreciated functions.

    As a bottom-of-the-barrel check, if you raise all those red flags I think it would be worthy of an emailed notice to the plugin author and a phase-out of the plugin on the repo. Say, 30 days after the email it gets removed from the repo unless the plugin’s issues are addressed and updated.

  4. I just released a plugin a few minutes ago that may never receive an update unless I messed something up or core WP completely changes this feature. There’s only a few lines of code and the plugin will only ever do that one thing. I actually have a few plugins like this and use a couple from other devs.

      • All the update has to consist of is changing the supported version in the readme.txt. Easy enough for most. I do recommend testing first, of course. With whatever means you test with.

        • Otto, I don’t want to get into the GIT vs SVN discussion, but for me it is just the need to figure out again how to use SVN which prevents me from doing that. If it was git it would have been easier since I use git all the time and SVN only for plugins.

          Anyway, some backend feature that will let the plugin author to easily update the version from his wordpress.org profile will make things easier, at least for me (you can even put links to update the version in that automated email I just received)

        • I second Justin and Mark K.
          I have now just 2 very old plugin in the repository (in the years I removed the others because they where superseded by core’s features or better plugins).
          One of this is a very very simple shortcode that probably will never requires an update.

          An easy way to udate the “tested with…” part directly from the wp.org profile page would be very useful and could help solve the problem.

          On the other way I have to say that now I’m using only GIT and having to delve in SVN just for the WP Repository is really stopping me to releasing new plugin.

          Stefano

      • It doesn’t really bother me that much. I’m just too lazy to go through and update the readme for all of them. :) I need to build some type of automated system for that.

        • How would it defeat the purpose? I could just run a script to update the “tested up to” line to the latest version of WP. That’d be the same as me SVN pulling every plugin I have, opening the readme.txt, and manually typing it. The only difference is that an automated script would save quite a bit of time.

        • Hey Justin, sorry maybe I misunderstood (as I’m not a developer). I thought you meant an automated way for the version to update and keep from falling over 2 years old.

          I’m all for making a system to make developers’ jobs easier! (I used to work in data operations.) :)

          What I meant is that for a version update, there should be some testing or verification of compatibility involved, not just updating a number in the readme. If devs had an easy way to just update that number, without some kind of other checking involved, it would defeat the purpose of users relying on the last-updated date as at least some indicator of attention from the developer.

          We often don’t have a whole lot to go on… so we need *some* kind of metrics to judge by. That said, if the system is so convoluted many developers just walk away from it, that defeats the purpose as well!

        • Yeah, we’re just talking about an easier way of saying, “Hey, the plugin works on this new version of WP.” Nothing more than that. This is different from bumping up the actual plugin version number. Right now, it’s a huge pain doing that if you have a lot of plugins.

        • It’s ultimately about trust for the user. The best way to do that is to make sure developers have easy-to-use tools.

          It sounds like the WP repo needs some sort of system to help developers. I’m no person to update it but say after a couple weeks or so on the heels of a new WP release, an e-mail goes out that says something like:

          “As the author of xxx plugin, can you confirm compatibility with WP x.x?” with maybe 3 options:

          * No known issues with x.x
          * Broken, last known version that worked was…. [dropdown with wp versions]”.
          * Haven’t tested but we don’t expect any major functional or rendering issues”.

          Well crafted, simple plugins could easily choose the first option. You click confirm in the e-mail and it gets updated, so no changing readme files, etc. It’d be like validating whether an e-mail is valid with an account, child’s play.

          Maybe the system could detect that simple, 1 file plugins could opt out of this as well. And maybe point releases of WP could automatically get updated too or run some kind of automatic linting against the latest version.

  5. Guilty, as charged. I’m in the camp of losing interest on some and also finding myself with little time to devote to continued development at this point in life.

    • Fair enough… but I guess the point would be whether older, unmaintained plugins should be listed. Maybe they get listed in a place where people check a box to display in the results, knowing they are ‘dead,’ but possibly still useful?

  6. This is perverse.

    We know almost exactly how many and which plugins are *NOT* updated to work with the current revision level of WordPress, but what we don’t know is, how many are, and which do.

  7. AFAIK wordpress core haven’t removed yet any deprecated function since 3.4, therefor every plugin that worked at 3.4 should be working at 4.4 as well. The 2 years limit is just an annoyance to the authors and it is not like there was any research done when setting it up.

    wordpress.org with the usage stats have a much better heuristic to work with then just the 2 years arbitrary number. If people keep using it then it is compatible enough, end of story.

    As for “if a plugin is not update it is not worthy”, that has to be a joke. Good plugins fully contain all the functionality they intended to cover so why should they be updated if they were written with best coding practice in mind? Why should a google analytics plugin from 8 years ago be updated?

    On contrary, too many updates create the update fatigue and too many times update change and even break functionality. The only reason to install a new plugin version is if it is a security update, otherwise I don’t care that much that there is an update at all.

    • Mainly I agree with you, but as for ~ “if a plugin is not update it is not worthy”, that has to be a joke. ” ~ I didn’t say that, and I never would, of course.

      But only a Dev would react to that idea in the way you have.

      Its “people” that are at the heart of which plugins are used, not the metrics or which is likely to contain more or less deprecated code.

      Your average Joe type “people” looks at the suppository, sees one simple statement and says ~ “ah yes, that one’s up to date”, or “oh no, that one hasn’t been touched in years”.

      People.

      Not code.

      • Well, maybe it came out wrong but I did mean that the metrics of havn’t been updated in X time is not really useful to anyone.

        • I suppose a more complex method could/should be figured out, but IMO, it’s at least a good *minimum* determination.

          I suppose there are copyright issues, but it would be nice if it worked a bit more like domain names. If you aren’t there being active and ‘renewing’ within a reasonable interval, they go away or are given over to someone else. (Or, maybe active involvement is just a qualification of being listed in the repository.)

          Another factor might be if the author has recently interacted in the support threads. That’s something I often look at when evaluating plugins/products. I also look at how the author is interacting, but that would be hard to measure without human curation.

          But, IMO, this is a bit like the old Mac vs PC battle of how many apps are available. I’d rather have 100 great apps than 100,000 where most of them just get in the way of seeing the 100.

          • Historically the repository was design to be a … repository, and not a plugins quality evaluation service. It developed over time with strong pro user bias which sent many developers away from it because they don’t care that idiots will give them 1 star with a comment “it didn’t work” and complain about not getting support they didn’t pay for (not directed at you personally). Right now the repository don’t give anything to the developer, even the support forums that you talked about do not send notification to the developer when there is a new posting…..

            WooCommerce do not give support,yoast does everything on github, so which plugins are you exactly using? The more limitations that will be imposed on authors the less interested the authors will be to doing anything related to the repository.

        • Copyright issues might affect whether a plugin would be able to be offered to the general public via the suppository, but don’t really impact on the length of time it can stay there. That’s purely an operational matter.

          A total cull of all “unsupported” or “dead” plugins ~ whatever that means ~ could be organized within an hour or two, and implemented in a flash.

          That’s if the committee that decides on these things, could defecate or get of the receptacle.

          The problem is ~ it seems ~ nobody cares enough, is smart enough, or ballsy enough, to step up and grasp the issue.

        • Terrance, I mean the domain-name-like behavior of transfer to new ownership. While I know that would be hard to apply to code, I was just thinking how that might get rid of all the ‘X plugin revived’ type stuff… the original could be updated so there would be less ‘noise’ in the repository.

      • Mark…. which ultimately makes it *not* user-centric OR developer-centric! If developers get frustrated with it and most go elsewhere, the users lose. If the info isn’t reliable to the users, the users lose. If enough users lose, the developers lose too.

        It’s like this comment system… even with 3rd party support, ti’s not very user-centric. How many years old is WordPress now? Isn’t blog-commenting a fairly central feature?

        • Steve, the developer gain nothing at all from having his plugin on the repository. The graph actually shows the current disinterest developers have in the repository, as with half the plugins being obsolete you would expect that there will be a lot of forking and therefor more new plugins, but this year is going to be maybe just a little better then flat.

          The disinterset probably come also from higher barrier to entry than on github, but also from competition from code canyon. Why would anyone submit a plugin to the repository where he will do no money while at codecanyon he can at least have the illusion he will.

          As for comments…. this is part of the big discussion on how core developers became disconnected from all wordpress users, with 4.4 having no feature at all for the blogger or SMB. REST API, oEmbed, srcset are features that maybe big organizations want but no one else (having them is a “nice to have” but is not a reason to upgrade).

        • I didn’t necessarily mean money, but whatever the point of their developing the plugin was in the first place (i.e.: community involvement, moving the platform forward, getting exposure, giving users a taste of their other (maybe paid) offers.)

          If the plugins aren’t kept up to date, known to be good, and then used, about all they’ve accomplished is maybe learning a bit more about coding. If that’s all they wanted, then why even publish it?

          • @steve, why people do things? so many reasons….

            The issue is that it is easy to add a plugin to the repository (or to any of the pay markets) but people rarely realize that the support is an essential part of software development and it takes much much more time and effort then the actual development took. Some people who do realize it still release the plugins because it might be helpful for someone even if not supported.

            You can see that sometimes even companies (yes cloudflare, I am looking at you) do not support their plugins as maybe priorities had shifted for them.

            I don’t see any way around it, if you need a long term support for a plugin you should have a binding legal agreement with the author which usually means paying, something that people don’t like to do when they can get the code for free. Otherwise you might get the amount of support you paid for.

  8. I am also guilty. I haven’t updated a number of my plugins for months now.

    The reason for most plugin abandonment stem from my experience is, most developers have a full time job or have a WordPress (premium plugin/theme) business that they run.

    Finding time to update their free plugins could be difficult more so when they have to familiarize themselves with the code-base before making any update.

  9. I think a lot of it has to do with the repo. SVN is a bit difficult to learn in some ways. I have 2 plugins in there and it is a bit of work to update.

    Maybe take some notes from Drupal Modules. A lot of them can be taken over by other devs so it can continue or even a company that is using it. Overtime very old version do get depreciated because Drupal has a new version.

    So maybe WordPress should have a cutoff version where any old ones that don’t support the new version just don’t even show up .

    Just my thoughts.

  10. There’s also an issue of effective plugin account management on wordpress.org that could be contributing to the number of inactive/abandoned plugins.

    Plugins that have not been updated in 2 years don’t show up in the main directory (apart from an exact name match), BUT they do still show up in the list of plugins on the authors profile page.

    Plugins that have not been updated in 4 years don’t even show up on the plugin authors profile page!

    e.g. https://wordpress.org/plugins/touch-punch/

    I have a few plugins such as this one that really need deleting but I’d completely forgotten about because they are effectively invisible (to me as the main developer).

    Also, I’ve discovered at least one plugin that I originally registered for back in the day but never even made an initial uploaded.

    e.g. https://wordpress.org/plugins/clear-inactive-widgets/

    I suspect there may be more than one of these but I have no way of checking. I can’t even remember how this happened now. Perhaps you could once register for a plugin name without making an initial upload?

    I’m wondering if plugins that fall into these categories are included in the 41,380 plugin count, or is it only plugins that have been updated within the last 2 years?

    Plugin and theme developers (like everyone else) are pretty busy people on the whole and it can be difficult to set aside time to manage/update free plugins. It would significantly help if this process was made easier on wordpress.org.

    Here’s a couple of things I’d like to see:

    Plugins not updated in 2, or 4 years (or never activated in the first place) to be visible on my profile page and highlighted in some way.

    Tools made available to DELETE plugin repositories (rather than just hide them) or a way to notify admin to add plugins to a deletion queue (obviously this is only applicable if you are the sole plugin contributor).

    • More should have been done with the adopt a plugin idea. New developers could take over unfinished plugins or those which get stale. It would let people learn, hands on and keep more plugins active.

      Could there be a check box to release a plugin into the wild if the original dev isn’t keeping it going (for whatever reasons)? They could all be listed in a subdirectory of the directory, like a plugin garage.

      • I love the adopt a plugin idea, as I always hate reading about past-great plugins and then seeing all kinds of forks and new, improved, revived variations.

        I’d much rather someone new just took over the project and kept building that one plugin’s status and effect.

    • Yes, I remember that before you could just sign up for a plugin name and add a description (or readme.txt file) of what the plugin (idea) was supposed to do.

  12. Impossible to quantify, but I’d bet that plugins that exist only as Git(Hub) repos have a shorter average time-since-last-update than those on the WPORG repo. I know mine do.

  13. Well, I have 3 plugins on the repository, from 1 or 2 years ago, and all of them work perfectly with the current WP version. Actually, they are pretty simple.

    The reason why I did not update their readme.txt? Laziness + SVN nightmare.

    Each time I needed to upload those plugins to the repository I had to go through tutorials, forums, videos…a bad experience. And I can’t remember the process, so if I want to upload an update file, I think I will have the same headache.

    Wouldn’t be good if there was a simpler way to update the readme.txt file? Like a simple form or something?

    • Use from time to time the only command

      svn ci -m=”version compatibility update”
      vs
      git commit -m=”version compatibility update”

      from the plugin trunk folder is not too complex.

      From other side I keep some my plugins without version compatibility update also and the reason is not SVN “nightmare”. I don’t support them actively and I don’t touch them while I know that they work correct.

      • You do realize, as a user, that’s one of the top things I look at when picking plugins? I often look at when it was updated, and the look at the support area to see if the author is interacting. Functionality comes in 3rd. If I really, really need some functionality… and can’t find some other plugin, then *maybe* I’ll use one that hasn’t been updated or supported recently… but I gotta be pretty desperate.

        So, IMO, you’re wasting your time unless you just enjoy coding for fun, if you don’t keep things up to date and interact on some basic level.

        • 100% agree with Steve – on both business and private WP installs, first thing I look at in a plugin is date of last update.

          Obviously there are a very few where I don’t, and just automat(t)ically install – akismet, jetpack, and my favourite SEO, gallery, and contact forms plugins.

          But for anything else (including themes) I check the author’s maintenance of them first. If it’s a new function for a specific site (e.g. a membership or newsletter plugin as installed this month on a new site for a client) then anything not marked as working with current WP version is immediately ignored and only the most recently updated plugins considered for use.

  14. Sorry but if a plugin dev is too lazy to even update the readme then the plugin should be nuked. That dev is not worthy of having their plugin listed. Period.

    • Try to step outside that box where all plugin devs only have 2-3 plugins to maintain. Keep in mind that some of us have to change a line in the readme.txt and SVN commit about once a month for 30, 40, or more plugins just to keep that “tested up to” version correct.

      • If that’s such a hardship for you then maybe you should stop developing plugins.

        How about focusing on the end user for more than a nanosecond?

        • I think I’ll just continue building awesome stuff and helping out the millions of users who are a bit more grateful for the contributions that I and other plugin authors make.

        • While it sounds harsh, I’d agree. If an end-user can’t depend on some level of quality and commitment, then maybe it’s better not being listed somewhere users might trust (the developer can always publish it on their own website if they want).

          While I’m not a coder, I have been involved in various volunteer efforts. While no one likes to put quality-control in place for fear of losing volunteers… if it isn’t there, the effort sometimes may as well not exist.

        • Your comments are unfair. I hugely appreciate the plugins developers share on the WP directory. I know it must take quite a lot of their time and resources to keep those free plugins maintained (as well as bringing in new features on top of keeping them working). No one should be bashing them for not putting more time and energy into free plugins.

          If you want more quality and commitment support the plugins. At the very least vote up what you like and use and give a thank you note in the review you post. If you can, or want to, donate to the development of the plugin. Or, buy the premium version after trying the free version.

        • For the record, I have bought many $1000s in plugins and templates over the years.

          I’m just tired of devs whining about not being appreciated for their “free” plugins (more often than not they’re just crippleware disguised as “free” anyways – the Yoast garbage comes to mind).

          My comments are only “unfair” to those that can’t handle the truth.

        • Steve, I actually agree that users should have some level of assurance that a plugin might work (as much as possible in such circumstances). That’s an issue with the system. I’d happily talk about ways of improving the system.

          I’m just hopping in this particular thread because some folks don’t seem to know how to have a civil conversation about the issues.

        • Quality vs malware is a problem in the plugin directory. They don’t get the checking over which themes do these days. I would like to see plugins be less risky in that way. Even when I buy a plugin I’m concerned about what else is written in the code. I think it’s getting better, more or less.

          You’re one of the very few I’ve ever heard say anything less than great about the Yoast plugins. I agree. They are pushed a lot but I found them to be bandwidth hogs and not much really useful.

        • @Ron

          Vetting what plugins to use will always be on the onus of the user. Whether a number is incremented or not, if you are not vetting the plugin and an issue occurs that is laziness on your part. If you are vetting a plugin, that number incrementing with a new release won’t mean much because a dev can increment while being unaware of issues.

          What’s important is the developer proactive enough to fix big issues if they occur? For that vetting a plugin properly is important, researching what the developers are like is part of that. If you do your homework on Justin as an example, you probably would not use the word ‘lazy’.

          But I think you touch on something interesting that maybe hasn’t been articulated well around the expectations of users from developers and what expectations to levy on freely submitted plugins and themes in general. And maybe more so the language that comes out of these exchanges that tends to reflect negatively on developers and how that contributes to a crappier environment, to the point where it turns devs and would-be devs away from submitting work all together.

        • @ Peter

          This point goes back to some of my earlier comments on volunteers… but free is overrated. :)

          I’m not saying I don’t *greatly* appreciate all the free plugins and volunteer effort that goes into the WordPress community. But, if that results in a ‘well it’s free so I’ll not care if it’s updated or support it’ kind of attitude, IMO, that hurts rather than helps the community.

          I know all too well that life changes, and thing come up. I’ve had to walk away from things I’ve volunteered on in the past… and a few times, even without a smooth handoff (which I’m not proud of). But, I’ve also seen enough volunteer work that may as well not be happening at all, as it was of such low quality, it was hurting more than helping. (Totally different fields… but I think the same applies to WordPress as well.)

          The point is… for WordPress to be strong, and the repository of plugins being worth having (aside from a huge number for marketing purposes), there needs to be a certain level of expectation and commitment, yes, even with free and volunteers.

          When I’ve worked with volunteers in the past, that means some (many?) of them just walk away… and I have to be OK with that. That might mean the program fails… but IMO, better to fail than do it too poorly.

          I don’t think WordPress is there. There is a lot of great stuff out there. But, I still think that principal applies. And, maybe the plugin repository should be 1/10th its size, but 10x the quality if one were to just take random samples? From a user perspective, I’d be happier with that. But, I’m also a Mac user, so I’ve seldom been impressed with raw numbers and specs.

    • Well, I don’t make a living on plugins. My goal was only to help others and give back to the community.

      And if I am “not worthy of having my plugin listed”, that is fine. I will understand.

      But remember what I said. My plugins work fine with WP current version. I would not neglect un update if wasn’t so. That is why I am proposing a simpler way to update just the readme fine.

      Anyway, you don’t want to discuss. You want only to express your opinion. I can see by the “period” at the end of your message.

      • If you know the plugin works, and what is keeping you from ‘updating’ is the system, then I totally agree, it’s a system problem. As users, we don’t see that aspect of it… so if that’s the case, maybe we need a developer uprising to get a better system put in place. :) (At the same time, there are a lot of plugins where the dev hasn’t stopped by the support area for years too.)

        Maybe someone can help me here, as I’m a bit new to the politics of WordPress. Everyone goes on and on about it being open source and community driven… volunteer effort, etc. This or that can’t happen because there isn’t enough interest behind it… or xyz isn’t happening there isn’t enough leadership and direction.

        But, certainly Automattic has some money, right? If there are hurdles in the way, damaging the efforts of all this volunteer work, it would seem they are shooting themselves in the foot not to fix it. Fixing stuff like that and providing the vision and leadership shouldn’t be part of the volunteer effort, IMO. (At least I’ve never seen volunteer effort succeed without it.)

  15. I still use and try out the old plugins. Many work well and have nice features which tend to be kept for premium versions more often now. I use them until they stop working.

    I’ve been slowly learning more coding with the idea to adopt some of my favourite old plugins and make them work again. I’m not sure what the right thing to do is when I can no longer track down the original developer for the plugin. But, I’m assuming no one will mind and nothing will blow up from my fiddling around with them.

  16. I teach a web design class using WordPress. It was pretty aggravating when the plugin I told the class to use to import all of the class members as subscribers became invisible. Getting them to type the exact, long name to find it was frustrating for many of them. Alternate plugins varied wildly in terms of features and usability. Maybe there could be an easy way to refresh still functioning plugins. Perhaps a crowd sourced approach?

    • @Paul

      Maybe should explain to your class that ~ with 40,000+ plugins, and who knows how many themes ~ however you slice and dice them, you’re still only going to be able to trawl through a tiny fraction of what’s available in the directories.

      This kind of automatic retirement is essential.

      As it turns out I am working on project which does the very thing you have suggested, and I hope to be able to announce it very shortly.

      But its a complex issue requiring sensitivity of both the developer’s plus end-users’ rights and wishes, workflow and technical issues involved in cross-platform development, and an on-going dialogue and involvement with the people who give up their free time to manage the directories.

      But don’t forget, even with all that in place, it also requires the development of a very simple way for the average end-user to be able to update from abandoned plugin/theme A, to adopted plugin/theme B.

      And as far as I know, even with 40,000+ plugins in the directory, that’s never been tried before.

  17. The whole unpaid volunteer thing…

    Technically speaking if the unpaid volunteers that check the quality of plugins/themes were paid then they wouldn’t be volunteers.

    The definition of volunteering is essentially…doing something without an expectation of getting paid.

    • IMO, the whole unpaid volunteer thing doesn’t work (at least not totally on it’s own).

      I’m trained in Christian apologetics. I spent nearly a $half-million (in lost wages and tuition) getting there too. I haven’t made a dime back (partly my own failing… but the point is that the discipline is – at this point in time – mostly a volunteer ‘job’ which is vastly under appreciated by the church.)

      I bring this up, as I think it’s somewhat parallel. I *love* Christian apologetics. I spend a LOT of time studying and writing in the field, for which I’ve earned nothing (maybe a bit of respect, among the criticism?).

      I think that’s a lot like coders. They love the craft. They believe in WordPress as a platform. But, while I’ll do it for free, I didn’t go into it with the expectation that I’d never make any income from it… probably like many plugin developers out there. I’m a teacher, and I had hoped I’d be paid something for those skills and knowledge. (And, naively didn’t expect to have to become so much of an ‘entrepreneur’ for that to happen!)

      But, there are some things *in and about the system itself* which will lead to success for either. Christian apologists (let’s just say ‘teachers’ for the sake of ease of understanding) aren’t going to be properly valued or supported by the ‘organization’ without some buy-in and support FROM the organization. Grass-roots only goes so far!

      For example, while as a teacher, I have a degree, there are a lot of people working in the field who don’t. At some point, some level of quality-control needs to be roughly enforced by the ‘organization’ whether that be degree or expectations being set.

      While all work is appreciated, this vetting has to be there so the end ‘users’ *recognize* they are getting value. The same, IMO, goes for the WordPress plugin community. The repository *should* be that kind of gate-keeper.

      And, there should be some proper level of support from the ‘organization’ to help increase pay or opportunity for pay (set a recognition for value at least) within the larger community.

      And, there should be some level of leadership and ‘systems’ being put in place by the ‘organization’ to help both quality control and value recognition.

      In observing the WordPress community, it seems that those are somewhat lacking from the parent organization. And, if that’s the case (as it is in Christian apologetics), it’s going to be a struggle, without much ‘payoff’, and a lot of effort being wasted in overall impact… not for the lack of trying, but with a lack of impact.

      Is my parallel a faulty one? Is Automattic giving a proper level of leadership, value opportunity, support, and systems? It doesn’t seem so, from my admittedly outsider vantage point, especially with our ‘systems’ discussion here.

      The repository shouldn’t be something the developer community has to figure out how to improve and implement. And core WordPress functionality (like the comment system I keep harping about) should be driven (and funded) by the parent organization when necessary.

      Maybe I’m just not enough in the know… so sorry if I’ve overstepped my bounds. But, this is the impression I’ve gotten as I’ve started to pay more attention to the WordPress community.

  18. We all get the “keep your WordPress updated” speech all the bloody time.

    Shouldn’t WordPress lead by example, practice what you preach?

    There should be an option when we search for a plugin/theme and have the option to pick that the results show plugins/themes that are compatible with our version of WordPress. I am NEVER going to install a plugin/theme that hasn’t been updated in 2 years.

    According to WordPress entry on Wikipedia…3.6 and before are versions not supported.

    3.7-4.2 being older but still supported

    Two years ago follow between 3.7 and 3.8

    Anything older than two years should be deleted. If you like an older plugin, fork it and update it.

    I personally don’t think there should be any plugins/themes that are not up to date for at least 4.0 (3 versions before current version).
    4.0 came about 14 months ago.

    What about big bug issues, we had that over the past 2 years. How many of those not-updated in 2+ years have security bugs?

    • I absolutely agree with you 100% when you say

      There should be an option when we search for a plugin/theme and have the option to pick that the results show plugins/themes that are compatible with our version of WordPress.

      The rest I am not so sure about.

      What I can’t understand is, why ‘apparently’ its so hard to add this to the current set of filters.

  19. Peter Knight,

    Technically speaking Justin admitted him being “too lazy”. Look up

    PLEASE NOTE I AM NOT BEING SERIOUS, JUST SPLITTING HAIRS ON A TECHNICALITY.

    • I think that’s maybe more in the context of, “too lazy to care enough about some broken metrics of a broken system to jump all the necessary hoops…” not too lazy in general. :)

      But, the point I’m trying to stress is that those are the metrics users are using. And Justin is right that the onus falls on the users to do the research, beyond those metrics… I know that’s the reality… but I guess I’m questioning if that should be the case.

      IMO, it is Automattic that should be putting in the effort for their vetting system, unless the goal is to just have a big number of plugins for marketing purposes.

  20. Just out of curiosity, from people who have gone through the process of plugin submission & updating, what is the rule for updating version numbers?

    I ran across a repository plugin dev who kept updating his plugin but not updating the version number so I had no idea for months that his plugin was coming out with incremental improvements.

    When I called him on it in the support forums, he said that the changes he was making were minor, and he had no reason to increment the version number until he’d made enough minor changes to warrant an actual version change.

    I stopped using his plugin and went looking for a different way to get the functionality I was testing out.

    • That’s pretty much what all developers do. You make incremental changes. When the time comes, you tag it and make a new release. Now, it’s just common to use a version control system outside of WordPress.org (like GitHub) and then just push the releases back to WordPress.org.

    • I must admit I’d never seen that before, where a dev makes incremental changes to a plugin (noting them in the changelog), but doesn’t increment the version number (say from 2.8 to 2.8.2 or something) and makes about a lot different changes but never changed the version number in the repository.

      Another user in the support forums even made note in of the fact that a firewall flagged his plugin with a warning since the files in the repository were different. I think he finally made an official release update after that and has been more careful of changing files since then, but it just struck me as odd, making incremental changes in the repository files, but never incrementing the version numbers so that people’s WP installs would let you know there was a plugin update.

      That lack of update notice inside my WP site was what made me notice that I’d missed three months worth of updates he’d done simply because he didn’t increment the version number and kick off whatever feature it is that lets folks know that a plugin update is available.

      He seems to have modified that habit since 6 months ago or so, so moot point now.

  21. I agree that this is an issue. I like the archival idea, but also agree that plugins still working without updates shouldn’t be archived. I’m sure there would be volunteers willing to test for some sort of kickback or backlink or backkick (heh) but you get what I’m saying…

  22. I think that there are two things at play here: Plugin developers who lose interest / desire / move on, and the lack of clear deliniations and steps in the wordpress development system.

    The first part is easy. Developers move on. They had time when they were in school, but don’t have time when they are working. Or they have time, but they are putting it towards their own design business and not making it easier for everyone else. Perhaps they got tired of the constant need to try to keep their plugin compatible with an endlessly moving code base target.

    Thus brings us to point two, the lack of a solid version steps in wordpress.

    Normally, the big numbers of version indicated a new code base or significant new developments. That is a clear sign that the target core has moved. Instead, WordPress has sort of constant evolution, patching and changing and adding features, deprecating functions, and so on in a sort of random way. Making significant changes (such as the customizer, deprecating functions, and the like) should be done at a X.0 level. Making those things a .1 different (and often combining it with security patches) means that it’s hard for developers to stay on target.

    My belief is that WordPress needs to:

    (a) set 4.4 as the final version in the current development process. Issue ONLY security patches as need be and declare 4.4 as a stable version. Go through the plug in directory, contact everyone involved, and give them the change to bring their plug ins up to date. Making everything possible 4.4 compatible, and if not, remove it or otherwise make it available in an archive of “untested extra plugins”.

    (b) Begin work on version 5.0 of WordPress. Take a big step back and consider ALL of the code and all of the functionality, and consider what is best without as much consideration for the past. Clean up code, fix issues, add a pile of new features, clean out ALL of the old, no longer supported legacy stuff, and generally build a new wordpress from the bones up. Make sure it all works, make sure you are happy with the concepts, and let the developers in on Beta to start working on 5.0 compatible plugins.

    At that point, WordPress has a legacy 4.4 version that would be security maintained for say 2 to 3 years, and a new 5.0 version with all the toys, all the bells and whistles, and none of the legacy stuff to get in the way. New themes, new plugins, new style… take a bold step.

    Honestly, trying to clean up the theme and plugin libraries and backlog of submitted stuff may be a losing battle.

    • Well as a User and a Dev that’s not workable at all.
      I can just imagine ringing my clients to explain that WordPress 5.0 is not backwards compatible and they will have to buy/get a new theme, all new plugins to replace the ones they use (assuming a plugin actually exists for 5.0 to do the same job) and of course the some 20 hours of billing while I rebuild there site on the new platform.
      A much better solution is to improve the system for changing version numbers, it’s a reasonably simple exercise and as has already been stated it would make the Dev’s lives a bit simpler so they would actually do the update to the version number. I understand the frustration as It drives me rather nuts when something I wrote for free then requires a dog and whistle show to update a version number.
      I also totally support the idea of a dead plugin bin were Dev’s can adopt an old plugin and make it viable again.

      • David, I am not sure which is worse: Telling your clients that there will be an upgrade “if they want to do it” that will cost 20 billable hours, or dinging them for double that each year mitigating the problems caused by minor updates that change, break, or otherwise make wordpress not behave exactly as it has in the past.

        I am not, btw, suggesting a totally new incompatible platform. Same house, perhaps with better plumbing and with the older code retired, new features added, etc. The other part is about establishing a stable supported version at 4.X so that if your clients don’t want or don’t need the 5.x feature set, that they could remain on 4.X and continue to receive security updates as needed. It wouldn’t be a development environment, but would provide a proper end point for users and sites who need exactly that – a stable environment. WP could then support 4.X for a period of time, say until the release of the 6.X series in a couple of years.

        It would certainly allow everyone to work to move forward in a nice solid leap, rather than shuffling forward until things break.

  23. Justin made clear how to solve the issue for legit but aging plugins. I had stopped commenting in these types of threads because far too many are trolling for lack of anything positive to say. Lesson reaffirmed.

  24. All the talk above about removing unsupported plugins misses an important thing here: WordPress checks for plugin updates, and if it can’t find the plugin in the repository, it just assumes it’s up to date.

    Until such time as the repository and WordPress itself can show that a plugin has been removed and can no longer be assumed “safe”, old plugins should stay in the repository and simply display the “hasn’t been updated” message. That also allows users to continue logging issues in the support forums, which can serve as a warning.

    As it stands now, when a plugin is removed from the repository due to a security vulnerability, any sites using that plugin can carry on using it with no indication that it could compromise the site.

    IMHO, this is a much bigger problem than some old plugins that haven’t been patted by their authors for a while, but still work. I mean, it’s not as if a plugin being new or even receiving updates is any indication of its quality, eh?

  25. Wouldn’t it be amazing if someone would go in and delete those plugins. I would like to think that after that amount of time, they are not going to deliver anywhere near their desired performance with any current version of WP.

    Plus I think it would provide a greater level of space for new plugins and ones which are delivering to their expectations as well as being updated on a regular basis. Just a reflection of my thoughts.

    Thanks Jeff for your amazing work on the WordPress Weekly Podcast. I truly enjoy listening to you and Marcus. Keep up the phenomenal work on both sides of the community.

  26. You’re right, this is a real issue. It’s frustrating to spent time researching plugins when so many of the plugins I click on haven’t been updated in over 2 years, it wastes a lot of time and makes it harder to find the right plugin. It would be good if the plugin repository on WordPress.org had a better search with the ability to filter out sort the results by date updated, rating etc. I would also like to see plugins being removed from the repository if they’re not updated for 2 years, as other commenters have said. That would fix the problem immediately, encourage plugin developers to continue supporting their free plugins and leave hair which will encourage other developers to fork or replace older plugins that are no longer supported.

    • True, this is a case where too much choice becomes a hindrance. Sorting plugins by number of updates might help although there might be some plugins that are still working fine after two years without updates.

  27. With so many plugins in the Repository, I suppose it is extremely difficult to keep up. However, that being said, it would be great if they could find the really old ones and maybe move them to like an “Archive” type page so they did not populate on the front side (if that made any sense?)

    I realize that many of them do still work, however, we all know as things roll within the WP network, there will come a day when they die or cause a site to go down.

    I would like to think that as a developer of a plugin, you would want to keep them updated and certainly if you were thinking of taking them to the premium level. But who am I? I just love to design in WP and the thought of delving into the plugin or theme development arena just makes my nerves come unhinged!

    But kudos to those who do keep their plugins and themes current with the latest WP releases.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: