Why isn't this allowed in the wp.org plugin repo?

[notslang]

Sorry if this has been asked before, but I couldn't find an answer in the other issues and the line in the repo is really vague:

This plugin is not allowed in the wp.org repo. 😦

[afragen]

As @Ipstenu said #7 (comment)

While the plugin itself was NOT actually violating the rule (it was just letting you use another source), but it was encouraging others to do so. I like the code, but it's just contrary to the ethos of the repository.

The rule in question was Guideline 8. Not a technical violation, but I do understand.

Since GitHub sourced plugins aren't going through any sort of peer review, condoning the automatic updating of these plugins, by having this project in the repo, could have severe implications. Most users of GitHub are probably sophisticated enough to do their own code review of sorts.

[Ipstenu]

It would be innacurate to say that ALL code on the WPORG plugins repo was peer reviewed, but the control thing is a big issue, TBH. Consider clashing plugin slugs, for one. If you make a plugin named ipstenu-rocks and so do I, but mine is on WPORG, who wins for updates? They might constantly slug it out :/ And then what if someone makes an intentionally BAD plugin? Right now we can yank it, or better yet, fix it. Once you take that control away from the repo, and introduce the big bad world of evil people (which you guys are not!), it's ugly. :(

I WISH we had a better way to manage that!

(FWIW I personally still love this code and recommend it to people all the time :) )

[afragen]

Mika, there shouldn't be any issues with clashing plugins as WPORG plugins shouldn't have a GitHub Plugin URI header. Forks should similarly be able to update independently (provided the forked plugin changes the header).

I absolutely agree with you regarding intentionally EVIL plugins or even those plugins who benefit from your watchful eye and assistance (I know Pippin and Otto are there too. 😉)

I know @pdclark has a great plugin for searching GitHub hosted WordPress plugins, https://github.com/brainstormmedia/github-plugin-search and Paul is trying only to list plugins based on a minimum starred number or certain authors to make it more safe for the end user. Clearly there's no way to manage GitHub hosted plugins. Perhaps some sort of "seal of approval" from you, Pippin or Otto. But then again you guys already have a handful just keeping WPORG safe.

I'm glad you like the plugin and always appreciate your insight and kind words.

Andy

[Ipstenu]

WPORG plugins shouldn't have a GitHub Plugin URI

re-reads your code, which has changed since last I looked in depth Ooooh clever :)

[afragen]

Thanks Mika. I was shooting for low cost of use (single header) and performance closely resembling WP core. I think we've done pretty well and it is definitely a WE effort. The code would be no where near what it is without @GaryJones.

I still have some work to do to get the theme updating on par with the plugin updating. It's nice to have a TODO list.

BTW, the best reason for automatic updating is how this plugin has evolved.

[GaryJones]

I saw @mikejolley make a suggestion, in that each WPORG rpo be allowed to link to a canonical source (could be GitHub, but no reason it couldn't be BitBucket, or some other version controlled source). Everything still passes through the repo, but not all of it uses SVN as the source. Repo admins would still have the ability to yank a plugin, by removing that link, but developers can have a new plugin on the repo, but enter a value in a field to say they'd prefer developing it elsewhere.

(The same could be done for Support forums vs GitHub Issues etc.)

Thinking of it in terms of being a link is the best suggestion I've seen around this topic. Copy the code that connects the repo to SVN, and adapt it for looking up GitHub repos instead. @Otto42, personal and philosophical opinions aside, what is the technical feasibility of something like that?

[notslang]

@Ipstenu - looking at the npm repository, which anyone can publish to without being reviewed, surely the "big bad world of evil people" isn't a real issue. The repo reviews itself because users are responsible for reviewing the packages that they depend upon.

Even with peer review, I guarantee it is possible to get a evil plugin into the wp.org repo. It probably wouldn't be able to gain much popularity, but hiding evil functionality isn't hard. The point is, peer review isn't how you gain safety - it's by sand-boxing plugins and giving them a responsible API - like chrome does with the permissions API. Of course, this isn't really possible with PHP, but that's how you'd actually solve this problem.

@afragen - thanks for the link to Github Plugin Search. I was actually looking for something like that.

---

Anyway, the reason why I'm asking this is because I'm publishing a plugin called wp-migrate-db and I want to do updates through GitHub (because SVN is horrible). But having to download and install the zips for both github-updater and wp-migrate-db is like a 3 minute long process. It would be much easier to tell users to just download this plugin through the WordPress repository.

[Otto42]

Short version: no.

We may at some future point have git support in-addition-to svn (or better yet, just have an interface to make the difference not actually a difference), but we will run our own repository of code. We will not use GitHub, and we will not be allowing plugin updates from anywhere outside of WordPress.org. External repos are a non-starter.

If you want your code listed on .org, then it must be hosted there as well. The plugin directory is a hosting service, not a listing service.

[notslang]

Yeah, I don't want my code listed on wp.org, it would just be nice if this plugin was on there because it would make the install quicker.

Anyway, thanks for the speedy response. Seeing as this isn't happening imma close this issue.

[GaryJones]

@Otto42,

I think most developers would take git support on the WPORG repo as a more than acceptable middle ground. Adding a second remote repo of WPORG in addition to GitHub, and pushing to that as needed, would be a far simpler workflow than what we currently have. Thanks for commenting :-)

