[wp-hackers] Making Updates Friendlier?

[Dougal Campbell]

In the aftermath of the recent WP worm, there has been the usual raft of 
FUD flying about. I won't bother pointing out any particular sources -- 
suffice to say that some of the recent posts about "WordPress Security" 
were reasonable, and many were not. It seems like every time there is 
some sort of security issue related to WordPress, regardless of the 
scope, it becomes a PR nightmare of sorts. Primarily, I think that it 
goes hand-in-hand with the popularity of WordPress: we are popular, 
therefore we are a high-profile target, and therefore when something 
goes wrong, it affects a lot of users, and therefore it gets a lot of 
attention. It's the nature of celebrity.

As has been pointed out time and time again, WordPress is easier than 
ever to keep updated. When a new version is released, a nag appears in 
the Dashboard. From there, it's just a couple of clicks to upgrade. And 
yet, people *still* lag behind. The reasons are varied, and _mostly_ 
invalid (depending on your perspective). Some of it is simply "fear of 
breaking something". Some of it is just simple stubbornness ("I just 
upgraded, I don't want to do it again so soon!"). Some of it might be 
ignorance and laziness (they see the nag, but don't look at the 
WordPress News blocks in the Dashboard, or go to the main site to read 
about it).

So, what more can we do? Not a *whole* lot, but I do have a suggestion:

In order to express the relative urgency of upgrade notices, I propose 
that we categorize upgrades into four priority levels:

  1. Minor Bugfixes
  2. Major Bugfixes
  3. New Feature Release
  4. Security Update

Each version release could be tagged accordingly, along with a brief 
description of the changes and/or impact. These priority levels could be 
used to style the update nag messages, and provide a sense of their 
relative importance (e.g. 1 = yellow, 2 = orange, 3 = green, 4 = 
REDOMGWTFBBQ). For bugfix releases, a brief, friendly message can be 
presented along the lines of "To find out if these issues might affect 
your site, visit [URL] for more details."

This information could be stored on the wordpress.org side, with a 
simple API update in the current version check functions.

Other notes: for a long time, people have requested the presentation of 
"patch releases" which only contain files which changed, rather than a 
full reinstall package. Personally, I don't mind the extra safety given 
by a full update, because it ensures that if any of my local files were 
modified without my knowledge, those changes would get overwritten. But 
then again, I update my site from the current svn branch nightly anyways.

I did see one comment over on WP Tavern which mentioned a pretty valid 
problem with updates[1]: In some corporate environments, all changes 
have to go through a multi-stage vetting process before being pushed out 
to production. Changes are put through testing/QA, and often maintained 
in a local source control system. Large-scale changes are *much* harder 
to push through such a system than small ones. It would be easy to point 
fingers and just say "your process is broken", but that isn't helpful. 
Providing an official "changes only" patchset *would* be helpful to such 
users, because the code which needed review would be more isolated. 
(Yes, they could go to Trac to see changes. Yes they should be able to 
diff against their local source control system. Yes, yes, yes. But I'm 
simplifying, and remember (to paraphrase) - individuals are smart, 
groups are dumb).

On a tangential note, a lot of people complain that occassionally 
WordPress upgrades "break plugins". I've pointed out before that 
typically, this is because the plugin author has taken a shortcut 
somewhere, and is mucking around with WP internals, instead of using an 
established API function which insulates them from changes in the guts 
of WP. But it's hard to get end-users to see it that way. From their 
perspective, it's simple: the plugin worked before the upgrade, and it 
was broken after. Therefore, the WP upgrade "broke" the plugin. You'll 
probably never convince them to look at it any other way. But I have to 
wonder if we can't try...something. I'm not sure what. But since this 
seems to be a large source of the FUD concerning upgrades, it certainly 
seems worth discussing it and kicking around some ideas on how to 
address it.


[1] http://www.wptavern.com/security-this-security-that#comment-3613

-- 
Dougal Campbell <dougal at gunters.org>
http://dougal.gunters.org/
http://twitter.com/dougal
http://twitual.com/