Feature request: Allow plugin header repo locations

[abuyoyo]

I use this plugin (mostly) without the json file. only by passing it __FILE__ from the plugin using it.

Would it be possible to have the Puc library read the plugin header file for:

GitHub Plugin URI: afragen/github-updater
GitHub Plugin URI: https://github.com/afragen/github-updater

or

GitLab Theme URI: afragen/github-updater
BitBucket Theme URI: https://github.com/afragen/github-updater

etc.

As per afragen/github-updater usage. It would allow for easier migration between the two. And allow for shorter usage like:

$myUpdateChecker = Puc_v4_Factory::buildUpdateChecker(__FILE__);

if slug is the same in repo and inside WordPress. ie. making repo_name and slug optional.

[YahnisElsts]

This seems like a pretty good idea. However, I'm not sure if/when I'll have the time to implement it.

[RichardCoffee]

I can see a problem in that the url is supposed to be the first parameter. Perhaps something like this at the beginning of the buildUpdateChecker method:

if ( func_num_args() === 1 ) {
   $fullPath = $metadataUrl;
  $metadataUrl = self::parseUrl();
}

The method parseUrl would then read the plugin file for possible urls and pass back whatever it found.

If you think this approach would work, I can submit a PR.

[abuyoyo]

@RichardCoffee

1. A new static method could be added to factory API with __FILE__ being the first param and all the other parameters being optional.
2. A new major version which would not be backwards-compatible because of different parameter order - but keeping the method name.
3. API that accepts an options array ['__FILE__, $plugin_uri, $authtoken, $slug, ...]. Doing away with parameter order altogether.

I dunno. These are design decisions. I don't really have an opinion about this.

[YahnisElsts]

Too bad that PHP doesn't support keyword (named) arguments. Personally, I would probably go with a new static method. I don't want to break backwards compatibility just to add a convenience feature.

[RichardCoffee]

I tried my hand at writing some code for this:

https://github.com/RichardCoffee/plugin-update-checker/blob/master/Puc/v4p9/Factory.php

New methods are at lines 21-65

Please take a look at it, and if it meets with your approval, I'll put in a PR for it.

[abuyoyo]

my 2-cents: API should still allow for passing other optional arguments that might be neccessary - github URI (if not the same as the link in plugin head, or github oauth for private repos, slug if the repo slug and plugin basename are not exactly the same. etc.

Also, having thought about this - I am partial to an arguments array being passed. ($file, $args) signature.

[RichardCoffee]

API should still allow for passing other optional arguments that might be neccessary - github URI (if not the same as the link in plugin head, or github oauth for private repos, slug if the repo slug and plugin basename are not exactly the same. etc.

That would be nice, however not really sure it's compatible with the plugin structure. A lot of the code is based upon not colliding with other plugins. Using filters would be a better way to go with that, I think.

Also, having thought about this - I am partial to an arguments array being passed. ($file, $args) signature.

I agree.

[abuyoyo]

That would be nice, however not really sure it's compatible with the plugin structure. A lot of the code is based upon not colliding with other plugins. Using filters would be a better way to go with that, I think.

I'm not sure I follow. There are fallbacks in the library. If a json file is not provided - the library gets the data from elsewhere. Same would apply here. If repo uri is not explicitly set as a param in $args array, the library uses get_plugin_data() and looks for [PluginUri] (or GitHub Plugin URI header if we're adding this functionality, and then falls back to PluginUri) etc.

Same would apply to unique slug. If not provided - there are ways to extract it from plugin header or plugin_basename()- which I assume is already the case. I've not dived into the source code.

I don't understand how hook filters play into this functionality.

[RichardCoffee]

Hmm, quite right. I understand.

I shall refrain from submitting a PR on this matter until @YahnisElsts expresses a preference as to preferred methodologies.

[YahnisElsts]

Personally, I'm leaning towards $fileName + an optional $args array. Settings in the $args array, if present, should have precedence over plugin header fields.