WordPress (plugin) updates can trigger innapropriatly for non-hosted plugins
|Reported by:||Quandary||Owned by:||anonymous|
It appears as though the plugin update service at api.wordpress.org utilizes only the plugin name and plugin version to determine if an update is available vs. any plugin matching the name that is hosted by WordPress. This method breaks down if there is a plugin that shares the same name as a WordPress hosted plugin.
If the hosted plugin's version is higher than the non-hosted plugin's version, the user will be nagged to "upgrade" to a completely different plugin than s/he has installed. This probably is not the Right Thing to do. Naturally, plugin name collisions should be avoided by authors where possible, but handling this situation gracefully would be a big plus.
This may be solvable as a side-effect to #5115 -- updates could be set up to not trigger, e.g., if there is no SVN repository name metadata. This would, however, require that the metadata be present, and would break backwards compatibility for update notification.
An alternate solution would be to at least allow the user to dismiss the notification as "this plugin is not hosted by WordPress," or to add a piece of plugin header metadata indicating that a plugin is not hosted.
Another option still would be to compare the plugin's metadata with the metadata present in the repository, and look for a match heuristically in that manner. This could run into problems if, e.g., a plugin's maintainership changes for a plugin that does not utilize version tags.
Change History (6)
- Component changed from Administration to Upgrade/Install
- Priority changed from normal to low
- Severity changed from normal to minor
- Component changed from Upgrade/Install to WordPress.org
- Milestone changed from 2.9 to Future Release