I have often wondered whether I could write such a thing. Problem is that a plugin can (and sometimes needs to) make changes – database and sometimes files too. There is NO way for an external party to know what changes were made. A plugin that could manage the process would have to (as noted by nicole) backup the entire DB and all the files.
This would be very time consuming and hopefully redundant (Because one should have one’s own backups happening as well). If you decided you needed to restore, it would take a while. Might be quicker relying on your normal backups (and good to test them too!)
All up I think one absolutely simply has to allow the time for a serious website.
Recommended procedure (I kinda do this ongoing, – I keep a wp beta dev system going with all my frequently used plugins and apply updates as I see them, not a rigorous test, but alerts me to any obvious funny bugs)
- Before upgrading, read all changelogs and check support posts. (I
subscribe to key ones in a feedreader so I get early warning of
others experiencing issues – I scan the titles very quickly regularly) - Do not be the first to upgrade unless it is a dev system
- Upgrade all on dev system first. You may not see all impacts due to differences in data/system, but it’s a start.
- If changelogs indicates any risky changes, definitely test that area first. If no changelogs – look at the version number – if they went to a x.0 it’s a big change.
- Do not auto upgrade where you are not watching the screen – need to
see any messages. - Navigate to all upgraded plugin settings in case
there are ‘upgrade’ actions that only kick in if you are admin and
on the plugins page - Do not upgrade late at night – need to allow time to fix if there is a epic ‘FAIL’
- Be well mannered at all times if you need to post a support note. It may be your very unique
combination of ‘stuff’ causing a problem. - Do post a support note describing your setup as well as possible and the symptoms you saw – this helps all