Really good advice, Brion. Much appreciated.
(And yes, we are for sure doing the upgrade in a sandbox!)
:__)
From: brion.vibber@gmail.com [mailto:brion.vibber@gmail.com] On Behalf Of Brion Vibber Sent: Wednesday, October 19, 2011 10:31 AM To: eric@longjump.com; MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] Upgrading to 1.17
On Tue, Oct 18, 2011 at 6:56 PM, Eric Armstrong eric@longjump.com wrote:
The download page for 1.17 has the (somewhat scary) comment:
If your MediaWiki installation is heavily modified, it may be difficult to incorporate the latest official changes/updates. (So here's version 1.6.5. It's good for maybe a year.)
I accept the need to do whatever integration is necessary-especially since the one-year clock has been ticking for a while now--but I need to know:
a) What constitutes "heavy" modification? --We have a installed a number of plugins, have defined some variables, have created several customized skins. Is that heavy or light?
It's not clear from the above whether you've modified MediaWiki at all, or if you've just dropped in extensions and skins with no modification whatsoever.
If you changed files that were distributed with MediaWiki, then you've modified it and it's up to you to figure out how to perform those modifications on the new version.
Extensions, skins etc can still be problematic, for instance if they make assumptions about internal interfaces which have changed. Skins are particularly fragile, as it's a poor interface to begin with and has never been very stable.
You're also more likely to see errors related to extensions exacerbated at upgrade time; for instance if you also upgrade PHP you may encounter new problems related to changes in PHP's handling of references in function parameters. You may also find that updates in core that clean up old incorrect use of references cause extensions that have not been similarly cleaned up to require modification.
b) What, in general, should be the migration process? I'm guessing there are other kinds of modifications that could be done. So ideally the upgrade notes would include a taxonomy of cases: - If you've done "X", you'll need to do "Y".
1) Make a testing/staging copy of your site -- if you are not already doing this you are in trouble :)
2) Upgrade the testing/staging copy following standard procedures in the instructions (pull in updated code, run the updater script)
3) Test that everything works.
If anything doesn't work as expected, debug and fix it. Follow normal debugging procedures that all software developers and system administrators are familiar with, such as testing small changes, turning individual pieces on and off to localize the source of a problem, etc. Make use of error messages produced directly in output and in system logs. Check the source code when you see line numbers or backtraces. Google your error messages to see if people have seen them before. If you are not familiar with how to find error and system logs from PHP, please check the documentation on php.net, the documentation for your operating system, or contact your system administrator for information.
-- brion