Plugin GUIDs

[mdawaffe]

When a blog submits a list of plugins to the plugins update API, the API has no way of uniquely identifying the plugin; it's forced to do heuristics to make a best guess.

There are occasionally plugins that have the same name, for example, that make these heuristics difficult to perfect.

​http://groups.google.com/group/wp-hackers/browse_thread/thread/69fa8f52249b13a0

Attached is a patch to get_plugin_data() that adds a meta datum to the plugin header: "GUID".

This GUID would just be the URL to the plugin's page on the WordPress.org Plugins Directory: e.g.

​http://wordpress.org/extend/plugins/akismet/

I propose "GUID" because it's intentionally opaque; I don't think people will confuse it for anything they're supposed to do anything with (as opposed to "Update URL" or "Update GUID", which make it sound like I go there for updates or need it before updating).

I propose the URL because it gives us namespace::identifier for free and is understandable by humans and machines.

The intention is that these GUID lines would be automatically generated by the Plugins Directory to reduce plugin author error.

[mdawaffe]

better get_plugin_data() readability and patch for GUIDs

[dd32]

Sounds good to me, However, You've got an error in the logic:

foreach ( $data_keys as $field => $preg ) { 
                preg_match( "|$preg:(.*)\$|mi", $plugin_head, $match ); 
                if ( empty( $field ) ) 
                    $plugin_data[$field] = ''; 
                else 
                    $plugin_data[$field] = _cleanup_header_comment( $match[1] ); 

empty($field) probably isnt what you were after... probably empty($match)

But it could also be written as:

                if ( !preg_match( "|$preg:(.*)\$|mi", $plugin_head, $match ) ) 
                    $plugin_data[$field] = ''; 
                else 
                    $plugin_data[$field] = _cleanup_header_comment( $match[1] ); 

Also, This overlaps with the ticket to add a filter to the list of plugin headers returned, All that would be extra is a preg_quote on $preg and a filter.. - #8964: enhancement: Allow adding headers to get_plugin_data (accepted) - However, looking at that patch.......lot of extra code there :)

[mdawaffe]

one fewer bug

[mdawaffe]

Nice catch, thanks.

I think the loop in the patch above is a little simpler than the patch on the other ticket.

[dd32]

Yeah it is much simpler, Just thought I'd mention its existence.

[westi]

Reviewing this...

[brantgurga]

This is a fine idea, but they should not be called GUIDs. GUIDs have a pretty strong and standard definition. Using a URL is most definitely not a GUID in the typical usage. Using a URL as an identifier is what RDF does, and the terminology used there is URI of which URLs are only a subset.

[dd32]

This is a fine idea, but they should not be called GUIDs. GUIDs have a pretty strong and standard definition. Using a URL is most definitely not a GUID in the typical usage.

Why does the fact the GUID happens to be in the form of a URL matter? Its still a globally unique identifier as nothing else can exist at that url. Being prefixed by WordPress.org helps push home the fact that its a Wordpress.org plugin.

A guid of plugin.wordpress-org-hosted.akismet works as well, But a URL is a much friendlier manner of it.

[markjaquith]

We discussed this, and we're uncomfortable altering the PHP of a plugin. Some plugins have md5 information, and this would break that. It would also offset all patches by one. As an alternative, we suggested putting that guid in the readme.txt Perhaps use:

WPID: ​http://wordpress.org/extend/plugins/subscribe-to-comments/

WP.org should strip that from the readme if someone has mistakenly added it, and readd it, nearish the top, before offering the plugin for download. WP will scan for this, knowing that it'll be near the top, and this additional info can be passed along in API calls to increase accuracy.

Third party plugin repos can use their own URL and have a third party upgrader plugin use this to resolve the plugin to an entry in their upgrade service.

[dd32]

we're uncomfortable altering the PHP of a plugin.

Automatically adding it, you're right, but letting plugins add it themselves? It'd at least help for future plugins.. and allow current 3-rd party and forked plugins a means to explain its not the original.

Adding the metadata to the readme seems like a good idea on the top, but then comes to the fact that the readme.txt is ignored for everything else generally.. and doesnt work for single-file plugins which some people still like to put in /plugins/

[mdawaffe]

See comment:ticket:6863:12 for more detail about current lame heuristics.

[Denis-de-Bernardy]

there also are cases where the plugin is not on wp.org at all, for all sorts of reasons. for instance, the wp.org folder could be empty yet "taken".

[docwhat]

I'm confused by this. All plugins that are hosted on Wordpress.Org have a canonical id, the URL to the plugin. For example: ​http://wordpress.org/extend/plugins/google-sitemap-generator/

No other plugin can have that URL, it is canonical.

Any plugins that update through another site ... well, it is the code serving updates on that site that has to worry about it. Not our problem.

Ciao!

[Denis-de-Bernardy]

Replying to docwhat:

Any plugins that update through another site ... well, it is the code serving updates on that site that has to worry about it. Not our problem.

the point was to say that you can't rely on the guid to be set...

[docwhat]

Replying to Denis-de-Bernardy:

Replying to docwhat:

Any plugins that update through another site ... well, it is the code serving updates on that site that has to worry about it. Not our problem.

the point was to say that you can't rely on the guid to be set...

I think I did a bad job explaining it. Let me try again.

Instead of using some magic number for the GUID, use a canonical URL. The URL should also act as the point of information on updates as well as information about the plugin.

For wordpress.org there can only be one and only one ​http://wordpress.org/extend/plugins/google-sitemap-generator/... I don't know how plugins are uploaded, but I doubt I can upload another google-sitemap-generator. So that solves the canonical URL for wordpress.org.

For external sites, either:

a) We don't support plugin checking and updating.
b) We support it by checking for an HTTP header.

