Make WordPress Core

Opened 8 years ago

Closed 6 years ago

#6863 closed defect (bug) (duplicate)

Plugin Update Notification incorrectly notifies

Reported by: csogilvie Owned by: mdawaffe
Milestone: Priority: normal
Severity: normal Version: 2.5.1
Component: WordPress.org site Keywords: dev-feedback needs-testing
Focuses: Cc:


We have a released Plugin on Wordpress.org - http://wordpress.org/extend/plugins/flickr-thumbnails-photostream/ which has the following headers in the PHP script.

Plugin Name: Flickr Thumbnail Photostream
Plugin URI: http://community.plus.net/open-source/
Description: Generates a random selection of photo thumbnails from a given Flickr account.
Version: 1.0.1
Author: PlusNet Plc - Developer Responsible: James Tuck (Web Development Team)
Author URI: http://community.plus.net/open-source/
Copywrite: 2008 PlusNet plc

We also have another two plugins which we use which aren't released, one of which has:

Plugin Name: Wordpress News Ticker
Plugin URI: http://community.plus.net/open-source/
Description: Displays a 'ticker' tape of items within your 'Blogroll' in the category 'Ticker'
Version: 0.1
Author: Colin Ogilvie
Author URI: http://community.plus.net/

as it's header.

On checking my Plugins page, I'm alerted to an upgrade for the other two plugins, despite the fact that there is no way that api.wordpress.org could know about them (and there's not an update anyway).

It would be useful if this could be fixed as it's very annoying.

Change History (12)

#1 @DD32
8 years ago

  • Keywords dev-feedback added

It appears that api.wordpress.org is basing it off the plugins URI.

Changing the URI to a unique value fixes it for me.

#2 @csogilvie
8 years ago

The problem, of course, is that not all plugins are going to have a unique URI which is why this problem occurred.

It would be useful if this could be changed to also work on the Plugin Name as well as the URI or something.

#3 @war59312
8 years ago

Indeed annoying so I am using http://lud.icro.us/disable-wordpress-plugin-updates/ to stop it from telling me there are updates when there are in fact none.

These two plug-ins are incorrectly reported as having updates:

Not-To-Me: https://skippy.net/SVN/plugins/wordpress/not-to-me/

It takes you to download wp-cron 1.3

WP-Cron Moderation: https://skippy.net/SVN/plugins/wordpress/wp-cron/wp-cron-moderation.php

Again it takes you to download wp-cron 1.3

#4 @lloydbudd
8 years ago

  • Owner changed from anonymous to mdawaffe

#5 @mdawaffe
8 years ago

  • Status changed from new to assigned

#7 @DD32
7 years ago

  • Component changed from Administration to WordPress.org
  • Keywords needs-testing added

Its an issue with the API not with WordPress. (Not sure if it still happens, needs to be checked)

#8 @Denis-de-Bernardy
7 years ago

  • Milestone changed from 2.9 to Unassigned
  • Type changed from defect (bug) to task (blessed)

#9 @DD32
7 years ago

  • Type changed from task (blessed) to defect (bug)

#10 @Denis-de-Bernardy
7 years ago

I doubt it'll get fixed anytime soon, personally. The update API reacts to the plugin's folder (or file stripped of .php, when in the plugins folder).

I also imagine that wordpress.org/extend/plugins reacts to plugin-name/plugin-name.php and assumes there's a single plugin in that folder.

This should probably be closed as invalid, or wontfix. There isn't much point in leaving it here to rot forever.

#11 @Denis-de-Bernardy
6 years ago

  • Milestone Unassigned deleted

#12 @mdawaffe
6 years ago

  • Resolution set to duplicate
  • Status changed from accepted to closed

Marking as duplicate of #10814.

The problem is that the API has no unique identifier for plugins. Currently, the API uses the following heuristics to guess at what plugin is requested.

$plugin_url = URL from plugin header of plugin file on your server;
$plugin_dir = santize/normalize( basename( dirname( plugin file on your server ) ) );
$plugin_name = santize/normalize( Name from plugin header of plugin file on your server );

A plugin's slug is defined as the last piece of the plugin's URL in the Plugins Directory: http://wordpress.org/extend/plugins/{slug}/

A plugin's name is the name of the plugin as far as the Plugins Directory knows: specified in the plugin header of the current stable tag version of the plugin in the Plugins Directory.

1. Find all plugins that have the given plugin_url.
2a. Find all plugins where slug = $plugin_dir.
2b. Find all plugins where slug = $plugin_name.
3. Find all plugins where sanitize/normalize( name ) = $plugin_name.

Define group 2 = union( group 2a, group 2b );

If there are any plugins that are in all groups, RETURN first such plugin.


foreach plugin in union( group 1, group 2, group 3 ) {
 score[plugin] += 10 if in group 1 (url)
 score[plugin] += 8 if in group 2a (slug = directory)
 score[plugin] += 5 if in group 2b (slug = name)

RETURN plugin with highest score.

This is super ghetto. Note that the a plugin's score isn't improved by being in group 3. We've tried that, and we get lots of false matches. It seems that scoring URL highly gives the best results. We also score group 2a (slug = directory) highly since it matches for all plugins installed "automatically" via wp-admin/plugins.php.

The heuristics can probably be improved, but the only real solution is to have a unique ID for each plugin in the Plugins Directory. That unique ID must be accessible to WordPress. That's what #10814 is about.

Note: See TracTickets for help on using tickets.