[wp-hackers] Richer metadata for plugin versions

Steve Taylor steve at sltaylor.co.uk
Wed Jul 11 21:15:24 UTC 2012

> It's better to update than to not-update and become increasingly
> behind and increasingly insecure. The time between exploits becoming
> public and those exploits being actively used for evil is as close to
> zero as you can imagine.

On the one hand I agree, of course, if you don't want to update at
all, you can fork the plugin.

On the other hand, I totally appreciate the original poster's point
about wanting information. If an exploit is discovered and patched,
what Otto is saying is 100% understandable. But if a load of
not-yet-mature features are piled into a new release, you may not want
to risk lost time in upgrading. This may be time that (1) you don't
have, (2) your client can't afford / won't pay, or (3) both. Despite
this, you may not want to fork because you may want to upgrade at some
point for improvements and new features, when you've got time to
address the issues these may cause.

I tend to include feature release upgrades of plugins along with
batches of work. Then, general knock-on issues that may arise can be
caught as part of the QA process for that work - 2 birds, one stone
etc. I work mostly with charities with tight budgets, so this works

For myself, at the very least having a clear indicator - output
according to plugin metadata - as to whether the version you've got
installed is lacking a security patch included in a more recent
version, that would be *extremely* useful. I appreciate that this
metadata may not be used by many plugin authors, but it seems like a
good thing to pursue.

If the core suddenly forces auto-updates of plugins, I'll be quickly
coding a plugin to disable this. I mean, that's just a dumb idea on a
live site, completely taking the human element (i.e. installing
locally and testing when you find the time) out of the equation.


More information about the wp-hackers mailing list