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

Peter Westwood peter.westwood at ftwr.co.uk
Wed Feb 8 22:19:29 GMT 2006

Hash: SHA1

Arne Brachhold wrote:
> Hi,
> the problem with non-working plugins after WordPress updates could
> be avoided if we check them for problems BEFORE upgrading it.
> If a user sees, that some plugins won't work with the new version (and
> there are no updates for them available), he might consider
> to wait until they are compatible.
> The installation screen could check for plugin updates like Peter
> Westwood mentioned in the mail above. The webservice (or whatever) could
> give a response like:
> - Up to date and working with the new version
> - Not working (and no update available)
> - Not tested (use at your own risk)
> - Needs update to work (and is available)
> "Not working" should disable the plugin automatically so there are
> should be no errors after installation. "Needs update"
> should download the new version and install it after the
> Wordpress update has finished.

This kind of more advanced functionality required more heavy lifting in
terms of the webservice providing the update info than a simple update
message - it also makes it easier to implement in the xmlrpc case than
the rest case.  Which may increase the processing load on the plugin
providers if they wish to use the functionality.

The rest case switches from returning some HTML to display to providing
a parseable resource, for example an xml document, which provides the

I think that the best first step is to get update notification into the
core.  If we then move onto update download and install ability that is
a good improvement that can build upon the previous work.

We just need to ensure the design has the extension in mind ;-)

- --
Peter Westwood
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the wp-hackers mailing list