Petting the Peeves

Hello everyone, hope you’ve been well. While I’ve been working on and off on various things, in the last few weeks I’ve mostly dedicated to fixing and improving things that had been bothering me for a while.

To start with something trivially minor: the thread expansion links did not point correctly to their own threads. Not an incredibly noticeable problem as thread expansion is handled with scripts but, for someone using something like noscript, those links would return errors. Likewise, I fixed an issue with the board list on the top of pages not always regenerating successfully by making sure that each page generation process all went through the exact same bits of code. Obvious, right? Well, stuff like that is holdover from older design intentions when there might be cases where it wasn’t desirable to output the same links (e.g. on certain special boards or when something like frames were enabled.)

I’ll gloss over that I gave a similar touch-up to some of the RSS generation templates to make them more uniform and more spec-compliant and instead focus on the links for story threads at the bottom of threads. While it’s a feature that I added like a year or two ago, it was still somewhat imperfect. The amount of pages output and what was omitted was inconsistent. So, say, on thread 13 of 17 the amount of threads listed to the left or right of the current page was not the same as thread 10 or the first or so forth. They were roughly the same and roughly in the same position but I thought it was less-than-stellar, particularly on the mobile view of the page.

I decided to rewrite bits of how that was generated on the server end, making sure that there’s always just 7 results and, depending on the thread number, making sure that there’s a consistent amount of other threads displayed, including the first and last. It’s not a terribly difficult problem but it still requires thinking about things mathematically and adapting the formula to special cases along the loop that generates the links. As I’m no mathemagician I took to plotting various cases and permutations on paper to make sure that my numbers were correct and then ran several tests on the code to make sure that translating that worked well. When you’re handling both index values in an array as well as numerical values, and using both in the code, there is plenty of opportunity for mistakes.

I might revisit some of this in the future as I’m not sure it looks “great” on mobile yet and might do it more along the lines of the updated story list. But seeing how I’ll most likely get around to changing how board pages look…. Things might take on a different form in the end.

While I’m never sure if regular users notice—or, indeed, care—about these sorts of things, I’m somewhat surprised to have found that the mobile parts of THP had not really been working right for a fair chunk of time and no one had said anything. To be fair, the actual issue that was due to deprecated features and old inherited code would not have really been that evident, as the “visible” effect of it would have been to make the sticky menu not fade in and out, leaving it static and in place. But this exception did cause other things to break, such as watching threads and more advanced settings. That does fortify the impression I have that most users don’t bother with any of the site customization and that’s something that I’ve kept in mind when designing new features and with future endeavors.

Something that’s taken me embarrassingly long to change is manual triggering of multi-board regeneration on the management side of things. I’ll unpack that first before carrying on: whenever a post is made/deleted/a thread or board page needs updating, the HTML file is generated through templates using database entries and PHP code. There are times when it is desirable to update pages even when there’s no new content, like when I change the template files and add a new feature (such as the various schema) or change headers, links, or other things of the sort.

There’s two options for that on the management side of things: 1) Updating on a board-by-board basis on each boards’ settings page and then “save and regenerate” 2) going to the “regenerate all” page.

Obviously the second is preferable in most cases as doing it for 14 or so boards is tedious and time-consuming as one must wait a few seconds before the regeneration is complete before repeating the process with another board. The issue with the latter, however, is that it is prone to failure. As features have been expanded and the thread generation process is sequential and linear, the cumulative amount of time taken for all those boards and all their threads (and posts!) can be very long. Just something like minifying the HTML output to make the files smaller and quicker to load add to a lot of processing time. And, because PHP is a scripting language, the execution time of a resource-intensive script can mean that other requests aren’t served and the various workarounds for parallel workloads are not ideal and, honestly, a little out of scope for a project like current THP.

In other words, the common result of trying to regenerate all at once is usually that the script reaches its execution time limit (which is already raised from default) and fails. This has been an issue for several years now and, while annoying, it wasn’t something I was doing all the time. So I dealt with it usually by drinking of tea and thinking of which touhou has the fluffiest tail while doing it on a board-by-board basis.

Years-long inertia was finally overcome and I reworked the “regenerate all” section into a “regenerate selectively” page. I can now select an arbitrary group of boards and do them in batches or all at once, whichever is likeliest to work. It’s a flexible solution that consigns thoughts of tails to the dustbin of history. All it took was some tedious under-the-hood work and persistence.

In a similar vein, the last piece of significant work that I did was also mostly for my sake (and that of other moderators—may they Rest in Hiatus.) The ban pages themselves were a mess and combined a form to add bans with information on current bans. Which doesn’t sound too bad until you realize that there’s different kinds of bans and that navigating hundreds if not thousands of bans was a terrible user experience. Still, it worked, and manual bans were rare enough, so this relic of design from the Kusaba (non-X) days was tolerated.

To be clear, other systems that interacted with this page had been changed, as well as some mechanics underlying bans themselves. But still the page remained visually unchanged.

On THP proper this page was busier, with a table of range bans and generally involved a lot of scrolling, especially if it was set to show more than the default 15 bans each.

The new 'View Bans' page with its relative simplicity.

What you might appreciate from the screenshots is that the viewing of bans is now its own separate page. Additionally, there are different pages and sections for each type of ban; this not only organizes things better visually but is also an optimization as only type-pertinent data is fetched and processed on load as opposed as to everything following the previous table on the same page. A lot of the generation code was refactored while I was at it, making it so there’s less repeated code and it’s more clearly and efficiently laid out. Fewer for loops that iterate over everything, single-letter variable names, and needless use of arrays for database queries for starters. Smarter use of conditionals and flexible options such as arbitrary requests for last x amount of bans (as opposed to only all, 100, or the default 15) as well as an option to search for IPs with bans directly instead of being reliant on finding it on a list and clicking on it to see other previous bans.

While I was at it, I also integrated the separate-but-related banned file list into this new interface. It was previously an afterthought, listing banned image hashes at he bottom of the page and without an ability to look at a larger list of them. Now, not only is it its own section that has similar features to other types of bans but I also did some database-related things to simplify their table and optimize how they’re used elsewhere in the code base (ie checking a would-be poster’s image if it is posting a banned image.) It results in a speedup that, even if it’s very slight, helps the site in cases multiple posts are being made at around the same site. There’s more room for improvement there but I think it’s best to leave it until other newer pieces of other things are in place.

Finally, the (old) ban page itself also handles image banning better and has a simple checkbox to confirm whether the image is being banned in addition to the user. Previously, it would only be processed when a time was inserted for how long the image was to be banned for. Somewhat unintuitive and, generally, if an image is banned, I think it can be assumed that moderators want it banned for ever. If not, the image can have its ban manually removed just as easily as any other kind of ban now.

I think that’s a good ending point for today. I won’t bore you with the other minor stuff. Seeing as my time pressures have eased up a little lately (knock on wood!) I might be able to finally finish the tagging improvements I’ve had in mind. Or, failing that, there’s another feature that I’ve wanted to implement for moderation/in the fight against spam that I think I could get wrapped up soon.

Either way, I hope to be able to report back with good news soon. Until then, take it easy!