On July 30 I got an automated email from the web hosting service HostGator that my CPU usage was too high and had been too high for “an extended period of time.” Using one of their cheapest plans, I have shared hosting and my CPU usage was exceeding 25% and my website was being disabled until I could fix the problem. I wasn’t even aware of the problem so they basically shut down my website without any notice. That seemed to include any script-driven websites including maybe this blog and the flashlight wiki, but not static web pages like my movie reviews. Their unhelpful advice was to get a dedicated server which would cost a lot more money, though they also pointed out that sometimes scripts can be buggy or need to be optimized to reduce CPU load. They also sent some kind of log which provided virtually no information, but all seemed related to the Flashlight Wiki. I have no idea what was going on but I do know that I have tried for a couple of years now to update the MediaWiki software, failing at least partially because HostGator didn’t provide the latest version of PHP and their technical support seemed unable to resolve the problem.
Another big part of the problem is that MediaWiki’s software is awful. To update the software on the blog, I just click a button and it happens. Updating the MediaWiki’s software is a huge ordeal and they are constantly changing how they phrase their commands so that commands I used successfully on one version will cause a new version to fail. And that failure generally gives you no clue as to what might be causing the problem. MediaWiki’s primary purpose seems to be running Wikipedia, a wonderful internet resource with hundreds or maybe thousands of super geeks running it in many languages with everyone wanting new capabilities and solutions. Given that it is one of the busiest websites on the internet, small tweaks can save tons of resources. But I just want something user friendly that I can update easily.
So the first thing to do was to write back to support and ask them to make the website work again so that I could work on it. One problem is that I use this blog to keep track of settings and modifications I have made and it wasn’t working either. Eventually HostGator complied with that, though they needed my current IP address, which was for the vacation rental house where I was. I think they were going to make the sites only work for requests that came from that specific IP address, but eventually I got them to just reinstate everything while I worked on it.
Next I downloaded a new version of MediaWiki’s software, which is 1.36.1. Then I upload that to the webiste, uncompress it, and move over my images directory. I also have some add-on extensions and skins that I use, though most are incorporated in the standard installation. You need to make sure you start with the latest versions of those so they are compatible, so each of those has to be downloaded, uncompressed and moved into position. Then I move over two key files, .htaccess and localsettings.php. Localsettings.php has all of the settings for the wiki including the name, how to access its database, and other settings like appearance and features, including who can edit articles. It is a pretty big file, but you can usually use the same localsettings.php file in a new installation instead of creating it through MediaWiki’s setup script where you could accidentally enter a wrong setting or forget some customization. Except sometimes you can’t use the file because they have changed the way commands are written, which is a problem I had run into when loading skins, and this time ran into when loading extensions. You have to go through the upgrade instructions to find out about those kinds of changes, but since it had been a couple of years since I had upgraded you have to really dig through thousands of changes, mostly related to arcane things that have no bearing on my installation.
By loading everything into a new folder and getting it all ready, I can keep the old wiki running while I am working, then just rename the wiki folder to something else and the new folder to the wiki folder and I am back up and running in a minute or less. Unless it doesn’t work, then I might try to make a quick fix, but if it isn’t working, I rename the folders back. Another key step is updating the database that the wiki uses. This stores all of the articles, users, history of edits, and a lot of settings and when they come out with new software they also add fields and tables to the database so the database has to be updated. I’m not 100% confident that once you update the database that you can go back to an old version of MediaWiki (though often you can), but also the new version won’t run without the updated database.
So while on vacation I would work on this while I got a chance, eventually abandoning my new installation which I had started with a .zip version of the files instead of a .gz version which seems to be a problem. I got the database updated, but the wiki still wasn’t working. I did other things like go through localsettings line by line to try to root out possible problems or comment out things I knew were tricky and might be causing issues.
Eventually I knew I needed to generate a new localsettings file from scratch, but my first try at that on vacation only updated the database (I think) but I got an error when it was time for it to make the localsettings file. So at that point vacation was almost over and I just left the site broken.
A couple of days later, back at home, I decided to try the setup thing again and this time I did actually get a localsettings file. I then put that file in place and tried it out, got a brief delay, and bam the site was working again. Then I loaded my customizations one at a time, testing it out and got most everything put back except one extension that isn’t critical and may have been causing the problem all along (plus I don’t think I used the new command to load the extension). The site doesn’t look 100% correct (the toolbar menus don’t have green links), but everything seems to be working fine. That night I found a place where I could CPU usage for the last 24 hours and there were no spikes, just a consistently low value of less than 100 where they consider 1,500 to be high. So maybe it is fixed? Was it ever really broken? At least I have the latest wiki software now.
Today I updated to v1.37.1 and it went pretty smoothly, but I had to remember a few things:
Copy .htaccess and localsettings.php to new wiki folder
Copy the images folder to the new wiki folder
The location of the logo file needed to point to the images folder
Needed to download and install MobileFrontEnd extension for mobile users
Needed to download and install MinervaNeue skin for MobileFrontEnd
Then it should work, but still need to:
Update the database by going to mw-config on the web page and entering the update key from localsettings.php and following prompts until the tables are updated