As mentioned by WP Engineer, WordPress 2.9 recently had a new feature added to it called bulk plugin upgrades. The interesting thing about this feature is back on September 11th, Matt published this through his Twitter feed:
Just upgraded three plugins in about 30 seconds using one-click upgrade — wish you could do them all at once though.
Well, now you can. I attended the WordPress developers chat today and according to the devs, the bulk upgrader works, all it needs now is to be tied into the API along with some cosmetics. I’m sure there are plenty of you, including myself that is pleased to see this addition to WordPress. However, I wonder what happens if during a bulk upgrade, one of the plugins fails. Does the upgrader skip the plugin and move on to the next one or does it ruin the entire upgrade? Looking forward to the answer in the comments.
Skip. When you do plugin upgrade one at a time, you will do the same–move on to the next plugin.
For those of us running enterprise MU environments, with a mix of 3rd party and custom unreleased plugins, it would be great if we could change the plugin upgrade repository to one we manage of tested and approved builds.
As it stands now, we can’t use any of the auto-upgrade features because it would entirely bypass our ITIL processes for change management and definitive software catalogs required for a high availability and recoverable environment.
well in that case, would an auto-upgrade even be useful?
custom unreleased plugins don’t need auto-upgrading, do they?
It is possible to unhook the existing upgrader and use your own repository.
Many commercial plugin developers use this approach to handle their upgrades since they don’t want their plugins in the official repository.
Interesting, I didn’t know that. I guess I should have assumed there was a hook, but I hadn’t gone looking for it.
Bubazoo, even though we don’t release all our plugins doesn’t mean we don’t upgrade them.
Are you you using SVN for your sites? If not, start. Then explore the power of the svn:externals property.
We are using SVN. Unfortunately, MU plugins can’t live in subdirectories, and the mu-plugins directory is part of the core svn. And, we’ve tried to use the hacks to change where the mu-plugins directory is, but have never been successful at it. So, svn externals hasn’t worked for mu-plugins. We use externals for themes, and love it, though.