Non-github-hosted repos?

[jazzsequence]

Does this work with non-GitHub hosted repositories (bitbucket, assembla, private repos, etc...)?

[afragen]

It doesn't work with non-GitHub repos. As for private repos, I don't have any but if all it takes is an authentication token I believe it should work. I think all that's needed is to add the header GitHub Access Token: xxxxx but I'm not able to test it. That part of code was very similar to the code used at GitHub Plugin Updater.

[jazzsequence]

No problem. I'll play around with it.

[mastef]

Would be great if you could test it with a free bitbucket private git repo. That's a really desired use case. As it's a default git repo, just the url schemes and token generation process would be slightly different

[jazzsequence]

Doesn't seem to work with a BitBucket repo. The update notification never shows up. Tested on two local test sites (one multisite, one single) with a bitbucket-hosted theme.

[afragen]

It wasn't coded for anything other than GitHub. It may work with a private GitHub repo as there's the ability to add the access token to another header, but I haven't tested.

[afragen]

Would be great if you could test it with a free bitbucket private git repo. That's a really desired use case. As it's a default git repo, just the url schemes and token generation process would be slightly different

I don't use bitbucket. I'd be happy to consider a pull request.

[mastef]

check this out
radishconcepts/WordPress-GitHub-Plugin-Updater#16 (comment)

On Tue, Sep 3, 2013 at 11:26 PM, Andy Fragen [email protected]:

Would be great if you could test it with a free bitbucket private git
repo. That's a really desired use case. As it's a default git repo, just
the url schemes and token generation process would be slightly different

I don't use bitbucket. I'd be happy to consider a pull request.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-23726010
.

[afragen]

I believe the code for adding access tokens is already there. GitHub Access Token: xxxxx

If the coding for other services bitbucket, etc could be worked out adding support for additional header recognition is very doable.

[afragen]

I will look into a Bitbucket account for testing when I have some more free time. I'm certain we can make it work, but the repo is named 'github-updater' 😉

[jazzsequence]

well then it could be Git Updater :)

[pdclark]

I wrote the pull request for @jkudish's repo @mastef linked above. It didn't end up being merged, but I did end up rewriting that updater to support Github public and private, Bitbucket public and private, and Gitweb (generic Git) public and private updates.

I've been using it on client sites for about a year. I'll try to see if I can package it up for public viewing soon.

PS: Your updater might pair well with this plugin, which enables search and install from Github through WordPress plugin search: https://github.com/brainstormmedia/github-plugin-search/

[mastef]

@pdclark that is great news! Please do

[pdclark]

Great. :) Working on it now. My plugin was a bit sloppy. I'm cleaning it up and adding your methods for getting the plugin version from the remote plugin file. (Mine used tags only.)

[GaryJones]

I'd be happy with GitHub Updater only looking for tags, instead of reading remote files. Tags are the proper way to mark releases, and would avoid the stuff with having to define a branch (especially in a git-flow environment).

In terms of backwards compatibility, nothing should break on the WP end - just the plugin author would need to start doing release tags for any further updates to be detected.

(This might be worth starting a new discussion.)

[pdclark]

