Over at WP at every new version release, plugin authors receive an email with a list of their plugins and the question to simply update the readme.txt file to reflect that the plugin is still valid for the new WP version.
Depending of course on the number of plugins an author has to its name, those should take no more than a few minutes of one’s time.
However there are still many many plugins whose authors cannot be bothered for some reason.
In the WP Plugins Directory the plugin that has not seen an update for more than two years, receives a warning.
I would like to propose to have plugins that do not receive regular updates removed from the Plugins Directory.
Of course this needs to be a bit further nuanced, because there are plenty one-liners out there that really do not need anything else. In such cases the plugin should however receive an update when a new ClassicPress version is released.
In case of plugin removal, it would be great - but I am not sure if that is possible at all - to release a version of the plugin that warns the users that have this plugin installed, that the plugin is abandoned and to suggest looking for an alternative.
I think something on these lines was discussed already in the plugin directory rule discussion. Adoption of abandoned plugins was discussed as an option. I think if a dev doesn’t update at least the readme for two iterations, plugin can show a warning stating it’s up for adoption. Then after third iteration it can be removed, and kept as a “private plugin/hidden” until a new dev adopts it and moves it forward.
I don’t feel that adoption and what I propose are the same thing.
The idea is to get rid of the stuff that was “invented” on a whim. If we would leave all that “garbage” in the Directory waiting for a new dev to adopt it, then that is the exact opposite of what I had in mind: a clean directory with plugins that are regularly looked at and refreshed.
Because we are using Semantic Versioning I think it should be across major updates.
A plugin for example that works on V1 should work on V1.9.9 so there is no reason to force the author update it every time. Yes, ideally they would but I don’t think their plugin should be removed if they don’t.
But then, why not just classify plugins as working with Vx and leave it at that. Then if your install is on V3 you won’t be shown plugins only working with V1.
I think first of all we miss both a point. A clean directory is not loosing diversity.
I am with you on clearing clutter away, but let’s think a minute…
Let’s say I fork buddy press on my own. At a certain point life gets in the way and I do not update readme file just once. Consider my plugin is buddy press, active on a gazillion cp installation. Your idea is to remove it? Something like “sorry, buddy press is dead?”. No. I don’t think so…
What if the directory notices I haven’t updated once and nags me to do it ASAP, then second iteration without update directory nags me and shows a big warning in red “abandoned plugin. Up for adoption. Use at your own risk. Be removed in 60 days for safety reason.”? You do not risk to delete a big plugin used by many without fighting to find someone to keep it alive. You give dev two chances to update. You give option to new devs to show up and shine. I think crappy plugins won’t attract nobody to keep them alive, so they get removed.
I don’t think we should remove as that hides code that others could adopt and update.
I tried to adopt a plugin that hadn’t been updated for 9 years (refused by mods as the dev was a core developer); the code needed minor tweaks to make work, but if it had been removed I’d never have been able to update it.
Another thought: make searching by version very easy (e.g. default admin panel search to the installed version) so older/newer plugins do not show by default.
I like the idea of searching by versions. If a plugin isn’t going to work on my version, I don’t need to see it at all. Plugins should be able to declare what versions they support, though, not be locked into a single version. There’s lots of plugins that work across many versions.
To add to the discussion. If I remember correctly, CP plugin directory will pull code/zip file from developer’s GitHub repo. So we’re not hosting any code, unlike WP repo using subversion.
So, if plugin is outdated, at a certain point we can label it “Outdated” or “Inactive” or something like that, which will prevent users from downloading/installing this plugin inside their CP. But, the listing itself on CP.net will remain and can comply with our abandonment policy.
If author comes back and updates plugin, it can be labeled “Active” and everything is back to normal.
I think this approach satisfies everyone’s needs in this discussion
2 years it’s a long time, if something isn’t active developed it can easily became a security problem.
This topic arrised again because of changes that are being done in the plugin install section the plugin API returns almost 60k plugins and this affects the results and the pagination of those results.
IMO linking versions to plugins is not effective. Saying that plugin works for WP 4.9 doesn’t mean it will work correctly for WP 4.1.
I personally don’t have any interest in installing plugins that aren’t updated in the last 2 years, and I think most of the users feel the same way.
Since we won’t be a repository and the repository of a specific plugin will belong to somemone else Github account, I guess the adoption process will consist in a fork to a new github repo.
Picking the BudyPress example, honestly it scares me a bit why it isn’t updated. Removing it from the Directory doesn’t affect the current installs so I guess it’s a good choice to remove something that didn’t changed a line of code in the last 2 years.
I understand your concerns about the need for “constant vigilance”–especially if a plugin is simple and doesn’t need updates.
However, I don’t think it’s unreasonable to expect a plugin creator to check compatibility with updates (I’d say .x updates) and confirm them (at least at the “it seems to work okay” level).
Perhaps CP could create a “value added” feature; a “badge” system that shows Compatible to: cutting edge, most recent (N.x.x.), stable (N.x), or major (N).
Promote “Platinum” developers (those who keep up with the most recent versions) over "gold’, “bronze”, “lead”, etc. Those plugins that keep up to date with the most current versions of CP get higher listings in the plugin directory. This gives plugin devs an incentive to keep up to date–and lets users know which devs looking out for them.
Perhaps add in factors for popularity and longevity (the latter more that the former)?
I love this idea. Incentivizing things works well. On the other hand, it also may lead to gaming the system; some may simply bump their version numbers to get better placement.
On the other hand, it also may lead to gaming the system; some may simply bump their version numbers to get better placement.
Is compatibility entirely based on what the dev says? I don’t know how this works.
Perhaps CP could offer a “certified compatible” verification (for a fee) for plugins? It could generate some income for the project, create a verification system, and make CP look more creditiable to customers.
I don’t think it’s been decided how compatibility will be denoted for CP plugins. With the WP directory, compatibility is determined by whatever values the dev places in the readme file – there’s no official verification of anything after the initial approval of the plugin unless someone actually complains about a bad behavior in it.
I’m not sure. I’m thinking it could possibly open the project to some sort of liability, but legalities aren’t my wheelhouse.
However this policy gets implemented in the repository, notices need to get pushed out to the CP installations so webmasters are alerted to a change in status of a plugin. A plugin I use was delisted a couple months ago and the only way I found out was by stumbling across this support topic.
It would also be helpful if the date a plugin was last updated and the version compatibility was included on the plugins page in the admin. That would make it a lot easier to see quickly which plugins are not being maintained and may need to be replaced, especially when taking over a new site where the owner has installed lots of plugins.
I agree, it would be great to address this. The reason that wasn’t implemented with WP is that anyone with bad intentions could create a website with all plugins installed and just wait for a notice to go out. When a notice went out, it’s a beacon straight to what may, indeed, be a vulnerable plugin.
I agree, badges can be a nice thing. Gamifying process a bit can definitely help, but they need to be shown clearly. WordPress plugin developers do get badges on their profiles, but nobody visits profiles so nobody sees them.
I would also stay away for now from any “certification”.
@rui since CP wants to be democratic and open, restricting users from downloading plugins they want might not be the best idea. It’s reminiscent of forcing Gutenberg on everyone, even though it’s in their best interest. That said, here’s what might work well: What if we add “Safe search” checkbox next to search field and have it checked by default. It will filter out certain plugins: low star count, not updated recently.
So user can uncheck safe search option, and it will display unfiltered results. It is ultimately up to the user to make the decision if they should install it or not. So we shouldn’t parent them too much, just enough to allow them to make an informed decision and know the consequences.
New plugins can be filtered correctly. No star count and recent date can be used to allow new plugins in safe search. But if it’s new and has 1 star ratings, should probably be excluded from safe search.
