Simplicity in 2.next - plugin update checking

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Simplicity in 2.next - plugin update checking

Peter Westwood
-----BEGIN PGP SIGNED MESSAGE-----
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?

westi
- --
Peter Westwood
http://blog.ftwr.co.uk



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD6RWHVPRdzag0AcURAp/ZAKCGKAf5B/bG/2zXLqBx6/EkoeuftgCgrPsR
xecCZZO+MPh41IPcyP4y9vg=
=sKxK
-----END PGP SIGNATURE-----

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next - plugin update checking

Douglas Stewart-3
Peter Westwood wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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
[hidden email]
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next - plugin update checking

Arne Brachhold
In reply to this post by Peter Westwood
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.


Arne




_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

RE: Simplicity in 2.next - plugin update checking

Vogel, Andrew (vogelap)
In reply to this post by Peter Westwood
EXCELLENT idea. Good thinking.

-andrew vogel
Manager of Professional Programs
University of Cincinnati
College of Pharmacy
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Arne Brachhold
> Sent: Wednesday, February 08, 2006 4:06 PM
> To: [hidden email]
> Subject: Re: [wp-hackers] Simplicity in 2.next - plugin
> update checking
>
> 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.
>
>
> Arne
>
>
>
>
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next - plugin update checking

Peter Westwood
In reply to this post by Arne Brachhold
-----BEGIN PGP SIGNED MESSAGE-----
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
information.

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 ;-)

westi
- --
Peter Westwood
http://blog.ftwr.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD6m5xVPRdzag0AcURAkrSAJ4jIaeVPAVOl8usXI+KffBF3TGabACfR0KC
5SgPm1dESZtj+XsuTQjN3zY=
=u8F1
-----END PGP SIGNATURE-----

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next - plugin update checking

Owen Winkler
Peter Westwood wrote:
> 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.

Yeah, I don't think plugin-server-side checking is necessary.  If the
right information is sent back for the request, it could be made via
rest, and handled by serving a static file in response.  The core
functionality should parse the response and determine the best course of
action.

Still, the response could contain enough information to come up with an
answer to the question that is as detailed as "Current &
Compatible"/"Not compatible & No Update"/"Not tested"/"Needs Update" or
any number of other results.

> 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.

Matt Read has a good plugin in beta to cannibalize:
http://mattread.com/archives/2006/02/introducing-installer-the-plugin-2/

It installs and uninstalls plugins and themes from zip archives.
Basically one-click.  Pretty darn cool.

Owen

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers