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.
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.
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.