[wp-hackers] Plugin Management and Autoupdate System

Computer Guru computerguru at neosmart.net
Sun Jul 30 14:38:30 GMT 2006

> WP 2.1 is going to break plugins with some of its database changes.
> Incomplete API leads to deep-reaching plugins which will break when
> things change.  But this isn't something that a plugin author is likely
> to know ahead of time, so I agree that a max version header in a plugin
> is of little use.  I HATE how Firefox disables things, and wouldn't
> want that kind of behavior in WordPress.  However, such a check could
> be done on server side.  That is, when a new WP version comes out and
> an old plugin is found to be broken, it could be flagged appropriately
> on the update server, and the plugin could be disabled, or a notice put
> up (assuming that its brokenness doesn't kill the wp-admin, as is
> sometimes the case).

I run the 2.1 SVN at all times. I have a _lot_ of plugins. Most changes
required but a db-query variable change and they were up and running again -
that easy.

I agree with your POV 100% - It should be flagged as incompatible only when
the dev deems it to be so. My way of tackling this problem is by keeping the
maxversion field, but in the API docs making it clear that this field should
ONLY be used _if and only when_ the plugin is verified broken.

The RDF generator will not have a "Max WP version" field, but rather a "This
plugin breaks if used on a WP version above:" field - to discourage the

Computer Guru
NeoSmart Technologies

More information about the wp-hackers mailing list