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.
I agree with the sentiment that we need to reward active developers, but I do disagree with complete de-listing.
If plugin isn’t actively maintained, it needs to simply be marked “inactive” and it will no longer be available for installation inside CP. But, we’re building a directory so there’s no reason to remove listing completely. What’s the point of abandonment policy if our directory can’t show abandoned plugins?
Yes, plugin is still on GitHub, but why are we expecting developers to leave CP.net and go find abandoned plugins on GitHub? We need to keep people on CP.net. They can find abandoned plugins in directory and a link to GitHub repo, so they can fork it if they wish to.
De-listing isn’t necessary and counter-productive. Should only be removed at the request of the developer.
5 Likes
De-listing is necessary for two reasons.
First, if CP is successful, it will be storing up huge trouble for later if we keep a mass of inactive plugins.
Second, despite @invisnet’s optimisim, we at CP cannot control the results of a search. We can control only the results of a CP search. But there is such a thing as Google. And that’s how many users find plugins. If we leave the plugins of inactive developers listed, then we will be seen to be endorsing them, and so plugin developers would have little incentive to remain active. That precisely what happens at present with WP’s repository.
1 Like
Can you tell me if WordPress is endorsing this plugin by having it listed in repo?
This is what I’m referring to. It’s still there, but a clear sign says it’s no longer available. And it can’t be installed.
We’re not hosting source code, it’s a directory. It will be as easy to manage as we design it.
My questions are, if de-listing:
- What’s the point of abandoned plugins policy if plugin is already gone from directory and no way to confirm if it’s a fork or not?
- What will happen if plugin developer does come back and wants to be listed again? Re-listing? That’s extra work that isn’t necessary.
Also, to add, listing something in your directory doesn’t mean endorsement. Look at Google, I doubt they endorse any of the listings in search results, Google My Business, etc. But it’s still there.
1 Like
No, I don’t think that’s an endorsement. But nor have I understood that as what is meant by being “marked as inactive.” And there’s a good reason for that. Because that plugin was removed not because of a decision taken by those running the WP repo, but at the request of the developer. So it’s simply not analogous to what we are talking about at all.
1 Like
I don’t understand your seeming obsession with de-listing.
I don’t understand why a list of “plugins that worked with v3” is a problem when we’re on e.g. v5.
I don’t understand why it matters how a user found a plugin; the plugin contains meta data, we can check at install time whether we know if it’s compatible.
I don’t understand why, if we have 3 plugins, A → B → C, you feel it’s acceptable to break A and B by de-listing C.
I don’t understand why a suitable notice on the plugin listing explaining it’s unmaintained/insecure/whatever isn’t at least as much incentive as de-listing.
I’m beginning to think we’re not talking about the same thing at all, but I don’t understand what that other thing might be.
1 Like