I like the idea of a button users can click, because I occasionally find that I have old, outdated plugins–yet they still work fine. I want the option to use a plugin that still works.
And for it to still get updates if the plugin author suddenly remembers it exists and fixes it.
2 Likes
No. It wouldn’t.
You test the plugin with the latest version of CP. Then you modify the appropriate line of code to say “Works with Version X.Y.Z” and commit the change.
Your plugin has now been updated and is not seen as abandoned.
If, however, you can’t be bothered to do the “paper exercise”, why should I–as a prospective user of your plugin–trust that you’ve actually checked to see if it’s still compatible?
5 Likes
Exactly my sentiments.
I like Blaze’s suggestion that they be marked as “abandoned” and not show up in searches unless you explicitly specify you want to see them. Then you have to click a button to accept the risks.
5 Likes
I like the idea of hiding abandoned (though I prefer the term adoptable) plugins, by default, and only showing them if the user checks a box (or whatever). I think it’s a needless step to make the user click a button to “accept the risk” where a simple explanatory text would suffice. If this were about protecting the project from liability, that would be a different story, however, the simple act of using open source software commits that user to accept any/all risks, by default.
4 Likes
Yes, it’s not about liability at all. It’s just an extra step to reinforce in the user’s mind that there is a risk involved with installing this particular plugin. The way I see it is… it’s one thing to click a box to say “show me all the plugins, whether maintained or not” - that’s a process that involves just having a look to see what there is available. But if you go ahead and actually decide to install an unmaintained plugin then there should be a second step to say “hey… this one isn’t maintained… are you sure?”
3 Likes
I see we were comparing apples to oranges. 
I was thinking abandoned/adoptable plugins might be a dedicated view, rather than intermingled with supported plugins.
1 Like
Ah, yes. That is Granny Smiths and Valencias. I was assuming it would be an
“include abandoned plugins” checkbox that would add them in with the other results.
I think this is how I’d use it. If I was searching for a particular plugin like an image slider, I might do a search first and get a few results that didn’t look promising, then I’d tick the “include abandoned” box to see if that brought up anything else. I can’t think of a scenario where I would want to get only abandoned plugins and nothing else.
3 Likes
This view would be handy when someone wanted to create a new plugin. If there’s already a similar plugin that’s been abandoned, they might adopt and give it new life. A dedicated view makes the search easy, rather than mixing them together. If it’s not easy, nobody will bother.
OTOH, I probably wouldn’t list abandoned plugins in the dashboard where average users had access to install them easily – installing dead plugins should be done with the utmost of consideration and only by someone with the ability to actually look at and understand the code (and any implications it may pose,) IMHO. I think it makes the good sense to keep them outside the main loop (as it were) and only show abandoned plugins in a special view like how the “secret” options page and the welcome screen are always there, but, you have to know how to access them directly to find them.
5 Likes
OK. I see now. I’m thinking like a user. You are thinking like a developer. 
Obviously there is a need to cater to both approaches.
4 Likes
I didn’t read the whole discussion but my opinion is that this is not a good idea. There are some plugins out there that don’t need updates because they provide just a simple function that works across all versions without further improvements or changes.
For example: What sort of updates might need a plugin that provides the arrow that scrolls back to top of a website? It doesn’t need any updates as it is unrelated with the editing publishing process, but it is something that it is useful and it should be listed in the plugin’s directories.
The plugins that need validation are those that are related with the publishing process as these are the ones that will change in time.
And that is a “respectful” post from a committee member? If I were her, I wouldn’t be back.
2 Likes
This is one of the reasons I try very hard to keep thread lengths down. When you land on a new thread and see it has over 90 posts most people aren’t going to read the whole thing.
I am closing this thread as it went off the rails long ago and if we need to come back to this discussion we can open a new thread that attempts to stay on topic.
@Marialena.S I was in the same camp as you at the beginning of the thread but found many felt it is the developers responsibility to at the very least test that their plugin still works on the latest version (not having to actually update the plugin, but rather update which versions are still supported).
2 Likes