Bug in Wordpress updated plugins check

[freediver]

I have discovered a bug in wordpress plugin update checker.

The problem appears when the plugin name given in plugin.php file is a different to the one given in readme.txt file. The first one is used by wordpress client to check for updates against repository, and the second one is used to name the plugin by repository itself.

The bug will cause no updates to be shown although updated version exists.

Example can be seen on JP Admin StylishBlue plugin ​http://wordpress.org/extend/plugins/jp-admin-stylishblue/#post-5031

readme.txt and repository name: JP Admin StylishBlue

.php and plugin name: JP Custom Admin CSS - Stylish Blue

Solution is either to change the repository api to recognize plugin name sent by the client or to change client wp_update_plugins() (or get_plugins()) function to extract the name from readme.txt file.

[neoen]

I also encountered this problem - new version of plugin exists, but there is no update notification.

But only on one website (WP 2.5, problems were also in 2.3.3). Second website works well (also WP 2.5).

Example plugin - NextGen Gallery.

[ozh]

More reports & tests & head scratching: <​http://comox.textdrive.com/pipermail/wp-hackers/2008-April/019376.html>

Basically, the system doesn't check against a plugin name, but its directory name in the SVN repo? I'm lost.

[Denis-de-Bernardy]

related bug: plugin update notifications should not check plugins whose versions contain 'fork'

[DD32]

related bug: plugin update notifications should not check plugins whose versions contain 'fork'

In cases like that i'd suggest changing the plugin name is the best way to show that the plugin has changed.

How do i know that a 2nd version of the forked plugin is available otherwise? :)

[mdawaffe]

The reported bug was fixed some time ago. The "JP Admin StylishBlue" plugin was not returning the correct data because of another bug, which has also now been fixed.

api.wordpress.org tries to guess what plugin you're talking about based on a number of pieces of information:

• The Plugin URL of the plugin as reported by the plugin header. Problem: some duplicates, changes from plugin version to plugin version.
• The local directory name of the plugin (if downloaded from the plugins directory, most plugins will be installed in a subdirectory of wp-content/plugins whose name matches that plugin's SVN directory). Problem: Not everyone puts the plugins in the "expected" directories.
• The Plugin's name as reported by the plugin header (api.wordpress.org compares this to the plugin's plugin header name NOT the readme.txt name). Problem: Some duplicates, changes from version to version.
• Failing the above, the sanitized version of the plugin name (sanitize_with_dashes()). Problem: Same as above.

It weights the different factors (listed above from most to least important).

The biggest problem is that api.wordpress.org only checks user-submitted data against the most recent version of each plugin. A big help would be to store some kind of signature for all versions of all plugins. I'll work on getting that set up.

Another problem is duplicate data. Storing a signature for all plugins and all versions would help some here too. Right now, if there are plugins with duplicate plugin URLs, there can sometimes be mixups since api.wordpress.org only compares the fields (URL, name, dir) one at a time (URL =? URL, name =? name) instead of all at once (URL,name =? URL,name). This is currently necessary because the data can change between plugin versions; if we tried to compare all fields at once, we'd almost never get matches.