Plugins whose authors do not update them, should be removed

Projects Directory
75

Y’all are making this way more complicated than it needs to be.

Wild West

The plugin directory is open to anyone who isn’t actively harmful.

For those users who are looking for guidance…

Compatibility With Current Version

Set a “Compatibility Rating”

  1. Fully compatible with most current version (V.x.x)
  2. Compatible with current minor version (V.x)
  3. Compatible with current Major version (V)
  4. Unconfirmed compatible

Prioritize listings by rating, only show rating=4 by explicit consent (e.g., “show me all plugins, even if they aren’t compatible”)

If a plug-in dev can’t be arsed to check the plugin with a clean install of the current CP version and update a simple text file, then they should be bumped down the list.

Olympic Ranking

Rather than the common “5 star” ranking system, move to a more granular system (percentage?). Then remove the outliers (as is standard in statistics). So (for example) ignore every review under 10% and over 95%. Eliminate the fanboys and haters from the equation.

Badges

CP needs to make money. Use the plug-in directory to do so.

Develop a clear and well-defined set of criteria for “certification levels”. Bronze means “works with the most current V.x version of CP and the most popular plugins”. Platinum means "works with the most current V.x.x version of CP and has no conflicts with any Badged plugins.

Plugins can pay to be assessed for certification at each level (e.g., platinum, gold, silver, bronze).

Badges would heavily influence search rankings.

Find the right balance of Certified, Approved, and Popular, and you have a valuable listing of plugins.

And a great marketing tool.

And a great source of income.

4 Likes
76

Those are good ideas, but they are not relevant to the topic at hand. What happens to plugins that are not maintained or abandoned?

As it seems, everyone wants CP directory to be well maintained and listing updated plugins. Nobody wants the wild west that is WP repo, with thousands of abandoned plugins that can cause serious harm.

So the question is, what do we do with plugins that become outdated or abandoned?

Some folks want to de-list (delete) those plugins. But that poses a problem for plugin dependencies, which isn’t a problem for WP since they don’t offer it.

We did find some common ground on labeling these plugins clearly with a warning message and making them unavailable for download or installation, unless they are installed as a dependency.

3 Likes
77

Though the admin panel, but through the website I’d still have them listed so people can adopt/takeover

1 Like
78

So the question is, what do we do with plugins that become outdated or abandoned?

You keep them in the repository, flag them as “abandoned”, and set a default filter to exclude them from searches. If someone wants to see and install abandoned plugins they have to click “show abandoned”, confirm the understand the risk, and click “show me” (3 clicks = “tell me three times”).

At that point, it’s “their problem”, and CP won’t support their installation.

Treat plugins the same way companies treat hardware: OEM, Approved 3rd-Party, and everything else. The first is guaranteed, the second has limited support, and the last is specifically discouraged, unsupported, and entirely the responsibility of the user.

This is SOP for industry and has solid legislation and legal precedent to back it up.

6 Likes
79

This also neatly solves the previously discussed issues with dependencies: “outdated” plugins don’t appear by default, but they can still be installed when another plugin requires it.

2 Likes
80

I’m a real-world very-small-type developer. I know CSS well and enough PHP to modify a template without breaking anything, I generally start with a theme I like and modify it to extreme lengths. About half are WooCommerce sites so will be able soon, I hope, to commit to CP.

Now one of my favourite plugins is called Flexi Pages Widget - and the description is just perfect. Just nothing comes close. I curate it myself so I can vouch for it on the 4.9.9 generation. Updating is just a paper exercise. But it was last updated 3 years ago. So a perfectly good, safe plugin would be axed,

It is so simple to test, that it must not be impossible for it to be placed under a ‘curated’ category?

3 Likes
81

@ColinP: maybe not in this specific case, but not updating a plugin for 3 years generally means that it is forgotten and may or may not work.

We’re also open to considering other solutions here - such as a button maintainers and/or users can click to say “yes, this plugin still works”.

Implementation of this is still a ways out. We’ll be back and asking for help & feedback as we work through this and other plugin directory tasks :slight_smile:

1 Like
82

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
83

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
84

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
85

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
86

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
87

I see we were comparing apples to oranges. :slightly_smiling_face: I was thinking abandoned/adoptable plugins might be a dedicated view, rather than intermingled with supported plugins.

1 Like
88

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
89

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
90

OK. I see now. I’m thinking like a user. You are thinking like a developer. :smile:

Obviously there is a need to cater to both approaches.

4 Likes
93

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.

95

And that is a “respectful” post from a committee member? If I were her, I wouldn’t be back.

2 Likes
96

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
97