August 22, 2024: Two Steps Forward, One Step Back
So I mentioned in the previous blog post that I had upgraded the Central Wongery to the newest version of MediaWiki. Unfortunately, that apparently broke something with the login, which was a problem since I had to log in to access the blog admin page, and not being at home at my desktop computer where I could easily look into the issue, I had to post that blog entry the old-fashioned way, with phpMyAdmin. (Fortunately, of course the forum tag still worked, so I didn't have to go through the rigmarole of pasting the HTML of the blog post into an online HTML-to-BBcode converter and manually cleaning up the output to paste it into a forum post, like I used to.) When I did finally get a chance to try to resolve the problem, it turned out to have something to do with the login cookie not being able to be set securely due to the site security, or lack thereof, and after a lot of wrangling and bootless stabs at solutions, I eventually got the login working by setting the configuration variable $wgCookieSecure to "false", which... probably (almost certainly) is not the ideal solution, but as I have stressed so many times before, I have no idea what I am doing. I guess at some point I should look into getting an SSL certificate for the site? Would that solve the problem in a way that had fewer potential repercussions down the line? Maybe. How do I get an SSL certificate for the site? I... don't know. But probably I can figure it out. Maybe. One more thing to look into.
Anyway, so that solved the login problem, but I soon found that I'd somehow introduced a different problem. The next time I looked at the Wongery home page, I saw that the article in the Random Article sidebar was "Universe", which... wasn't supposed to happen. The "Universe" article on the Wongery is a disambiguation page, and I'd written an extension expressly to prevent disambiguation pages from being chosen as random articles. (Furthermore, the excerpt below the article title consisted of naught but an ellipsis, which also wasn't supposed to happen, but was probably related.) I refreshed the page a few times, and sure enough more pages showed up that weren't supposed to, disambiguation pages and stubs that should have been excluded by the Random Rules extension. Aargh. Had the update to the new MediaWiki version somehow broken the extension?
Now, I had been planning on revisiting the extensions sometime anyway, because there were more refinements and functionalities I wanted to add to them. Most urgently, at least until this happened, I wanted to track down the annoying bug that makes all interwiki links show as redlinks whether the page in question exists or not. But I was going to wait until I had migrated the site to its new hosting plan (something I still plan on doing, and really ought to get around to sometime soon). After all, I don't want to do my debugging on the live site, so working on the extensions would involve setting up a local copy on my computer; I had done that in the past, but that local copy was now badly out of date, so I'd need to redownload all the files and databases and set it all up again, and since I'd have to redownload all the files and databases anyway when I changed hosting plans, I may as well wait and do everything at once. But okay, this issue with the Random Article sidebar was bothering me enough that I decided I ought to try to do that now anyway.
It's been over a week since the site upgrade, but it didn't take me a week to figure out what was going wrong with the Random Rules extension. Rather, it took me almost a week to finally force myself to start working on the problem. Now, okay, granted, part of the reason for this was because this last week happened to be a very busy one workwise, and I wasn't home much—and while I do often have downtime at work and can work on Wongery articles and blog posts on my laptop, to work on the extensions I'd have to be at home, since it's on my desktop that I set up the offline version of the site that I can use for debugging. (Wait a second... actually, I could set up an offline version of the site on my laptop too. Maybe I should... do that. Although then I'd have to worry about keeping the two in sync...) But, me being me, admittedly a good part of the reason was just good old-fashioned procrastination (or maybe bad old-fashioned procrastination, really). And a good part of the reason for that was that... honestly, trying to work on the extensions again struck me as a daunting prospect. Sure, I'd somehow managed to write those extensions in the first place (and I'm still not at all sure how in the world I managed to do that), but I hadn't really touched them since last December; it had been long enough that I feared I'd forgotten everything I taught myself about writing MediaWiki extensions and would have to figure everything out again from scratch.
As it turned out, once I did finally cajole myself into putting in the work (and once I figured out how to stop the local version of the site from throwing a warning about the "Use of InterwikiLoadPrefix hook... [having been] deprecated" that interfered with the site's functionality), it wasn't that bad; it wasn't all fresh in my memory, but looking at the code again I remembered the basics. As a matter of fact, the problem with the Random Rules page was evident almost as soon as I looked at the relevant sourcefile: right there in the file was the following comment:
/* Unfortunately, for this second part to work, * line 97 in ApiQueryRandom.php must be changed from * $res = $this->select(__METHOD__); * to * $res = $this->select(__METHOD__, null, $path); * * This is a kludge, but one I have not yet found a way around. * Sorry. */
Oh... oh yeah. I'd completely forgotten about that. So of course, when I updated the MediaWiki installation, the version of ApiQueryRandom.php in the new installation didn't have that change. Now, at some point I ought to look into seeing if there's a way of achieving what I want without that kludge, but in the meantime... would changing that line of code in the new version fix the issue? Well, it wasn't line 97 anymore (and for reasons not worth going into here I decided that $path
might not really be a great choice of variable to use as a parameter), but... yeah, it did. (And I updated the comment to remove the fragile reference to the specific line number and to reflect the change of variable.)
So while I had the local version of the site running, I figured there were a few other things I wanted to tackle. For one, it had been bothering me for some time that the webpage title of blog posts just showed up as "Wongery - Blog" and didn't include the title of the blog post. (This was especially irksome when I linked to blog posts on social media.) Correcting this turned out to involve little more than swapping two lines in one file. And then I went ahead and looked into the interwiki redlink problem, as well. And as is so often the case in programming (at least in my admittedly very limited experience), the actual fix turned out to be very simple, only requiring the addition of 24 characters to the main sourcecode file of the Subspace extension. The hard part, of course, was figuring out what those characters were. (For the record: "$title->isExternal() ||
". (I said 24 characters were required, but okay technically I could have gotten away with only adding 22 characters by leaving out the spaces, but anyway.)) Now, MediaWiki caches the parsed HTML code for pages, so fixing the extension wouldn't immediately fix the links in all the affected pages, but I wondered if perhaps there was a maintenance script that could make all the pages update immediately, and as it turned out there was, Manual:PurgeParserCache.php.
Oh... I almost forgot. I'd remarked that on the Version special page, which shows, among other things, all installed extensions, the names and descriptions of my custom extensions weren't showing up correctly... for Random Rules extension, for instance, they showed up as "⧼randomrules-extensionname⧽" and "⧼randomrules-desc⧽", respectively. It took me a while to figure out how to get these items displaying correctly (I mean, it didn't take me that long, but it took me longer than it should have because, again, I am incompetent), but I eventually did, so... yay for that, I guess.
There was one more change I decided to make: I had a subspace in the RPG space for Dungeons & Dragons fifth edition, but, well, with 2024 Dungeons & Dragons on the horizon, and with Wizards of the Coast having promised to release the new SRD under a Creative Commons license, well, it didn't seem to make much sense to me to try to put in content for an edition that was going to be superseded in a matter of months. So I removed the 5e subspace, and edited the Game:RPG main page accordingly. Then I realized that it would probably make more sense to have a subspace for D&D, but not put any content there until the license for the new edition was released. So I restored the subspace, renamed from "5e" to "D&D", and reëdited the Game:RPG main page to explain the situation.
Unfortunately, when I looked at the Game:RPG main page on my offline local version of the site, I noticed that the subspace tabs weren't showing up above the article like they were supposed to. Oops; had I somehow broken something in the Subspace Tabs extension by deleting and restoring and/or renaming one of the subspaces? As I soon realized, no; I had just found a bug that had been present all along on the production version of the site, too, but that I hadn't noticed before. Going to the page via the tabs worked fine, except that the page URL showed up as "Game_RPG:Main page" with an underscore character instead of a colon between "Game" and "RPG", which wasn't ideal, but if I went via a link to "Game:RPG:Main page"—or typed "Game:RPG:Main page" into the address bar manually, then I got the page with a prettier URL, but without the tabs on top. (Also, in either case, the title of the page itself showed up with a space between "Game" and "RPG" rather than a colon or an underscore, which also isn't ideal.) And of course this wasn't unique to the Game:RPG main page; it worked the same for other subspaces as well; that just happened to be the page where I'd first noticed the issue. So... one more fix to be made with the extensions. Eventually. But not now. I figured I'd gotten enough done on the extensions and the site backend for right now, and I'd get back to focusing on writing articles.
Well, okay, there is one more thing I did with the extensions before I made this blog post, and that's push them to GitHub so the latest versions would be available for other people to use them. Not that I'm sure other people would want to use them, given the clunky coding and poor documentation, but, well, hopefully they'll be improved over time, and I do want to ensure they're freely available. (As I've said before, you can see and download all the extensions at https://github.com/ClaySalvage/, if for some reason that is a thing you want to do.) I realized on doing this (or was reminded on doing this, since I'm sure I must have known this before) that I hadn't set all the extensions up on GitHub the same way; for the Random Rules extension, I'd pushed to GitHub the contents of the Random Rules directory, but for the other extensions, I'd pushed the directory itself. It's a minor difference, but the inconsistency bothers me, but I'm not sure exactly how I can change this after the fact—and moreover, even if I could, I'm not sure which is the better way of doing things, and whether I should change the way the Random Rules extension is set up on GitHub to include the entire directory or change the other three to include only the contents. One more thing to worry about later. (A course on GitHub is one of the many courses I've purchased on Udemy but haven't gotten around to taking yet.)
Oh, also at some point I ought to update the Public Wongery too, with the latest MediaWiki version and the latest versions of the extensions, but... eh, something else to worry about later. Again, I feel like I've put in enough work on the site's backend for right now, and want to get back to putting up more content.
So, there we have it, yet another blog post about the nitty-gritty about the programming behind the site in which nontechnical users are likely to be completely uninterested. You know, I probably ought to add some sort of categorization and/or tag system for the blog posts so people can find those posts that are more likely to interest them. Also a search function for the blog posts. Okay, yet another thing to worry about later...
(Okay, and now that I've just tried to post this blog entry... it turns out that while the login issue is fixed, the blog admin page is broken; it just shows a blank page. Oh, criminy. Fine; I have to leave for work (very late workday today), so I'll once again put up this blog post through phpMyAdmin, but when I get back home... one more thing to worry about...)