Changes

I just upgraded my wiki siteLast updated in 2008, it was time to revisit this page and thought I would write down the steps for further referencemake some new notes. Even though the README, UPGRADE and online help are very detailed, I find it helpful to note my personal preferences, observations, and clarifications where I might not understand . Still, for the do-it-yourself types, the [[mw:Manual:Upgrading#Using_Git|official docs]] are the instructionsbest resource.If you need professional help with MediaWiki, then contact [[User:Freephile|Greg Rundlett]]

The process obviously started with downloading the source from the web. However, since the wikipedia project uses the continuous integration method of development (meaning they always run their own latest code), I decided to join that follow the same practice and run off SVN trunkeither the latest release branch or master from the [[git]] repository. So, I simply did a <code>svn checkout http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3composer update --no-dev && git fetch</code> to get the code. I performed a diff of the entire tree v. my installed copy using the venerable KDiff3 to get prepare for an idea of the magnitude of the code changes; to learn by reading some code changes and get a feel for the 'current best practices'. It also helped me to see what old stuff was deprecated, or that I had lying around as cruft on my filesystem. Since it had been a long time since my last upgrade, there was a large delta. I didn't want to or have time to look at all the code improvements so I moved on to the next step.

I copied my filesystem as a backupand testing ground.

For the database, I copied my database as have a backup. I noticed script that phpMyAdmin failed silently in addition to timed backups, will create a spot backup because it exhausted the PHP memory limit. When I say 'failed silently' I mean that it saved the export as a compressed file on my system without complaining, but the contents of that file were the plain-text error message from PHP. I could have increased the script memory limit, but instead I found that an uncompressed version of the export would workdemand: <code>~/bin/backup. I also could have used mysqldump or the Mysql Administrator clientdb.sh mediawiki</code>

Having downloaded the desired new version of the software, either as a packagefrom SourceForgeThe mechanism for loading extensions has changed, or via an export from Subversion, decompress the files asneeded, and replace the existing MediaWiki files with so the newold 'requires' can be replaced by 'wfLoadExtension' function <code>require_once\( *"\$IP/extensions/.*/([^/]*)" * \); wfLoadExtension( '\1' );</code>

With the software downloaded (git fetch), and a check to see if you've modified anything (git status), you can simply switch the branch you're on <code>git checkout -b REL1_26 origin/REL1_26</code> and then do the database upgrade. You should must preserve:

* The AdminSettings.php DatabaseSettings file, where it exists

If using an alternative uploads directory, preserve this; and if using customskins, preserve these too. The core code is now updated. I did all of those because I do have an 'accessible' skin. The easy way to do the filesystem upgrade is with the rsync command. Besides the filesystem update, you also need to create a AdminSettings.php file with credentials to access your database. :<code>user@host:/path/to/docroot$ rsync -vrc --delete --stats --progress --exclude images/ --exclude extensions/ --exclude LocalSettings.php --exclude skins/disabled/ mediawiki-1.6.1/ wiki</code> 

In order to quickly upgrade, revert or take the site offline, I you can simply use a symbolic link and point that to the correct target folder that I want. In order to complete the upgradeHowever, all note that was left was to change the target of my wiki symbolic link from phase3_1_7_1 to phase3_1_11this can present problems for your extensions when <code>$IP</code> is not defined correctly