[wp-hackers] Making Updates Friendlier?

[Tim Schoffelman]

I like the idea of color coding the upgrading nag & I would also have to
second Dougal's paragraph on cooperate environments, of which we're running
to a scenario that's pretty close to the one he listed - having something
that would smooth the process out a little more than looking at Trac or
looking at the diff between files/folders would be
nice (still thinking about what a good solution would be though).
~tim


On Tue, Sep 8, 2009 at 3:03 PM, Dougal Campbell <dougal at gunters.org> wrote:

> 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/
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>