logo
  • Home
  • About
  • Plugins

Subscribe to Articles

Death by plugin

Author: andrew Category: Uncategorized Tags: plugins

Wednesday
Jun 4, 2008

Automatic updates create a new problem for plugin authors. Users no longer have to download and install a plugin, and in the process see what has changed, they now just update it and hope it all works out. My question today is, what should plugin authors do if they know the latest update is liable to break things?

One option is to release an intermediate version. A version which contains a warning message that the next version will have major changes and so users shouldn’t update without thinking things throught first.

Another options if to bundle a previous version of the plugin. The they can either upgrade but ask the user if they want to go back, or alternatively explain the changes and then ask the user if they want to proceed with them.

Lastly, they could simply prepare to field the inevitable support queries and hope enough users read the updates page before going ahead.

I am still trying to decide which option to go for with some changes to one of my plugins.

Do you ugrade without checking the changes? I know I tend to. If so which option do you prefer? or is there something I have missed?


Share:
image image image image image

Comments

Frank (http://bueltge.de/)

June 4th, 2008 at 8:49 pm

! correctly,
and the update-function is to bad. The users like the function and upload all files, incl files screenshit and many language-files.

No visits for a update or read the history :(

Ian Stewart (http://themeshaper.com/)

June 4th, 2008 at 8:55 pm

I upgrade w/o checking for changes—unless the plugin has previously broken my blog (Like WP Super Cache). Of course, I don’t care if my blog is broken since usually it’s not that hard to fix: 1. Deactivate the plugin. 2. Go on with my life.

Out of the options presented: I’d like an intermediate plugin that hijacked the “Right Now” widget on the dashboard to let me know about the coming changes or hijacked the “upgrade your WordPress” yellow warning-box-thing. Maybe with an ajax-y close-this-window checkbox?

Christopher (http://cjw.me.uk)

June 4th, 2008 at 9:14 pm

Apart from the odd moment of weakness I will always try and check out the authors website for notes about changes etc - though sometimes there is no hint of a changelog :(
Personally I wish the upgrade process would pause once it has downloaded the zip file and display the readme file (and / or perhaps a changelog file) - and only resume installation once the file has been scrolled through / read and a button pressed.

Having a link to the readme file of each plugin on the plugin page might also be quite useful, and I think I have seen a plugin that does that (and more) - but I can’t remember the name of it.

Lothar (http://blogpimp.de)

June 4th, 2008 at 10:59 pm

I think that the automatic update function is missing one important feature: it should version-control. So if I publish a plugin for WordPress 2.6 this should be checked by the function and it should only update, if my installation is 2.6 or newer. If I still have 2.5.x, it should not update, but give me a message. That would be the only usefull solution.

Austin (http://www.ilfilosofo.com/)

June 5th, 2008 at 3:27 am

I always test plugin upgrades on a development site before pushing them live, but I don’t think the sites I manage are typical of the kind of people who use the automatic update anyways.

What I mean is that the people who automatically upgrade without checking the code are not likely to have checked the code even without the automatic update, so probably the only thing that has changed with 2.5 is the likelihood that users will upgrade, not their degree of caution.

But to answer your question, if breaking upon upgrade were unavoidable, I think I would check for the existence of the earlier version and then disable the main functionality, with a prominent admin area warning (like Akismet’s “you don’t have an API key” message). Then the user could opt in to the breakage, or (by following a link) re-install the previous version.

Andrew Rickmann (http://www.arickmann.co.uk)

June 5th, 2008 at 6:08 am

Lothar, you are right. The first thing I looked at was the plugin upgrade code because I had assumed that the actual upgrade command would feature an optional version number so a plugin author could choose to trigger a roll back.

Out of all the options I personally favour including an older version of the plugin which is enabled automatically, but which has an added page for the user to trigger the replacement.

I may be trying this out fairly shortly on my fun with sidebar tabs plugin because I need to change the class based system to an ID based system and I want to change the structure of the html. There could be a fair amount of breakage.


Photoshop Design Framework
New Plugin Release

Recommended

WP Remix Banner

Archives

  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007

Tags

2.7 2.8 Admin Advertising Air Blogging blogs Cache Cliche Coding Comments Content Types CSS Curry Death development Disqus Features Habari image Interview Licensing Modes Monday Poll New Features Organisation Personal Platform Plugin Plugin-Practices plugins Plugin update Poll premium Readers Reviews Search Simplification Snippets Spam Themery Themes tools User Interface Widgets WLTC

Copyright 2009 Fun with WordPress - All Rights reserved.

Wordpress theme by: WPUnlimited