SamuZai
Touhou-Project.com
Touhou-Project.com

patreon


The Wheel

Hey all, hope you’ve been well. I’ve been busy working on a number of things as of late. Though I’ve generally been pressed for time and focus, I’ve managed to get plenty done. The changes I’ve pushed over the last few days may not be the most glamorous of things but they’re improvements across the board. So, in no particular order, I’ll be talking about some of the things I’ve done.

A couple of things on the management side of things were reworked or expanded. The most obvious of these changes is the expansion of the automatic emails that are sent on occasion. THP has had a mail server more-or-less in good working order for many years; I have an email account that I use from time to time and, more relevantly, reports of various sorts are emailed to me. Things like a summary of moderation action/automatic bans gets emailed to me from time to time, so are ban appeals and so is any post that gets reported.

I expanded the emailing bits of code to make it a bit more generic and a bit more flexible. In other words, the work I’ve done allows emails to be sent to multiple addresses and also discriminates against internal access levels. Now other members of the staff can set an email address in their settings panel and receive relevant notifications. All this is much less fancy than the average user panel on a typical site but it’s a step in the right direction in terms of experience gained and design foundations for expansion to regular users.

On another note, I also gave taggers a little more power in switching the status of old stories to their correct state. As a lot of the data was entered into the story list automatically, there’s no doubt a lot of stories that are set to “abandoned” or “completed” that ought to be set the other way around. Or to something else. I don’t expect this to have much of an immediate impact seeing that we have few taggers, overall, and most of those aren’t really active, but it’s one less excuse for people to yell at me to fix things instead of doing it themselves.

Over the past few months, I’ve also been hardening THP’s server in fits and starts. Just your odd rule to deal with a sudden burst of requests from a single source here, banning unauthorized login attempts there. So part of what I’ve done is employ rate limiting more aggressively for certain things and, in some cases, that’s led to some rewrites of how the site serves certain things. With this latest round of changes, I overhauled how moderators get all the IP address to posts in a thread. The very old Kusaba X way of doing things was querying posts sequentially and now, with the changes made, there are way fewer database queries and the asynchronous response only happens a single time. A little more filtering and smart processing needs to happen server-side but it’s well worth the fewer open connections and requests.

As I dealt with asynchronous requests for one feature, I found it a good excuse to deal with most other features. As board and story pages are static HTML files, most dynamic content depends on client-side scripts. So there’s about a dozen or so asynchronous requests that might affect content on the page depending on user settings and actions.

There wasn’t really a standardized way of handling all those requests until now. This was partly due to some of the first client-side features being reimplemented from Kusaba X’s code but mostly due to the hodgepodge nature of feature expansion on my part. That is to say, I didn’t approach things with consistency and foresight and, in some places, used tools granted by the jQuery library to make things easier and native JS implementations for other things. It’s the sort of thing that’s common enough when you’re slowly doing bits and pieces over the years of features that aren’t directly related to one another.

Now, all the asynchronous requests done on the board pages go through a common custom function that I wrote to accommodate the site’s needs. It saves a few lines of code but, more importantly, helps maintainability. I had to re-test most of these features one by one and make a few changes to some of the callback code for them to make sure that things didn’t break. Even with the old way of doing things I had managed to avoid the worst of callback hell so I didn’t spend too much time bashing my head against the monitor when updating things. An extended testing period of a few days and with all sorts of permutations was well worth catching unexpected bugs and issues.

A little aside for those of you who might know a bit of JS: I used the old XMLHttpRequest way for AJAX instead of the more modern fetch for all of this. Why? Well, I had already used the former in some of the code and was already familiar with its intricacies. As the code is relatively simple, it doesn’t really matter much either way which is used.

As my rewrite focused on using native JS instead of jQuery features, I also then figured I could reduce the overall dependency on this library in the code. Now, I could talk at length about the usefulness of it and why THP uses it in the first place but I think that’s best left for another post. It’s more important to note right now that it’s a somewhat modular library and that it can be built without certain features if needed. Seeing as I had stopped using all of it’s AJAX features, I figured I might as well get rid of that. And while I was at it….

I shaved off about 20 KiB from the file that’s loaded by every user by limiting features. Not all of that was simply AJAX and some of it were other effects and shortcuts that were rarely used. Rarely, but used nonetheless; more code was rewritten to use plain JS and more rounds of testing were needed to make sure nothing broke. Things like the local timezone had to be changed and designed differently, as plain JS doesn’t have in-built ability to format an arbitrary date in the browser’s timezone. Shorthand for certain events like clicks or button presses in certain situations also had to be reworked and so, in the end, quite a lot of code was changed.

Eventually, I plan to wholly excise jQuery and just roll my own, mostly original code. Mostly original because, like almost every (web? Feel free to judge me non-web devs) programmer alive, I have adapted examples found on the internet for certain problems. It’d still be a lot of work to achieve that but I think it’s fairly doable.

I think I got most of the bugs and edge cases brought about by these changes but there’s no real way to be sure. Even with vigorous testing, there’s still an absurdly huge amount of permutations and setting combinations possible. I even caught a small bug only after I pushed code live as one of the threads I opened on the site had something that I had not thought to check on my local testing server.

Hell, when testing I even discovered a bug that had been in the code for many months and was unrelated to the newer changes. It would have affected a lot of different pages but was subtle enough not to be noticed by the average user most of the time, I think. I only caught it because of my reread of related parts of source code when I was making sure all of my new changes were working properly. In the same vein, a small CSS error was also fixed in the user management page where a typo made a rule not come into effect. Again, not very obvious.

I don’t want to ramble too much more and make this post too difficult to stomach but I will quickly mention a couple of more things. First, I’ve also taken the time to add a little reminder for users who create a new thread to add it to the story list. It’s conceptually an extension of the extant “Edit Update” button except that it doesn’t go away unless you actually go the user page and enter the thread properly. Anything that gets people in the habit of managing their own works, possibly adding tags while they’re there and the like is good as story management help from others isn’t really a sure thing.

The other thing I want to mention in passing is that a fair bit of work was done for the various RSS feeds. There were a few errors when generating feeds in terms of inaccurate information and dates; the spec is infamously picky about what is valid. Things like removing items from feeds are also better handled and that necessitated a a little work on the deletion functions in the core parts of the site’s code.   I think things are now in a better state. RSS isn’t exactly a feature that a lot of people make a use of but it’s still something that I appreciate having around and working as well as it can.

There was a lot more I wanted to do or complete but I simply didn’t have the time to flesh out. Likewise, there’s something that I’ve been planning for the site’s upcoming birthday but I don’t think I’ll have it done by the end of the month. I’ll likely detail whatever it is I do manage to finish in the near future in another post, however, so do look forward to that.

Until next time, take it easy!


More Creators