What happens if WP repo closes the plugin but it didn’t violate CP directory rules?
Technically, WP repo still has an exemption for Google Fonts in the rules, we plan not to allow Google Fonts CDN to be used. How do we reconcile rule differences, now or later?
The plugin reviews we’ve done so far for the existing directory did encounter this problem. WP plugin wasn’t getting approved because it wasn’t passing our standards, but the developer tried to reason that if it’s good enough for WP it should be good enough for CP.
Using a Git-based service such as GitHub (or GitLab, Codeberg, etc.) is not an unreasonable request in today’s world. It’s almost a standard.
If we’re asking developers to abide by our rules to be listed in the directory, why can’t that include GitHub or another Git service? When you build a house, you don’t stop when the walls are done; you need a roof.
We need to figure out how to handle it in the core.
Simpler Approach
Thinking more about it, we could try a more straightforward approach using CP Requires header, assuming Update URI is empty:
Check if Requires CP is set:
Yes, default to CP directory if CP directory API request returns data for the slug.
No, default to WP repo.
This process would still consider actual version requirements set in Require CP, but the mere presence of this header should default CP core to use directory API. I think this is the way we should proceed.
I trust that the WP plugin review team is handling closures responsibly. If there is a code problem, I wouldn’t want CP dir to be still promoting it. If there is a problem with the author (or self-closure), I wouldn’t want CP dir to be still promoting it.
As for Google Fonts, if the author wants to be in the CP dir, they have to follow CP rules. They can be in WP repo without being in CP dir.
I never said that you couldn’t ask that. What I said was the CP directory is a list, so it should be able to list plugins from several repos, including WP repo which is not Git, and authors shouldn’t have to put it in Git just to be listed in CP dir. (It’s best to have one “source of truth”, one place the code is maintained, not multiple.)
It would make more sense if you used the correct term of Update URI.
Would this only work for a version greater than the version with the CP dir integrated?
This is the only part that requires a core change, as this must happen in get_plugin_data() function for things to work properly.
Directory integration at the moment is a plugin that requires CP 1.5.
My bad, but clearly you got the point I will correct it, to not confuse new readers.
We have to make certain trade offs to ease implementation and improve automation. As Git is the dominant version control system with 89% marketshare, this is what we decided to use.
And you’re absolutely right, we need one source of truth. That source of truth is ClassicPress Directory, which has specific requirements to ensure safe and secure plugins/themes are made available to our users (not WP users). This means developers must meet our requirements to be listed. In WP, they must use Subversion. There’s no choice.
I understand where you’re coming from. WordPress controls its ecosystem, ClassicPress should be able to control its ecosystem without reliance on WordPress.
This whole conversation began because I wanted to make it easy for WP developers to list plugins/themes. It’s easy, but they have to comply with the requirements. If they don’t use Git to version control their plugins/themes, I’m not sure what the alternative is and, frankly, have reservations of listing that type of code in our directory as it doesn’t imply quality.
Um, no…CP directory is a list, not a repo, so it’s not a source of truth. It should still be able to list plugins in GitHub or in WP repo (because the interface is already in core).
The choice of version control system has no relation to code quality.
But CP dir still needs to be able to interface with it.
For ClassicPress core ClassicPress directory will be the source of truth, since it is a reviewed list of themes/plugins.
Anyone can create a repo on GitHub, anyone can download a plugin/theme from GitHub and install it. Hosting the code doesn’t mean it’s the source of truth. It’s just the source of code. ClassicPress review team decides what the truth is by reviewing plugins/themes using our guidelines, and making that truth available to the ClassicPress community.
This is why we can add GitLab, Codeberg, and any other Git-based services. We’re filtering data to ensure users get the “truth”, whatever the Git-based source of the code is.
I guess if we simply treat WordPress repository as just that, a non-Git repository, we could consider integrating it. Following WP rules is up to the developer. However, how exactly would we deal with a closed plugin since WP API stops serving information when it’s closed?
To me the issue arises because we are confusing two separate things:
Plugins that want to be hosted only on CP dir, need to have a place they come from (GitHub) so that the dir can serve updates.
Plugins in WP repo (so their source is WP repo and not GitHub) and want ALSO to be listed in CP dir. They need to abide by WP rules and CP rules to be listed in both obviously but they come from a different source, so we need to see how to implement updates from them (and here I think as the majority that implementing a check to see if it comes from one or the other is necessary and that once we have our own ecosystem we will need to simply drop the wp repo but this will come in the future)
Plugins only listed in WP, these will be available as direct management in dash as long as we keep the WP repo connection, once we will have our own separate ecosystem grown and remove the WP repo they can be installed by uploading them.
Now, for the what if a plugin gets delisted in WP BUT it still abides by CP rules and can stay in CP dir? Simple, we tell the dev to update the source (he hosts in GitHub after being kicked out). It is the case with all the plugins that are for ClassicEditor, at a certain point a big number of them will be kicked out of WP because you know deprecated, they have blocks now… so we just invite the devs to make them available for CP by hosting them on GitHub. Ideally, we contact these devs way before they are kicked out and invite them. They might accept and list with us and WP at the same time then when the wp is no more they simply update the listing to point to GitHub.
Instead, what if a plugin gets kicked out because of something bad like malware or other violations? in that case we will have to agree with the WP repo and delist ourselves, we do not want to list dangerous code that could endanger users’ sites, and on this, I agree with @joyously
To me, the question is: we need to change the core to implement the check, let’s say in about 4 or 5 years we have an ecosystem (I believe even sooner). We then decide to unlink the WP repo from the dashboard… we will need to change the core again to only manage CP dir, correct?
You are thinking in meta terms. I am talking about authors having to make a Git repo separate from the WP SVN repo. There should only be one “source of truth” for the code. (obviously if the code diverges for CP, it needs a separate repo) But the whole point was to make it easy for the developer to support both. I say the easiest is to have it in the WP repo with the Update URI set to the WP repo, and CP dir lists it if it meets CP review standards.
There’s not much to do there…the core already does this for updates, and the CP dir just needs to talk to the WP API for the data to show on the plugin page (outside of admin). And since core CP is being used for the CP dir, it’s already built in.
It’s no different from how WP treats it. It’s as if it doesn’t exist, since it won’t be served from the WP repo. Why is this a problem?
I still don’t think a backup mirror is a thing CP dir should be doing, since it’s just a list, not a repo.
Why not just host it wherever the user wants to? So the user can choose GitHub, WordPress, a personal server, or {insert-free-choice-here}?
This would mean total freedom.
Users who have a plugin on WordPress, can keep it there (so they don’t need to upload it to different places for each version).
Users who don’t want to use git for some reson, and also not mess with SVN, can host a zip file on their own server.
…
And then, the directory would just contain all the information (title, version, description, whatever) and a link to the package, wherever that is?
So, even if the user can be free to host wherver, if the plugin breaks some condition (malware or anything like that), the plugin gets delisted from the CP directory et voilà…
@alvarofranz because we need to know when a plugin is updated to make updates happen.
With GitHub you can ask GitHub API for the latest release.
I can write a post in my own blog that my plugin is updated and attach a ZIP, but there is no way for us to know that there is a new version (just as example).
I think this is wrong security-wise. If you can host on your site and that site is not secure and the plugin file gets hacked you will be serving hacked updates to people…
Hosting on GitHub and adhering to guidelines and undergoing the review process ensures that the code is safe. If it is the far west instead who knows what can be placed in plugin files… Let’s say I undergo the review and pass, then after ten days I change the plugin to do something bad and serve the update. Or do we enforce a review with each update?
I don’t think we have enough people to review each new release.
What I think is that you should trust the developer to install a plugin, but as you said if a plugin is hosted on a bad hosting it can be hacked and the plugin can be overwritten with malicious code.
The way I intended this to work is by manually updating the current version on the directory dashboard (as a plugin author). What’s easier? … upload my plugin to two directories (WordPress and ClassicPress) or do it once and change the version manually in the other place? well… both require a minute or two.
That could potentially happen… could be a point. Then: stick to “hosted on WordPress, GitHub, GitLab…” sites where the being-hacked probability is low?
As far as I know, it doesn’t matter where the plugin is hosted, you can always edit it in a new version to be a bad person… even on the WordPress directory.
That could potentially happen… could be a point. Then: stick to “hosted on WordPress, GitHub, GitLab…” sites where the being-hacked probability is low?
Yes basically. since CP is a listing every listing should include a field where to point to fetch updates. We can allow updates coming from WP repo (that is SVN), github, gitlab… where the chance to be hacked is low (these repos have strong security measure in place to prevent hacking of their servers).
I agree that a bad dev can update the plugin to include malicious code, but this is a very rare occurrence and if one lists his plugin on WP or CP and it undergoes review one can assume that dev is trusted. If the dev is discovered to put malicious code in its plugins it gets kicked out (this already happens in WP because the bad code is discovered and outed, so we can apply same measure to plugin listed in CP)
This discussion has served its purpose to identify a way to manage updates for WP repo and CP directory plugins/themes. So it will be closed.
However, the WordPress repo as a source discussion will be moved to Github to continue to explore this possibility. Anyone interested (@alvarofranz@joyously) in this discussion can monitor or participate here:
Thanks to everyone who participated, we appreciate your feedback.
I will correct it, to not confuse new readers.