Our Beds Are Burning

Fixing such an old forum is not easy. Documentation is rather sparse because the framework it runs on is old. There is however a more modern version, but updating is difficult. Here was the issue for the forum - upgrading failed. 

A website (usually) consists of two different parts: 1 - The files. They contain the code, scripts, designs, images, attachment, profile pictures etc. 2 - The database. The database connects all the different parts and tells the website where to find something. Everything gets stored in tables, assigned IDs and given values. Everything written, each post and topic is also stored in the database. So without the database the whole page would be useless.

It was clear from the beginning that the database was the culprit for the failed upgrades. I got an earlier backup from HL and started working.

I set up a local environment with two versions of XAMPP. One running on php 7.4 (the last version having compatibility for the forum framework version and the upgrade script to the recent version) and the other on a modern 8.3, which was the same as the version the server @fireflowersims set up for GOS.

I ran the upgrade script (which consists of 4 separate parts) on the old backup and ran into errors right away. The script would just outright crash on me, most often without a log or message. The (local) server would just stop responding. My original plan had been to upgrade to version 2.0 first, then 2.1, since it was the recommended order. However the database backup had already been partly upgraded to 2.1. That was the reason my upgrade script failed. Reversing those changes could have been a possibility but extremely time intensive.

(This is the frontpage of the upgrader. I stared at it so much. Like you can see it has a ton of steps)

Instead I asked for the current database and HL provided it to me. This one was already further along on the upgrade and I could see the error HL had run into before handing over. I had to look at the upgrade scripts and source php files to diagnose what the framework was expecting - and failing - to find in the database.

That’s where I found the main culprit for *most* of the errors: Time tables. The framework saves every action that a user does in a log, a long table with the action, an id and a date. This was where everything had gotten wrong. The upgrader expected to see one column for the date, named *day*, while the current table had a different column for day, month and year. I tried fixing the table at first but that didn’t seem to work, so I completely deleted the table and created a new empty one myself. (By now I think the issue stems from forgetting to uninstall certain packages before upgrading, more on that later)

That was possible because the log actually doesn’t hold relevant information for the forum to work. It just records each step, probably for moderation purposes. Once I had done that step the upgrade script was finally able to proceed.

There were a few more errors where I had to look at what the script was doing, find the corresponding code in the sources and edit the database myself. Thankfully the code is relatively well commented and named, so I was able to find what I needed.

Finally I got the upgrade script to run to the end and I was actually able to open the forums (local) page. I hadn’t been able to for now so it was a first. But a lot of stuff was still missing, like all the topics. I could see that the posts were back, but not sorted correctly.

The fix was simple but annoying. The forum framework comes with a repair_setting.php file which I had run several times to fix all the paths, but apparently it didn’t fix *all* of them. So back to the database I went, ran some queries and fixed them myself.

Then the forum finally worked again!

(This is what the forum looked like when I first opened it. It ONLY had recent posts)

(The working local forum, no files yet with the default theme. Seems wrong to look at GOS without the dark theme, right?)

There were still a few things I needed to fix but the database seemed to work fine now. I had never done so many queries in my life. I know SQL, and had to fix databases before but not this intensely. So I guessed I learned something new haha.

Next was the exciting step to upload my clean install to the server. @fireflowersims and I had some directory issues, but I was able to fix them manually once again.

Then I had to take a look at the files which mostly consist of avatars and attachments. They didn’t work at all once moved to the clean install. Once again I took a look at the code and realized that the upgrade script would have changed those files as well, but because I ran it on a clean install it didn’t actually do this step.

I didn’t want to run the upgrade script again, worried that it would mess up a now working database. Instead I wrote a script myself that sorted through all the attachments, looked for the IDs of the avatars from the database so it could move and rename them.

Last were the attachments. This was an easier fix. They just had to be given the ending .dat. @fireflowersims ran a command through the console and then the attachments worked too!

We were getting closer!

Next was the theme. The old theme didn’t work on the modern framework anymore so @fireflowersims looked for a new one which I customized with CSS, trying to get it closer to the way the forum looked before. I think it turned out quite alright, hope you guys think so too!

(Trying to find out what CSS class addresses what? Make everything red and green!)

(All the spider webs)

Next was packages, or mods, to the framework. Fire and I encountered some hiccups here too, since there were some leftovers in the database. The packages hadn’t been properly deinstalled before running the upgrade script, which was another source of the errors. I tried fixing them manually but one of the packages would continue to just break the site no matter what I tried, so we settled for an alternative.

Some more work was put into SSL and making the forum secure. Once again some settings seemed to just break the page and each time I had to go back in the database and manually fix what had gone wrong. It was tedious but by now I knew my way around quite well.

@fireflowersims handled a lot of the server administrative work and DNS settings. I know very little about that part so having @fireflowersims there was great and they made sure the page is reachable at the correct address.