Yes, that phrase could do with some work.
The idea is to ensure that no WP-specific code is loaded (or available) at runtime under CP, not to prohibit a single shared codebase.
Update: that phrase has had some work - feedback welcome!
2 Likes
Quoted for posterity after the changes… this looks good to me.
2 Likes
This does not make sense to me.
Will CP have 3 ways to update a plugin? (that sounds like WP-specific code)
Will every code change to a plugin be audited? (no way to have the manpower for that)
Would there be a way to opt out of auto updates? (there are times updates are not wanted – e.g. Gutenberg)
I think the user would be confused as to what they are getting. With WP, if it’s listed in the admin Plugins search, it has been reviewed (initially at least). If there is a security problem, the plugin is closed so it does not show as available. But there are plugins available everywhere, and the user knows that those external ones have not been reviewed. The plugin author is rewarded with exposure to users by putting the plugin in the WP repo.
Some consideration should be given to what restrictions are put on plugins that are shown to the users, such as advertising or hijacking the admin or removing the plugin Deactivate link or crypto mining or tracking users or phoning home or sending spam, etc. I assume you want to be fair, but if you don’t restrict it, fairness goes out the window.
No, just 2 (we’ll most likely leave the existing WP-based plugin mechanisms in place for people who want to install plugins from the WP directory). There may be some variations in how plugins in the ClassicPress plugin directory are presented but they will be hosted the same way (for example, on GitHub).
The technical meaning of patch-level is important here. Plugins that are audited by ClassicPress will be required to use the semver version specification which is major.minor.patch (e.g. 1.2.3). In this example, 1.2.3 to 1.2.4 would be an automatic update, but 1.2.3 to 1.5.0 would not.
A patch version update (only the third number increases) means there are no breaking changes, only minor changes or bugfixes. The responsibility would be on the plugin author to follow this standard.
Please don’t use the words “repository” and “directory” interchangeable. They have a very different meaning in CP.
Maybe you know, that in CP we don’t have repositories, just a directory. WP has a repository. Old member knows this, but suppose, this thread will read a novice.
And if you think about the differences, you will find answers to some questions and worries above.
5 Likes
What are the main obstacles to running our own repo? Obviously there’s cost and management but what else is there? Security?
Regarding cost, anyone have a clue what it would actually cost to run a repo with 1000+ plugins / themes? And in that respect, what are the chances of getting A N Other Hosting Provider to sponsor us? Is that something worth exploring?
1 Like
Why do we want our own repo?
1 Like
It won’t be a repo, it’s just a directory. The rest of your questions are valid.
2 Likes
Why not?
It was discussed here on the forum somewhere… sorry, I can’t find it now among all the related posts. I think it boiled down to cost, liability, and ease of implementation since it didn’t require a ton of infrastructure.
3 Likes
Thanks @anon71687268. That’s all I was asking - what are the obstacles.
If it’s impractical for the reasons you mention then so be it.
I’ll have a look for the related posts as I’m still interested in seeing the detail, just to satisfy my own curiosity.
3 Likes
Sorry it was a short question, but it was a real one: what is it that a repo provides that a directory doesn’t that we might care about?
I’ve come to the conclusion that for now there’s absolutely nothing, but I may not have thought of everything - that’s the great thing about having other people involved in a project.
2 Likes
Sorry it was a shorter answer 
My question was a real one too. The main reason I asked was because it occurred to me that if the main obstacle was cost, then that might be a potential opportunity for sponsorship. I wasn’t questioning the decision, just wondering what the obstacles were.
In answer to your question, all other things being equal, wouldn’t a repo perhaps make things logistically a bit easier - from both a developer and end user perspective? We want to make things as easy as possible for both and certainly for users switching from WP. I think it may also give a greater sense of security to the end user knowing that they are downloading from a trusted source.
Anyway, that was where I was coming from. @anon71687268 outlined the reasons why the decision was made to go for a directory rather than a repo and I’m fine with that. But as I say, the potential for sponsorship was what led me to raise the issue in the first place.
3 Likes
If it was a repository you’d need to check your code into it as well as your own development repository. Being a directory, you’ll be able to link it to your own GitHub repository so less work from a developer point of view.
For the end user, they’ll install from the directory in the ClassicPress dashboard, so no difference in effort.
4 Likes
Both good points.
2 Likes