Plugin SVN & update API – how are plugins identified?

by

One thing that’s never been clear to me (especially since I haven’t submitted a plugin to the repository) is how a plugin’s unique “ID” (slug) is generated (i.e. this list).

  1. Is it a choice by the author at the point of SVN submission, or by a moderator?
  2. Is it the sanitized plugin name (title)?
  3. Is it the plugin_basename?
  4. Is it the main plugin file (without the directory name)?
  5. Something else?

I’m curious as to which attribute(s) of a plugin link it to it’s SVN counterpart (if it has one) for the plugin update API?

I ask, partly out of my nature to want to know, but also how to ensure (to some degree), my own one-off plugins won’t clash with one in the SVN.

For example, if it was only 3), I could use a highly unique directory name, but keep my plugin name (title) short ‘n sweet.

N.B. Whilst the “standard” file naming convention seems to be [my-plugin-name]/[my-plugin-name].php, I’ve become fond of [my-plugin-name]/plugin.php.

It gives all my plugins some consistency, it’s clear that it’s the “bootloader” (main) file, and from a petty standpoint I hate the repetition of the directory name.

This is another reason I ask the question, since 4) would screw me over. Plus I’d like to hear your thoughts on this “standard” too 🙂

2 s
2

When submitting a plugin, the slug becomes the sanitized plugin name, as submitted. The “Name” of the plugin can change after this, but the slug remains the same forever more.

When WordPress needs to check for a plugin update, it gets all the header information of the plugin and the directory name that the plugin is in, and sends that to WordPress.org.

Three factors are currently used to try to make a match against the plugins in the directory. Note that I say “currently”, because this changes every so often as we try to improve the matching algorithms.

  1. The plugin directory name is often the “slug” of the plugin. At least, it is if you installed it from the directory to begin with. So we check for a slug with that directory name. This is not a great indicator, but it helps.

  2. The “Name” in the plugin header is searched for as well, since Name must be unique in the plugin directory. If there is no match on that exact name, then the Name is sanitized to produce a slug, and we search for that slug as well, just in case. This doesn’t always work.

  3. The “Plugin URI” in the header is checked for a match as well. Since we know that value for all plugins in the directory, then that can be considered reasonably unique for each plugin. Thus, plugin authors are well advised to put in a Plugin URI that points to a domain they control and a URL that is unique to the plugin.

All three of these factors are then weighted, and the top result is returned. The weights used for each of the three reflect a confidence level in the accuracy of the data. For example, Name is weighted higher than the plugin-directory-as-slug, because most authors don’t change Plugin Names very often, and plugin-directory can actually be anything if the user installed it manually or something.

The closer the match to these three items, the more likely it is that that matches the plugin. But at least one exact match on these must be found for any result to be returned.

For custom one-off plugins, I tend to use the site name in the plugin name itself. This helps me with organization as well. So my one-off plugin name might be “ottopress.com – Fix issue with whatever”. Unlikely for any plugin in the directory to match your domain.

Leave a Comment