WordPress (plugin) updates compare unexpected values to find update matches

[Quandary]

Updates are not shown for plugins that have space(s) in the name displayed in the plugin page (and, by extension, plugins that do not have a display name that is exactly the same as the SVN directory name). Switching the spaces to dashes in the plugin's header information causes updates to register correctly again.

This problem could be solved in a number of ways:

1. Add support for a new metadata tag for either the display name, or the repository name, so that the two values can differ. Specifying the latter is probably more backwards-compatible.
2. Have either the client or the server normalize " " to "-".
3. Force all the plugin writers to have their plugin names exactly match their depot names.

I'd really like to see the first option happen, but I don't know how much work it entails. In any case, the fact that this matchup has to happen should be documented somewhere, because it will break the update feature for an unknown number of plugins.

I've attached an HTTP request demonstrating this problem, checking against the In Series plugin (you can change In+Series to In-Series in the file to see the update info working correctly). Simply execute cat request.txt | nc api.wordpress.org 80 to see the results.

[Quandary]

Raw HTTP request demonstrating how spaces throw off update notifications

[Viper007Bond]

Works perfectly fine for me on both my local install and my live blog

[Quandary]

Thanks -- that was exactly the information I needed. :D

Turns out that the check is performed against the very first header title in the readme.txt. This is not intuitive at all -- at best it should be documented, and at worst it's a bug. I would expect that the plugin's metadata name would be compared to the metadata name in the DB, not to some other value.

Also, if someone changes the name of their plugin, even slightly, it might break things. We might want to key off of something more robust (like the repo path, with a separate metadata indicator).

[capt_kirk]

We were able to reproduce this with WPG2. In fact it was this bug report that finally made me realize why WPG2 wasn't being reported as "update available."

Details:

In wpg2.php, the name was listed as WPG2

In readme.txt, the top line said === WPG2 - WordPress / Gallery2 Integration ===

The top line of readme.txt was being compared to the name in wpg2.php, so the update notification was failing.

I've now changed the top line of readme.txt to ===WPG2=== and we're getting update notifications.

[Quandary]

I'm really fortunate, since all my plugins had the PHP metadata set to "In Series" with the space, not the dash. However, for folks that distributed versions that have different PHP metadata, users will not get update notifications. This has the potential to put plugin maintainers in a jam, since there's no way (that I can see, anyhow) to get updates to show up for everyone.

To alleviate this, some other mechanism will be needed to link a plugin to its place in the repository, in a backwards-compatible way. If we're going with plugin names, then there should be an (optional) file with a list of current-and-past names that a plugin has held. This way, plugin authors can change the name of their plugin (mostly for minor cases like my dash-to-space change) and not suffer an inability to upgrade users who have the plugin under a slightly different name. That said, there will need to be some mechanism in place to keep people from tromping on each other's plugins, accidentally or no. A little bit of oversight should be sufficient; since the repo's central, I figure it's easy enough to detect and boot out troublemakers.

Also, I ran some stats against svn.wp-plugins.org to see how many plugins conform to the naming conventions. It makes a lot of assumptions (including that there have been no name changes ;), and doesn't take into account the popular vs. not popular plugins, nor current vs. abandoned/old plugins. If anyone can supplant the stats with that information, that would be useful; as they stand, they're simply a crude indicator of how many plugins won't work with the update feature. The script used to collect the first round of raw stats is included in the tarball. The rest of the stats were generated with the creative use of Vim and sed.

[Quandary]

Number of projects with valid PHP metadata and READMEs in their trunk

[capt_kirk]

So, 358 of the 1047 plugins listed on ​http://wordpress.org/extend/plugins/ currently have a valid match between the plugin name in their plugin.php file and the top line of their readme.txt

[Quandary]

Interesting side note: Google Sitemap Generator is one of the plugins that doesn't show updates for this reason. What makes this case interesting is that older versions of this plugin are the most frequent cause I've seen of "I get database errors on 2.3" reports. The newest version is compatible with 2.3, but no updates are shown.

I have since notified the author, but this should be strong evidence that we need a better checking algorithm. See bug #5116 for a discussion of SVN path tags, and why they're a good way to handle most scenarios.

[mdawaffe]

This bug has been fixed.

The API server checks the plugin name (as defined in the plugin's meta data a.k.a. plugin header) against the list of known plugins.

The comparison is done on normalized strings.

The title specified in the readme.txt file is used only for display purposes on the WordPress.org plugin directory.