[Otto42]

@GaryJones You know that the git client can talk to SVN servers too, right?

I'd say that the easy way to do it would be to make a branch called "release" or "svn" or something like that, which is a checkout of your plugin's SVN trunk. Then, in order to do a release, you do a merge --squash into that branch. Then you switch to that branch and dcommit it over to the plugins repository.

The problem with git is that honestly, it keeps too much data. People commit too often, as weird as that sounds. And while lots of committing for development purposes is fine, the plugin repository is a release repository. We don't need the commit history of every little change you make to your plugin. Every commit causes us to parse the plugin, build zip files, send update notifications if needed.. There's a lot of activity that happens on commits.

So some process to flatten those changes, tag them for release, and then to actually send them to be released is much preferable. Even if we switched to git, we'd still want this to be the case in some fashion. WordPress.org provides release and hosting systems, not public repositories to be used as development environments.

You could also rebase -i to flatten and then dcommit and so forth. That works fine too, but can be a bit trying if you have lots of commits to flatten. The method of merging all changes into a branch with a single operation and then doing a dcommit to svn seems simplest.

[notslang]

Umm... one of the major points of git is not keeping data globally. For example, unlike SVN, branching is not a global thing - you can make local branches without everyone needing to download them. If anything, git would be lighter than SVN for the wp.org servers.

Also, git uses tags for denoting releases. Releasing every single commit would be awful. Occasionally commits aren't even working versions. You can see an example of tagging releases here: https://github.com/afragen/github-updater/releases

[pdclark]

You might find https://github.com/brainstormmedia/deploy-plugin-to-wordpress-dot-org helpful in solving your SVN woes. It takes a Git repo and deploys it to wp.org for you in one step. 

Paul Clark
pdclark.com

On Mon, Dec 30, 2013 at 11:32 AM, Sean Lang [email protected]
wrote:

@Ipstenu - looking at the npm repository, which anyone can publish to without being reviewed, surely the "big bad world of evil people" isn't a real issue. The repo reviews itself because users are responsible for reviewing the packages that they depend upon.
Even with peer review, I guarantee it is possible to get a evil plugin into the wp.org repo. It probably wouldn't be able to gain much popularity, but hiding evil functionality isn't hard. The point is, peer review isn't how you gain safety - it's by sand-boxing plugins and giving them a responsible API - like chrome does with the permissions API. Of course, this isn't really possible with PHP, but that's how you'd actually solve this problem.

@afragen - thanks for the link to Github Plugin Search. I was actually looking for something like that.

Anyway, the reason why I'm asking this is because I'm publishing a plugin called wp-migrate-db and I want to do updates through GitHub (because SVN is horrible). But having to download and install the zips for both github-updater and wp-migrate-db is like a 3 minute long process. It would be much easier to tell users to just download this plugin through the WordPress repository.

Reply to this email directly or view it on GitHub:
#34 (comment)

[GaryJones]

@pdclark I already have https://github.com/GaryJones/wordpress-plugin-git-flow-svn-deploy which originates from the same repo as yours does, and it does a lot more (Git submodules, assets directory, opening questions). I was just curious if it was possible to have a native Git back-end to the WPORG repo.

[pdclark]

Sounds like you've made some great additions. :) I think Scribu has a variant too, but yours is the first I've heard of with all those features.

[afragen]

I was using one of these forks and I'm now using @GaryJones's version. What I Iike best is I don't need to put the deploy.sh inside each project.

[limikael]

Quoting @slang800

peer review isn't how you gain safety - it's by sand-boxing plugins and giving them a responsible API -like chrome does with the permissions API. Of course, this isn't really possible with PHP, but that's how you'd actually solve this problem.

Out of interest I googled a bit and found this:

http://php.net/manual/en/runkit.sandbox.php

Using that, would it in theory be possible to create a sandboxed environment for wordpress plugins? One where the only way for the plugins to communicate with the rest of the system would be through a well defined api. And then the plugins would have to request permissions, like an iPhone or Android app, such as "this plugin wants to read user data", "this plugin wants to access database table such and such", "this plugin wants to create its own database tables", "this plugin wants to read and write files in directory such and such", etc... This would obviously be a HUGE thing, but has someone else thought along those lines?

[GaryJones]

Since it's not bundled with PHP by default, not everyone will have it.

[limikael]

But that wouldn't stop us from imagining it and thinking about it, right? It would be possible to imagine a solution where plugins are sandboxed if this PHP extension is installed, and otherwise the plugins are not sandboxed and the user would be warned about this. Sorry btw if this was out of context, I was just curious about if someone knew something about this and if there was maybe a discussion about this in some other place...

[GaryJones]

If you want to create a local or production environment for your own sites that run plugins ins sandboxes, go for it. It's nothing something that would be part of WP Core, nor GitHub Updater, so this isn't the place to discuss it in-depth.