[wp-hackers] Making Updates Friendlier?
peter.westwood at ftwr.co.uk
Tue Sep 8 21:29:51 UTC 2009
On 8 Sep 2009, at 22:24, Andy Skelton wrote:
> On Tue, Sep 8, 2009 at 3:03 PM, Dougal Campbell<dougal at gunters.org>
>> 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
>> upgrades, it certainly seems worth discussing it and kicking around
>> 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
> 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
> 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.
Another thought that has been discussed is:
Make the update process safe and reversible.
Provide the user with the tools to upgrade and downgrade the site at
will so they can go back if something is broken.
This includes db and plugin up/downgrading.
Also integrate information into the pre-upgrade step to check for
plugin compatibility based on crowd-sourced data - i.e. not just rely
on plugin authors marking a version as supported but let the community
provide that information.
http://blog.ftwr.co.uk | http://westi.wordpress.com
C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5
More information about the wp-hackers