Opened 16 years ago
Closed 15 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: |
Description
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)
#2
@
16 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
@
16 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
#7
@
15 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
@
15 years ago
- Milestone changed from 2.9 to Unassigned
- Type changed from defect (bug) to task (blessed)
#10
@
15 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.
#12
@
15 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. Else: 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.
It appears that api.wordpress.org is basing it off the plugins URI.
Changing the URI to a unique value fixes it for me.