Most ratings aren’t accurate - they’re 1s or 5s. Often times, 1s are due to an error between the keyboard and the chair, rather than an error in the plugin.
2 Likes
We need to be careful to distinguish between plugins that have been abandoned and have problems, and plugins where development has stopped because there’s nothing more to do.
Let’s take an example in another field: qmail. In about 20 years it’s had one (at the time only theoretical) vulnerability. It hasn’t been updated in (too lazy to look it up right now) at least 10 years. Should we take something like that out of the directory?
At some point a piece of software does all it can usefully do. We need to ensure that we allow that to happen - updates for the sake of updating tend to be a source of security issues.
5 Likes
That’s true too, unless plugin’s name is Gutenberg 
1 Like
Along these lines, requiring a readme bump wouldn’t open any issues.
1 Like
But with semver, if we’re doing our job right, the plugin will keep working on the last tested major version. Why update the readme?
Right, and I appreciate that we’re using semver …but readme will still require a bump with major versions.
1 Like
Only if it’s been tested with the new major version.
Will plugin directory even use readme.txt?
We’ll need to parse it for the meta data, whether we use it directly like WP is another question - there are pros and cons to that.
Points taken.
1 Like
I see your point. It is a risk, but I think hackers are probably scanning the repo anyway looking for flagged plugins. Meanwhile the site owners may not find out for months or longer. Seems like security through obscurity not to alert them. If the site automatically forwarded the notices to the admin email when they came in, the webmaster would know right away to take action to secure the site.
1 Like
I’d much prefer we go with a GitHub README.md file over readme.txt.
A readme file is not really a great place to embed metadata, but there is a standard way of doing this on GitHub (raw file, rendered example).
5 Likes
I’m assuming we’ll be listing plugins we know work but where we don’t have direct engagement from the author. In that case we’ll need to parse the readme.
For plugins that explicitly support CP I’d like to see the meta in a json file, but now we’re starting to head OT.
But why can’t the developer simply update the readme.txt file to inform the world that the plugin has been tested with the current version?
That is the single point of starting this topic. If a plugin developer cannot be bothered updating the files (if only to reflect compatibility with current versions) then CP should not be bothered to list those plugins.
2 Likes
I agree 100% with @Pieter.
This thread has gone off topic quite a bit. This is, for example, nothing to do with security. This is to do with keeping the directory clean and composed only of plugins whose developers are at least somewhat active.
Several of the comments have also overlooked the significance of the point that we are talking about a directory and not a repository. If a plugin is removed from the directory, that does not mean that its code disappears. Not at all. It just means that there is no link to that code from the ClassicPress website. But the code will still be where it will always have been: on the developer’s Github site.
The effect of removal will thus be to withdraw the developer’s privilege of being somehow endorsed by CP. Current users of that plugin won’t be any worse off, because the plugin will work just as well as it would have if the plugin had remained listed in the directory. Potential future users will not, however, have an easy means of finding the plugin unless and until the developer updates the readme.txt file.
That all sounds really straightforward and sensible to me.
4 Likes
Me too!
We’re going to have plugin dependencies - we need that to make core plugins work; we can mark plugins as unmaintained, we can stop tracking them for new major CP versions, we can flag them as “author doesn’t respond to security issues”, we can even hide them from certain searches - the only thing we cannot do is delete them. We all remember the npm debacle, yes?
Using semver means plugin compatibility will be tied to major versions, which makes the directory effectively self cleaning. If the author doesn’t update the plugin meta for the next major CP version it won’t be listed - simple as that.
The assumption in the WP repo is that plugins that work with e.g. the last release of v3 will work with the first release of v4. Our assumption is the opposite; because we know there will be breaking changes between e.g. v2 and v3, we cannot assume plugins will carry on working.
So, to address the title of this thread directly: no, but they should be appropriately flagged.
4 Likes
Sorry, but this is a complete red herring.
We aren’t talking about core plugins here. We are talking about bog-standard, regular plugins. The only dependencies involved will be those that the plugin needs from core.
Using semver means plugin compatibility will be tied to major versions, which makes the directory effectively self cleaning.
Sorry, but that’s not even close to being true for an ordinary user. A directory is effectively just a list of (CP-approved) plugins. Those plugins stay in that list until removed. If the developer isn’t sufficiently active to update a simple text file, s/he should not get the benefit of having his/her plugin listed. It really is that simple.
No, it isn’t. Once we provide any feature - like plugin dependencies - it will be used, and almost certainly in ways it was never intended for and that we’d never thought of. That’s just how it goes.
Once the facility is there for plugins to define dependencies on other plugins, we are responsible for maintaining that relationship.
I think you are projecting the current WP experience onto what we’re still designing.
For a given search, why would we return results for plugins that we don’t know are compatible with the user’s version of CP?
If they search or browse the website directly we default to the latest CP version.
If they search from within CP we have the CP version so we only list plugins we know to be compatible.
The “ordinary user” never sees listings that aren’t directly useful to them. The “advanced user” can still find what they’re looking for.
3 Likes
Once we provide any feature - like plugin dependencies - it will be used, and almost certainly in ways it was never intended for and that we’d never thought of. That’s just how it goes.
OK, let’s assume you’re right. It still makes no difference whatsoever. An installed plugin will still work, and the code will still be available on the developer’s site. So this argument remains a red herring.
For a given search, why would we return results for plugins that we don’t know are compatible with the user’s version of CP?
You are completely missing the point. This isn’t about what works or does not work. It’s about rewarding plugin developers who are participating as members of the community, while making it clear that those who don’t do so will have their plugins de-listed.
I think you are projecting the current WP experience onto what we’re still designing.
Clearly, that’s not what I’m doing at all. This has nothing to do with functionality, and everything to do with incentivizing developers to keep at least somewhat active.