[wp-hackers] WordPress plugin update bugs

Omry Yadan omry at yadan.net
Tue Oct 2 10:13:41 GMT 2007

> No one's stopping you from providing update notifications for your plugin,
> as you've already done (and as have I for one of my plugins from back in the
> day). Infact, there's even a hook (after_plugin_row) you can use to display
> an identical message to the existing update notification.
That's nice, I might utilize this hook.
> However, I don't think something like this (checking for updates for
> non-WP.org plugins) should be in the core.  Promoting the usage of one, big
> database is best for the users in my opinion (we already did it previously
> via the Codex). It doesn't rely on some random guy's site being online. It
> doesn't require them to setup and host a script that has to be updated when
> a new version is out. It doesn't... well, you get the point.
Although I am not sure I agree with the central approach, it's not what 
I meant in my previous post.
what I meant was to allow plugin authors to create a stub project that 
will not contain the actual plugin but only the information needed for 
the version check mechanism (specifically, probably that readme.txt file).

> Plus, no one is stopping anyone from coding an API plugin that adds this
> support in. It'd be _very_ easy to do.
> But as I said, I think this is plugin territory and not core.
In this case, I think having a core service that does 
almost-but-not-quite-the-thing is a very strong de-motivator for people 
that want to come up with their own solution, because they don't know if 
all their work will go down the tubes one morning when the core service 
guys improve it and make their own redundant.

As to what you oppose: a core API that allow plugins to easily check 
version at their own home site:
I actually think is is a good idea.
let me outline a sketch:
1. plugins have an optional version-check-url
2. core consult this url when performing the version check. if the url 
exists it checks against it. else it checks against api.wordpress.org.
3. the url contain a service with the same interface as the service at 

I know this solution conflicts with the current implementation (sending 
information of all plugins to the service), but the point is a solution 
like this can be made to work, and it solves the problem presented by 
only checking version for hosted plugins.
as to your objections:
1. relying on "some random guy website": this can be made to fail 
gracefully and show the user an error message like "Can't check version 
for plugin X: error connecting to www.host.com".
2. having everyone having to update their script with every new version:
this is only true if the interface will have to change between versions. 
I think we have enough brain power here to get it right in the first 

More information about the wp-hackers mailing list