Any solution will require core changes, but adding another field to the database won’t solve anything. Think of existing sites with a mixture of plugins. The default value (whatever you choose) won’t help you at all, so the field itself is useless. It is the same as putting it into the if statements that you have to change anyway.
OK, I see your point and I think we can solve that.
- If a plugin/theme includes
Requires CP, it should default tocp. - If a plugin/theme does not include it, it should default to
wp.
We require plugins to have that header, so if the installation source isn’t set this should solve 99% of issues. There will be some edge cases, but there are always edge cases in any situation.
I can’t tell if you are still thinking you need a database field. I hope you can see it isn’t needed if you can derive it from the existing fields.
To me, it seems like the simplest case would be to require the Update URI field for anything in the CP directory, with the only allowed values as CP dir or WP repo. The core update process already handles that field as empty indicating WP repo, so I suppose you could put a check for Requires CP there, but I don’t think that’s the point of that field. The point is the actual version number.
This goes back to what Tim said about allowing WP repo hosted plugins/themes:
I’m also not sure of the feasibility of having a backup mirror for WP-hosted plugins/themes since it’s SVN. So the plugin can continue to be available even if it’s closed/deleted.
Yeah, I don’t agree with him. The CP directory is not a repo. It is a list of plugins that meet certain standards. I think it would be a missed opportunity to not allow listing WP plugins that are compatible with CP. The CP directory should not force developers to store their code in GitHub and in WP repo. It should simply point to WP repo (if the plugin meets CP standards, one of which would be the Update URI is CP dir or WP repo).
- 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 CPis 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.
@Simone what do you think of this approach?
Agree with your approach @viktor this but there is a problem in one point (we need Update URI for updates to work), so:
- first check Update URI and respect it
- if Update URI is empty and Requires CP is set, set Update URI to CP directory.
This is almost like what you said but without the last fallback to WP.
So you think we shouldn’t fall back to WP if Update URI is not set and Requires CP is not set?
This would be the case when a user installs WP plugin from the repo.
No, my idea is not to fall back if the Requires CP is set but the slug is not found in our directory.
If both header are missing it’s clearly WP.
Edit:
if CP directory API request returns data for the slug
I’ve just removed this part.
1 Like
OK, that makes sense. To recap:
- Check if
Request URIis set:- Yes: use provided URI.
- No: check if
Requires CPis set:- Yes: check Directory API if plugin/theme exists:
- Yes: Use Directory to update.
- No: fail/do nothing (there will be no update notification, I assume)
- No: default to WP repo
- Yes: check Directory API if plugin/theme exists:
Here’s a flowchart to visually show the process:
4 Likes
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?
Can’t give you a precise response.
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?
For example:
https://wordpress.org/plugins/helpful/
API returns nothing:
https://api.wordpress.org/plugins/info/1.0/helpful.json
This is akin to someone deleting their GitHub repo, which happened before. That’s why we decided to create a backup mirror of the plugins/themes.
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).
2 Likes
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?
3 Likes