Plugins whose authors do not update them, should be removed

Projects Directory
62

Again a complete misunderstanding from the original point of my topic.

I give up and will board my plane now.

63

I agree as long as we can make sure that doing this doesn’t break people’s sites.

Is it ok to point out when there are problems with a suggestion, or should we just silently agree?

64

I like to believe that this is just a misunderstanding.

However, @pieter and @timkaye rather than just stating we don’t understand could you further explain your side of the argument?

  1. Would delisting a plugin that other plugins have dependencies on just mean it doesn’t show up in the directory but can still be required by other plugins?
  2. My thought is that the plugin directory should be anything but onerous on plugin devs. So if V1.1.0 will work essentially the same as V1.2.0 why should we require devs to update their readme.txt - it just seems like unnecessary work when everyone knows it isn’t a breaking change. I am happy to hear another argument as to why we should do this, I do understand it shows they are active but there is a tradeoff.
  3. If we are encouraging forking, doesn’t delisting a plugin reduce the probability this will happen?
  4. Is your point more we should punish devs who aren’t active (reward active devs)? → I am 100% onboard with this
3 Likes
65

I am certainly in favor of promoting (4). And I think the tradeoff you mention in (2) militates strongly in favor of what @pieter and I have been saying. It’s a very small requirement, and it will help to indicate who is playing an active role and who isn’t.

I think you have a stronger point with (3). It’s one of the reasons why, instead of complete delisting, I’d also be happy to go with @viktor’s suggestion of preventing further downloads with an accompanying notice to that effect. It would enable potential forkers to see which formerly listed plugins are no longer supported and encourage them to look further. It would also avoid the issue of delisting and relisting a plugin.

The real controversy seems to be over (1). Let’s use an example to illustrate the point. 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. So no problem there.

Let’s try a different tack. In this instance, the user has both plugins installed, but the e-commerce plugin is then delisted or made unavailable for download. What happens now? Nothing at all. The two plugins work together as before. Plugins that are already installed don’t stop working just because the source from which they came no longer exists.

The only real issue arises if (a) the invoices plugin is updated to require a later version of the e-commerce plugin and (b) the latter is not available in the directory. But that’s on the invoices plugin developer. Either s/he should be checking that the e-commerce plugin is still available, or else s/he should be running a dependency check before the new version gets installed. Sure enough, @pieter does this in the Classic Editor Addon plugin he co-created.

So that takes us neatly back to (4). The proposal (or that of simply making further downloads unavailable) would not only reward active devs but also encourage good practice.

4 Likes
66

I just got off the plane and have nothing further to add :slight_smile:

Once again thank you @timkaye!

1 Like
67

No, you’ve missed a crucial point about how dependencies need to work! In any sane package management system, it is impossible to install a package without its dependencies.

So what happens under this example? Installing the invoice plugin fails with an error because its dependency is not available.

This would be a really bad user experience, and it is worth avoiding one way or the other.

1 Like
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