Back in August, I had tried and failed to upgrade the Flashlight Wiki’s software from MediaWiki 1.16 to 1.17. For whatever reason, I thought it would be a good time to try again. Only now they are up to version 1.18.
So I downloaded the new software and then uploaded it to my server. I put the compressed file in a new folder, but really it unzips into its own folder, so that isn’t necessary. I renamed the folder flashlightwiki instead of flashlightwiki where the original is. I also did a backup of the database and all the files in the original installation. I left the zip archive of files in place with restricted permissions in case I need to recover quickly. Last time I had to re-upload the zip file to recover.
This is where it gets tricky. I guess the way to do it is to go ahead and run the installer and generate a localsettings.php file. So I tried that out and it worked okay I guess except the wiki itself did not work exactly right when I was done. So instead I pulled up a copy of the new localsettings and the old one and did a line by line comparison to make all the same changes to the new one that I had made to the old one, while leaving any new stuff in place. Then I dragged over the images and extensions folders to the new installation.
And I got an error. I think it was something in my meta tags extension that wasn’t working. So I disabled that extension by editing localsettings. And it worked! Sort of. There were still some problems that I spent all afternoon tracking down and fixing. It would probably help to just print a copy of the old localsettings to use as a go-by. At some point I renamed the old folder and named the new folder flashlightwiki to make it the official copy. I also needed to move the .htaccess folder at this point.
There were some customizations I had done to the stylesheet of the old installation which I had made by modifying the css file in Monobook called main.css (which you aren’t supposed to do). I was able to eventually get these customizations to work using wiki pages instead, described at the end of this blog post of customizations.
I also tried to make my localsettings.php file a little more organized. Before I had my customizations all over the place. I would include a comment so I would know what I did, but really I don’t think the order matters so much and it is better to do all the new stuff at the bottom. But some stuff involves user preferences or disabling something in the top section. Moving my stuff to the bottom might also make upgrading easier. There is supposed to be some automatic upgrade tool, but I wasn’t able to figure that out.
The software was upgraded in November, so hopefully they won’t change it for a little while.
Really, I think the process should be easy:
- Unzip the software to a different folder
- Run the installer there and generate a localsettings.php file
- Make a backup of this localsettings file
- Create a hybrid localsettings that takes code from the old and the new files (this is the hardest part)
- Move the hybrid localsettings, images, extensions, and .htaccess files to the new folder.
- Rename the old folder to something else. Rename the new folder.
Tweak the CSS if there is a new skin involved.
For a simple update, where I don’t need to create a new localsettings file, the process is:
- Purge the objectcache.
- Export the database in phpAdmin to have a backup.
- In cPanel File Manager, make a zip archive of the flashlightwiki folder.
- Change permissions of the zip file so the world can’t read it (otherwise they could get the localsettings file which has your password in it).
- Download the zip archive to have a backup.
- Download the software from MediaWiki to my hard drive in my web browser.
- Using Filezilla, upload the MediaWiki zip installer to the public_html folder of my server space
- Using cPanel’s File Manager, unzip the file. It will unzip to a new folder.
- In the new installation, delete the Images folder (or rename it, but it is empty),
- Copy the Images folder from the original installation to the new one.
- Copy the Cite, Google AdSense, Google Translator, and UserMerge folders in Extensions over to the new Extensions folder along with the two Meta Extensions which are just files. The other extensions are included in the installation.
- Copy the WPTouch skin folder and file from Skins over to the new Skins folder.
- Copy Localsettings.php over to the new folder.
- In FileZilla, copy .htaccess over to the new folder (.htaccess doesn’t show up in cPanel’s file manager).
- Rename the old folder to flashlighwiki-old. The website is now offline.
- Rename the new folder to flashlightwiki. The website is now online again.
- Test the site by browsing, editing, and signing up a new user.
- If everything is working, delete the old installation, the zip archive, and the installer zip file (maybe wait a day).
In WordPress, you press a button and it upgrades the software.
Three days after I originally wrote this, they released 1.18.1. I don’t think I’ll bother, but the minor releases are supposed to be easier to install.
It was a rainy Saturday, so I decided to give the upgrade a shot and see if I’ve gotten better at the process. So I downloaded the file, uploaded it to my server, and unzipped the files. I ran in the configuration script and then tried making a copy of .htaccess and localsettings.php along with the folders images and extensions. I couldn’t figure out a way to do this in Filezilla, so I copied those files to my local hard drive which took a while. Then I was uploading them back and it was taking even longer. So I aborted that.
Next I just tried the easy way. I deleted the previous installation and unzipped it again. This time I renamed the original extensions and images folders and then just dragged the good ones into place (this would keep the files from getting all jumbled up too) along with htaccess and localsettings. Then I renamed the old folder to something else and the new install folder to flashlightwiki. Worked perfectly and it was really easy.
Upgraded to 1.18.2 today. It was a little more complicated than last time because I had installed the wptouch skin for mobile users, so I had to move that over along with the extensions, images, localsettings, and htaccess. It didn’t work right at first, but I realized I had forgotten htaccess. Also they made the extension ConfirmEdit part of the default installation, so I wanted to use it instead of bringing over my own copy, but Asirra isn’t part of ConfirmEdit yet (supposed to be soon) so I had to put the Asirra files in the ConfirmEdit folder. Version 1.19 is in beta, so there will be another upgrade soon.
Today I upgraded to 1.18.3. Probably the reason I forgot to move the htaccess file last time was that it doesn’t show up in the file manager in cPanel. So I FTP’d it to my computer and then back to the new installation.
Asirra is packaged with ConfirmEdit now, but ConfirmEdit gave me some kind of bug when I logged off, so I wound up moving my old copy of captcha.php to the new installation (the offending function seemed to be getIP).
Just a couple of days after 1.18.3 came out, they release 1.19.0. So I went ahead and installed it last night. It went pretty smoothly. Because this version modifies the database, I had to go through the whole setup process. My localsettings.php file is in pretty good shape with most of the automatically generated stuff at the top and my customizations at the bottom. Asirra ran fine as a part of ConfirmEdit (which is part of the default installation), so I didn’t have to do anything with that. The good thing about doing the updates frequently is I’m getting pretty good at the procedure. The bad thing is it is time-consuming and risky. But even when I had gotten my draft copy of 1.19.0 ready and the database was converted, the existing site was still working fine in place. Then when I got the skins, extensions, and images moved over, everything seemed to work fine when I made the final change to go live with the new software.
Updated to 1.20.0 today. MediaWiki says they will update to a new version every six months. This time I didn’t even bother to re-create a localsettings file since it said I didn’t need to do that unless I was having problems. I just put the old localsettings in place after running the installation script so that it could get into the database (and the installer had to upgrade the database, which always makes me nervous because that doesn’t seem reversible, but I think it is backwards compatible). I forgot to move the WPtouch skin over until a little later, but I had left a zipped backup of the old installation, so it was easy to go get.
You should “dump” a copy of your database prior to doing the upgrade. You can use PhpMyAdmin via your cpanel. That way you could roll back the database if you needed to. Better yet, set up a cron job that makes a nightly backup and rotates them out 7 days / 52 weeks / 12 months. http://sourceforge.net/projects/automysqlbackup/
I use this with all MySql sites, storing the backups in a /backup directory one level above the public html directory. I have a script FTP these files down each night. Because it is all text and data (no photos in the database) the files are not large. You have to have another backup scheme for files (images etc.)
Went to 1.20.2 today. I missed 1.20.1 completely. Instead of replacing the whole extensions folder, I just get the extensions I have installed which are Cite, GoogleAdSense, GoogleTranslator (all in folders) and MetaDescriptionTag and MetaKeywordsTag (files). I also need to get the folder and file for WPTouch in the Skins folder. All of the Images folder. Then get localsettings.php and .htaccess, which are files in the main installation folder. Then I can rename the old folder and name the new folder flashlightwiki. Then test that the site looks okay, sign up a test user, make an edit to a page, and check out whether WPTouch is working by looking at it on the iPod.
Upgraded to 1.21.1 last night. The instructions said I could still do it the easy way by copying over my localsettings.php file after extracting everything. Then I had to do something that would upgrade the database, but I don’t know exactly what I did. I still got a horrible error because of the Google AdSense and Translator extensions. These aren’t supported extensions and it turns out they were using a function call that is no longer supported. I fixed the AdSense extension by just downloading the latest copies of the files, but there are no latest versions of the Translator files so I had to comment out the line about wfLoadExtensionMessages in the GoogleTranslator.class.php file. Before I found out about that, I had just removed those extensions, but they seem to be working now.