[wp-hackers] Making Updates Friendlier?

[Andy Skelton]

On Tue, Sep 8, 2009 at 3:03 PM, Dougal Campbell<dougal at gunters.org> wrote:
> 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.

I had a thought. The only way to save the user from himself--short of
educating him--is to automate. Automating a safe upgrade begins with
knowing how to do it manually. Before upgrading a site you must see
that it works as-is. Then you must upgrade the site (preferably a
copy) and see whether it works. The baseline for what's working is
whatever passes your test. Or a test suite. Uh oh, unit tests.

So if you are to really fix the problem of broken-after-upgrade you
must have tests to run and compare before and after, a copy of the
site, and something smart to do when a test fails. Code not covered by
tests (plugins and themes) would be troublesome but not fatal; process
of elimination is valid intelligence gathering. Tests for plugins and
themes should be supplied by their authors, which is a cultural shift
that will meet resistance proportional to the size of the Extend
repositories.

The size of the WordPress repository is also daunting but it needn't
all have test cases from the start. It could be begun with just one
simple test case and grow from there: does index.php produce 200
OK...</head>?

The other way would be to toss the old plugin and theme systems and
write new ones that encapsulated non-core code and enforced nice play.
That would be great for the ivory tower set but not so much for folks
entrenched like most of us are.

Andy