Plugins whose authors do not update them, should be removed

Great, I think so too. Everybody’s happy.

1 Like

@viktor I didn’t understood the democratic argument, we created this topic to discuss this and I gave my opinion above.

let’s do this exercise. Type “form” in the plugins search box. Search Results for “form” | WordPress.org
You will get 643 pages of results. Go to the last page and open the detail page of each plugin. You will have plugins updated 11 years ago, 10, 5, 4.

So what’s the point of listing them if CP started in 4.9 ?

If this is about parenting why are we increase PHP version? Let’s give the user the choice to use the PHP version he wants? Of course I’m beeing ironic, some decisions need to be made and talking like we are now it’s part of the process.

I will help to implement whatever is decided.

2 Likes

At last, someone who understands my point. Thank you @timkaye!

3 Likes

My whole argument against de-listing is specific to CP directory, not plugins from WP directory.

I agree that old plugins shouldn’t be listed to begin with from WP repo.

My mindset was in the oposite way since for now we are still using the WP plugins API to do the search I was only talking about limiting the universe of change inside the WP repo search.

But we have to draw a line somewhere by default, and maybe like you suggested have an additional option to search for all the plugins available no matter what.

2 posts were split to a new topic: GitHub Requirement?

For those who didn’t know what this was referencing: NPM Left-Pad Controversy Explained

When you have code that can depend on other code (in this case, plugin dependencies), you cannot delete or de-list a dependency without breaking other plugins.

Dependencies will need to be considered before we implement any kind of de-listing or deletion policy, whether this is due to inactivity, security issues, or some other reason.

2 Likes

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

I give up and will board my plane now.

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?

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

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

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

Once again thank you @timkaye!

1 Like

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

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.

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

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.

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

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

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

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