! 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
· 1 year ago
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
· 1 year ago
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
· 1 year ago
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
· 1 year ago
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
· 1 year ago
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.
All Comments
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 :(
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?
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.
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.
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.