Is plugin still working?

[afragen]

I'm getting lots of strange errors right now. Many undefined variables, etc. I don't know whether it's that I messed around trying to get FirePHP working or something else is up.

[afragen]

I have pulled latest from develop to my local install.

[pdclark]

Working okay with that pull?

[afragen]

Doesn't seem to be. Very strange. Working at your end?

[afragen]

I reverted back to an older version I had as a local branch and it seems to work. Then I updated via the update notice and back to messed up. I think it has something to do with parse_plugin_uri()

[pdclark]

I won't be able to look into it for about an hour.

FirePHP setup should just be: Install FirePHP pluginin Firefox. Install FirePHP plugin in WordPress. add FB::log( $any_var, 'anything'); to your code. Check FireBug console.

[afragen]

I'm done for the night. BTW, Firebug / FirePHP Integration seems to be simpler. http://wordpress.org/plugins/firephp-firebug-php/

[pdclark]

They both include the same code -- either can be used with FB::log() or fb()

[pdclark]

Just ran the WordPress updater to get 2.0.1, both times just changing the version number on 2.0.1 to 1.0 to trigger the update. Worked alright.

I'm on MAMP / WP 3.7. Maybe share what error you're seeing?

[afragen]

I'm on MAMP, WP 3.7.1. I had a backtrace script running in mu-plugins, I disabled it. (WP_DEBUG, true), I updated to 2.0.1 and I get the following error

Notice: Undefined variable: url in /Applications/MAMP/htdocs/test-multisite/wp-content/plugins/git-plugin-updates/includes/class-updater.php on line 123

Also, nothing listed as ready to update. Also, it seems that the updater is taking the update from the default branch in GitHub and not from master or tag (Yes, I know tag isn't yet supported 😉 )

[afragen]

BTW, the backtrace script is from http://stackoverflow.com/questions/1159216/how-can-i-get-php-to-produce-a-backtrace-upon-errors/1159235#1159235

[afragen]

The problem appears to be in line 119 of public static function parse_plugin_uri( $plugin ) or class-updater.php

  }elseif ( apply_filters( 'gpu_use_plugin_uri_header', false ) ) {

if reverted to } else if { it seems to work again.

[pdclark]

I think I may see what's happening — before, it was parsing all Git URIs and Plugin URIs, so parse_plugin_uri would always return something. Now that it's usually only parsing Git URI, there likely needs to be a catch for the case where none is set. :/

That's my best guess. I'll try to take a look to patch soon (I'm still not seeing the issue here, so I'll have to fiddle with settings to try to recreate... Or just aggressively try to catch the errors.)

Branch support is listed on issue #1 if you have time to contribute. :)

[afragen]

I think part of the problem is my extra header is GitHub Plugin URI and previously any https://github.com URI was being parsed. We ran into problem when a WP.org plugin had Plugin URI: https://github.com/…

I have some free time tomorrow to work on branch support.

[pdclark]

That would do it! It only looks for Git URI right now. We can add the extra header for compatibility, it's just not in there right now. It was probably working for you before because it was getting the URIs from the Plugin URI header!

Thanks for the help! :)

[afragen]

I think this is fixed in #33