If we do 'b' then we can provide a simple .php file that reads the README to get the current version and set the header. The php file could also include a simple styling of the README and a download link so that if a human visits the page, they get useful information.

We also add the same HTTP headers to the /extends/plugins/<plugin-slug-name> pages on wordpress.org as well.

The advantage to this scheme is that plugins can be renamed by using HTTP redirects.

We don't have to implement all this right away. We can start with option 'a' and add in features in 'b' later.

Note how you cannot have an invalid GUID. The URL must exist. Moving a plugin into wordpress.org is as easy as putting in a simple php page that redirects to the wordpress.org page (ditto for moving away from wordpress.org).

Ciao!

[Denis-de-Bernardy]

That makes more sense, yes. I'd be a bit concerned about plugins that highlight their MD5, though. I'm aware of at least one that does so (Security Scan).

[docwhat]

Replying to Denis-de-Bernardy:

That makes more sense, yes. I'd be a bit concerned about plugins that highlight their MD5, though. I'm aware of at least one that does so (Security Scan).

Hmm... I not sure I understand the problem. Though, adding an extension to the "auto-update" protocol that could look for an optional md5 file, either passed explicitly via a header or by just trying to fetch <plugin-name>.zip.md5.

Also, don't forget that HTTP actually supports "Content-md5" headers. The PHP file that servers the page can server the file and the contents of the md5 file.

So we have several options, there.

Ciao!

[hakre]

The Plugin URI could be used as a pseudo-GUID as well. Should do the trick out of the box.

Otherwise for true GUID functionality, there must be some kind of webservice as a central registry where you can get "your" GUID.

Because of [12044], I think the patch is not valid any longer. That's not a big problem because the new changes should be even more easily integrated.

[hakre]

Patch against current trunk

[hakre]

Suggestion: It would be better if the get_data (reading) function would not contain any configuration specific details (e.g. by dealing with concrete field names) but by only providing an array of all header fields and their values.

It can be dealt on that normalized data later on so that stuff like header field names or how to write something inside the file would be seperated concerns.

[docwhat]

Someone has an RFC 4211 UUID code for PHP: ​http://www.php.net/manual/en/function.uniqid.php#94959

That should work for a GUID.

[hakre]

no it does not, you can not ensure a propper GUID w/o a central registry (even thogh a UUID is pretty good if you don't have that).

[docwhat]

I dunno....the chance of a v3 or v5 conflicting is so small that I doubt we care. Heck, v4 is probably more than good enough.

Reference:
​http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Version_3_.28MD5_hash.29
​http://tools.ietf.org/html/rfc4122

Using the URL of the wordpress blog should be sufficient, once it is set. Otherwise, you could use the MAC address, though I'm not sure how to get that via PHP.

I don't think it's worth having a central registry, especially since it'll upset privacy advocates. UUIDs are "good enough" for tracking stats.

Ciao!

[hakre]

As I wrote, UUID is pretty good if you do not have a central registry.

I do not want to sound like a nit-picker here, but you write it yourself, there is at least a chance that UUID will conflict and this ticket is technically about a GUID which, to expand the term, is a Global Unique Identifier. That means, it is unique per definition and implementing it comes with no conflicts by that, so even not by chance. Just to draw the line.

The rest is about personal opinion of wether someone want's to implement a GUID or a UUID then or just some fantasy name, re-use the URL or whatever.

Just as additional feedback:

A central registry won't necessarily have privacy issues. It will only offer a GUID once, so it's free to request by anyone and only need to be set once by the plugin author. Next to that it would be optional, no plugin author is forced to use a GUID. Each header field in plugins is totally optional, even the plugin name. Won't make any sense for non-shared plugins anyway.

The good thing with the UUID infact is, that since this is a documented algorythm, everybody could generate her or his own plugins ID. I think we should go for it, looks like the simplest solution.

[hakre]

since this got no further traction I added an interim patch that reflects all current options in documentation.

[hakre]

Related: #13418

[hakre]

Related: #13699

[westi]

I'm still not convinced we need a explicit "GUID" system while we only support one update endpoint out of the box.

Based on the fact that there has been no progess on this in over 18 months I am closing this as maybelater.

I think there are much more important things to work on with respect to plugins at this time.