I preferred tags for my own use as well, but since I'm moving to update all plugins from Github that can be installed with Github Plugin Search, I think it makes more sense to use the plugin file version, since most WordPress developers don't update tags, unfortunately. :(

Here's what I could clean up last night: https://github.com/brainstormmedia/git-plugin-updates

Right now, it can:

• Update public and private Github repos (using HTTP Auth)
• Update public and private Bitbucket repos (using HTTP Auth)

It will update plugins that set a Git repository address in either Plugin URI or Git URI headers.

I still need to:

• Add Github oAuth back in. I have a settings page in this repo that helps users set up oAuth and generates the URL string too. I saw that you have oAuth in your plugin too!
• Add Git branch selection. I saw you have it in yours; mine just selects master

If I get around to it:

• Add a GUI for managing which plugins are updated through Git. (This is mostly for tie in with Github Plugin Search
• Add support for Gitweb back in. (Updating from self-hosted Git repositories.)

Full issue list

[jazzsequence]

Glad to see this getting some love again. @pdclark I was using your branch of @jkudish's class for a while, so happy to see you here. :)

[afragen]

@pdclark I see a great tie in with GitHub Plugin Search.

If we can work it out it sure seems that our 2 plugins brainstormmedia/git-plugin-updates and afragen/github-updater are moving closer together to solving the same problems. Thoughts?

I'm glad some of the code here helps your project.

[pdclark]

Thanks @jazzsequence! I'm glad someone was using it. :) I just let it sit on that obscure branch for a year after I was unable to come to a conclusion with Joey on merging in the large amount of changes.

I'm very much in favor of there being one repo instead of duplicating our efforts, if at all possible @afragen.

I do have a pretty strong desire to host at brainstormmedia/git-plugin-updates to facilitate tight integration with brainstormmedia/github-plugin-search, but if you and @GaryJones are open to that, I'm happy to continue putting in the effort to combine the best attributes of the two.

When prepping for release at that repo, I read through both plugins line-by-line to try to identify the best parts from each. I'm sure I still had some sloppiness when bringing in just a few methods. A couple more read-throughs and some back-and-forth discussion would certainly be needed for a complete merge.

Thoughts?

[GaryJones]

So long as the end-user behaviour is perceived to be the same minimum (that a plugin can be updated from GitHub), then a future release of GitHub Updater could have it's URL pointed to plugin header pointing to the Brainstorm Media repo instead, so that future updates come from there - all users could be ported over quite easily I think, although Andy's repo should stick around for a year+ to ensure current installs have something to search and spot the update. GPU should also have a compatibility inclusion so support the plugin headers currently used by GU.

As for whether that's desired, it's @afragen's call, as it's his project.

I would like to see some improvements in GPU (I just scanned the code for three minutes) such as making the constructor only assign dependencies (if any) and nothing more, plugin.php being renamed to be the plugin slug (though this will break updates and may not be considered worth it), documentation, unit tests and some other bits, but otherwise agree that having two projects seems redundant.

[pdclark]

That's a smart use of updates — I hadn't thought of that! (But again, @afragen's call.)

I'd be happy to see additional headers — I've seen the Github URI format being used by others as well. (And could see some devs typing it out of habit anyway. Not everyone knows Git and Github are different.)

For the constructor doing something besides dependencies, are you referring to storm_git_plugin_updates_init? The PHP version check is a technique I first saw in WordPress SEO. The problem with moving it into a method in one of the classes is that instantiating a class with __construct() crashes a site.

Improving documentation should be quick.

I'd love to have help with unit tests. I can certainly write them, but I haven't set up WordPress unit tests in many months.

plugin.php vs. git-plugin-updates.php isn't something I can claim I would never change (it's just an issue of style), but I do prefer it for a few reasons:

• Less redundant: The plugin slug is already used in the plugin folder name (typically).
• More semantic: Clearly states "this is the main plugin file".
• Quickly reusable: plugin.php can be quickly copied to a new folder to start a new plugin (one less thing to rename).

Again, not the end of the world there. I'd also like to throw magic-and-unicorns.php into the hat of names to consider. ;)

[afragen]

I'll comment more fully a bit later. Busy at work.

But I do like where this is all going and I think duplication of effort is silly. I'm certain that we're all looking for the cleanest, most efficient method of coding this.

That being said I'm perfectly fine with the continuation of this at brainstormmedia/git-plugin-updater. Honestly I think the project will get more traction @pdclark as Paul has much better rep in WP community than I do. @GaryJones is invaluable. Just needed to throw that out there.

[pdclark]

Thanks, those are high compliments!

Now, please stop texting from the OR. ;)

[GaryJones]

For the constructor doing something besides dependencies, are you referring to storm_git_plugin_updates_init?

No, but I'll follow that up in the ticket you've created.

The PHP version check is a technique I first saw in WordPress SEO.

It's completely redundant. The WP bootstrap process is:

• Request gets directed to index.php
• ...which requires wp-blog-header.php
• ...which requires wp-load.php
• ...which calls wp_check_php_mysql_versions()
• ...which does a check against the PHP version and dies if it at least the required level.

All that is well before any plugins files start getting required.

The Codex twice suggests using the plugin slug as the main plugin file name. I thought there was an optimisation somewhere when looking through all plugin files that came from doing exactly that, but I can't find anything right now. If nothing else, since plugin files can be directly in wp-content/plugins, then having them suitably named has always been the suggestion.

[pdclark]

Moving these to issues. I'll reference your comment.

[afragen]

Bitbucket does do oAuth https://confluence.atlassian.com/plugins/servlet/mobile#content/view/238027431

But seems convoluted and think still have to log in to bitbucket.

[pdclark]

oAuth by definition requires logging in; the difference to @jazzsequence's point is that when logging in with oAuth, the login credentials only go to Bitbucket. Bitbucket returns an authentication token, which WordPress stores. The token can then later be revoked, and is not as significant a security risk if compromised.

[pdclark]

Also, re: bitbucket password header. There's really no need to have an additional header. HTTP URL's have a spec for username and password, which PHP parse_url understands: http://user:[email protected]

[jazzsequence]

HTTP URL's have a spec for username and password, which PHP parse_url understands: http://user:[email protected]

You're right. I hadn't thought of that. However, having a password in a style.css (which could potentially be read as plaintext in a browser) is still scary.

[afragen]

@pdclark don't you have to put the password somewhere?

I think the difference between GitHub having an access token that's not a password and doesn't allow unfettered access to the rest of a user's private repos is what @jazzsequence is referring to. It would be better, I think, for our purposes. Unless there's some other non-password key that allows GET access.

Paul, good to hear from you again.

[afragen]

Sorry @pdclark I was being dense. No extra header as user:password is in URI.

[afragen]

Non-private Bitbucket repo updating pushed and tagged. 😄

[afragen]

@jazzsequence try the latest develop branch for Bitbucket private repos. Format for header is as follows: Bitbucket Theme URI: https://<user>:<password>@bitbucket.org/<owner>/<repo>

Let me know how it works. Seems to be working here. 😉

[afragen]

It seems that Bitbucket does not allow the "public" downloading of private repos. https://bitbucket.org/site/master/issue/1087/private-repository-public-downloads-bb-733

[jazzsequence]

Guess that puts this ticket on hold until they get something in place.

[afragen]

Unfortunately that ticket has been open since 2009. I don't think it's ever going to happen and solution might be to create separate public repo for each private project. Counter intuitive. That or use GitHub and access token for private repos. Though free private repos on Bitbucket are the attraction.

[jazzsequence]

It makes sense. Supporting free private repos is asking for a lot. I don't have a problem with just using public repos (or moving stuff to GitHub if I want/need private repos)

[afragen]

I think I'll revert the private repo code as all it allows is knowing you need to update and not being able to do it. 😝

Currently plugin does GitHub and Bitbucket public repos and GitHub private repos via personal access token.

[jazzsequence]

I'm okay with closing this ticket at this point with the current functionality. However, I would like to ask about other repositories (e.g. not Bitbucket or GitHub)...

In theory, any public repo should be able to be used, right? So if I have my own repo, on my own server, can I use that? And if I'm using some other service (I was using Assembla, but since moved my stuff to Bitbucket because their system is a bit better), would the same thing apply? Or would support for each service (including self-hosted repositories) need to be added explicitly? (In which case, separate tickets should be opened for each -- this ticket is really too open-ended for that.)

[afragen]

Yes, given the proper API calls and responses we could certainly add additional class-{git style}-API.php files and add in hooks from class GitHub_Updater

If you want to work on this for any other git-style repo we should make another issue. I'm happy to extend this as needed. That was the point in much of the refactoring. 😉

I will likely need access to those git systems to help out though.

[afragen]

For Bitbucket private repo updating please refer to #59

[aristath]

There are others besides bitbucket...

Gitlab is an excellent and the most popular choice when it comes to self-hosted solutions...

[afragen]

@aristath let's create a new issue for this.