needlecream

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.

If you are readers of it that is!

I updated the pictures for Chapter 28 Part 1 so they aren't so low-res. I was using a new picture saving method when I did that chapter but I've updated them to look nice now. That was really bothering me (for a long time!) because I worked hard on a lot of those shots.

I am, in fact, slowly, working on Chapter 31

Progress looks like this: an un-small handful of pictures from like a year ago, unedited screenshots from March and then November, 2 notepad documents with poorly spelled ideas, about 40 small pieces of paper with ideas for this chapter and future ones on them

We all know the latest and contested change about the note counts that was thankfully rolled back, but its ramifications are still in use. Tumblr now considers every reblog a post in its own right, as you can see from the new banners for the same post as above:

The turn this website has taken regarding the ownership of posts is at best discouraging and at worst a massive disrespect done to all the artists, creators, gifmakers, fic writers and meta writers out there, making fandom fun and alive. If artists, writers and gifmakers don't get autonomy over their own art being shared on this website, how is a reblog different from a repost, something tumblr actively discourages from doing? How can the OP appeal for a post if they don't even know it's flagged? Why are we taking away ownership of the art from the artist, the human behind it?

How do I appeal?

Tumblr has this very useful feature, both on the website and on the mobile app:

You can find all the flagged posts on your blog either by going to the relevant blog>right hand menu, below Posts, Followers, Activity>Review flagged posts on the website OR by going to Settings>Review flagged posts on the mobile

Then you click on Appeal, and write a very short reason why, describing the post. You can even write this:

This post has nothing that is against the User Guidelines.

Viral Hell & The Power of the Call to Arms

To my friends and followers: my condolences for going viral are accepted. I love you. Let’s look at the numbers. My original post on this has cleared 24,000 notes. This is exactly why a Call to Arms was necessary. When we first saw the decoupling, we saw the immediate theft of credit.

In my case, over 10,000 notes were stolen or hidden by the uncoupling before I even realized the extent of the damage. This isn't just a UI preference. It is the systematic erasing of a creator’s reach and legacy.

Why we cannot stop now:

Staff’s reversal is a tactical retreat, not a surrender. Their language proves they still intend to push for a version of decoupling in the future. We forced their hand because:

The volume of feedback was undeniable. 24k notes on a single advocacy post is a massive indicator of user dissatisfaction.

Emails and Support Tickets work. They specifically cited emails as a reason for the reversal.

Public pressure creates friction. By making this a PR nightmare on Bluesky and X, we made the cost of the update too high for them to maintain.

The Mission Moving Forward:

We have won the first battle, but the Double Speak in their post tells us the war isn't over. They are going to try to rebrand a change like this in a few weeks or months.

Keep the pressure on: Continue to reblog your concerns when they surface.

Stay Vocal: They are betting on us getting tired and going back to business as usual. We need to show them that our safety and our creative credit are non-negotiable. Continue to voice concerns when they surface.