[wp-hackers] Simplicity in 2.next - plugin update checking

Doug Stewart dstewart at atl.lmco.com
Wed Feb 8 18:51:18 GMT 2006

Peter Westwood wrote:
> Hash: SHA1
> I am not convinced that we can easily integrate firefox like automatic
> plugin updating into the core.
> If we this this is achievable then we should focus on implementing auto
> updating of WordPress itself!
> I am also not a big fan of adding supported version number headers to
> plugins because it can be very annoying when a firefox plugin refuses to
> run because of these checks. I suspect that some if not most plugin
> authors would stick in a max version so high that the checks would be
> negated.
> However, i do think there are some great improvements we could make:
> 1/ Add an update url header to plugins.
> e.g.: Update URI: rest://example.org/hello-world/
> and/or Update URI: xmlrpc://example.org/hello-world/
> These would be provided by the calling WordPress install with the plugin
> version and WordPress version to allow for taylored update messages and
> The rest endpoint would be called with the two version numbers as part
> of the url e.g.
> rest:/example.org/hello-world/%plugin-version%/%wordpress-version%/
> The xmlrpc endpoint would be well defined with example server code
> available on the codex.
> 2/ Add a new tab to the plugins section which allows the user to check
> for updates - this would check for updates for all plugins with update
> urls and display a list of update messages (HTML returned from the
> update service and cached in the db) or a message to the effect of this
> plugin has no update uri please check the authors site for updates
> (linking to the Plugin URI from the plugin header)
> This update page would only check for updates when the user requests it
> _not_ on every visits.
> We could and should limit the update checks to once per day to ensure
> that we don't DOS the authors site.
> We could provide via wp-plugins.org a hosted update endpoint service
> that plugin authors can use to take the strain if they don't want to
> host the plugin themselves.
> We could make the update service handlers pluggable to allow plugin
> authors to define there own update service handler (instead of the
> builtin rest and xmlrpc handlers)
> What do people think?

I really feel as if that's just about the ideal solution at this point.

Doug Stewart
Systems Administrator/Web Applications Developer
Lockheed Martin Advanced Technology Labs
dstewart at atl.lmco.com

More information about the wp-hackers mailing list