Plugins whose authors do not update them, should be removed

Projects Directory
68

Actually, @james, I thought I did. I said:

A developer builds an invoices plugin that relies on an e-commerce. A user installs the plugin without that e-commerce plugin, because it isn’t available in the directory. What happens? Either nothing, or else the user gets a notice saying that the e-commerce plugin needs to be installed.

Whenever I’ve had the experience of a plugin’s dependencies not being satisfied, I get a message telling me just that. I don’t see any problem with that experience because it provides the explanation I need.

69

How would you resolve the dependency in this case?

The WordPress ecosystem has never had a dependency management system that works anything close to well. Existing solutions are ad-hoc and not user-friendly.

In my opinion, having to hunt down and manually install unlisted dependencies would also not be an acceptable user experience.

That may still be the direction we ultimately go, because this is a hard problem to solve, but it is worth discussing first. I don’t want us to end up with a user experience that is broken under certain cases because we didn’t think them through.

1 Like
70

As I indicated in a previous comment, I think the primary responsibility is on the developer whose plugin has a dependency. So I’m not sure it needs any resolution at the directory level.

71

This is the way things stand today, but our stated goals for ClassicPress v2 require that we do better than this.

Also, no established package management system works this way, because it is a backwards and ineffective approach. To name just a few systems I’m familiar with that have solved this set of problems: apt on Linux, npm for JavaScript, composer for PHP, and go get for Go.

1 Like
72

True, but that doesn’t mean that we need to change everything.

True again, but not necessarily relevant. What’s becoming clear is that the disagreement here is over the questions of what’s easiest for users compared to what may be desirable for developers doing complex work. These don’t appear to yield the same answer.

3 Likes
73

Yes, exactly. I think it’s important to discuss these trade-offs.

Now that I’ve made my point about how our goals for dependency management would impact the topic of this particular thread, I expect we will continue the rest of the conversation around dependencies elsewhere.

Edit: I started a new thread about plugin dependencies.

1 Like
74

Just to reiterate my point to include dependencies.

If a plugin isn’t updated or abandoned, then it will become “inactive”. This means that users can’t download or install it (doesn’t show up in search), and directory page will have a clear sign that this plugin is no longer maintained or abandoned.

If a plugin is a dependency of another plugin, then CP can still automatically install it when parent plugin is being installed.

When a plugin becomes “inactive” and it is a dependency of other plugins, authors of these plugins should be notified their dependency plugin became “inactive” and should be considered for replacement.

I’m using “inactive” as an internal label. It can be whatever, that’s just what I use for this discussion.

This rewards active developers, ensures users don’t use outdated/abandoned plugins, and also ensures dependencies are not broken.

5 Likes
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