[wp-hackers] WordPress plugin update bugs
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