No, I don't have especially good news to share about the Wongery. (I mean, I don't have any especially bad news to share that I haven't already shared, but I don't have any especially good news either.) No, what the title refers to is that I have finally, finally implemented the interface to allow me to post blog posts through a form on the website instead of having to mess with the MySQL database manually via phpMyAdmin. Thus, the blog, which I used to call the "news", is good, or at least my method of updating the blog/news is good, or at least it's better than it was. I don't know. I thought it was a clever title. I was almost certainly wrong, especially given the fact that I've just felt the need to spend a paragraph explaining it. And the more I try to explain it, the more strained and stupid it sounds. I think I may be bad at coming up with titles for blog posts. I think I may be bad at everything in general.

Anyway, so yeah, I finally got around to one of the many things I've been repeatedly saying I was going to get around to doing for the Wongery. Part of the reason it's taken me so long to get these things done is because, well, I don't really know Javscript and PHP well, and was trying to take some courses on Udemy to change that, so I was going to tackle these tasks after I'd finished those courses and hopefully had a little more programming skill. Well, I still haven't finished those courses (I'm getting close to done with the Javascript course, though, and then I'll get started on the PHP course), but as I've mentioned before I do know a little PHP, and I thought maybe that would be enough for this particular project. After all, it's basically just a form submission. I've done those before, and they're not that complicated.

Ah, but there was a little more to it than that. Sure, the form submission part itself might only take me a couple of hours to do (it would be a much faster task for an experienced programmer who knew what they were doing, but, well, I'm not). But I didn't want just anyone to be able to put up a blog post on the site. I wanted to restrict that ability to the Grandmaster Wongers. (Thus far, I (Clay Salvage) am the only one who's made any blog posts, but I do want it to be possible for the other Grandmasters to make their own blog posts if they want to. Assuming, of course, that there are other Grandmasters and that it's not just me using six different pseudonyms for no reason.) That means I have to check to make sure that someone with admin permissions is logged into. And that means I have to delve into the phpBB APIs.

As it turned out, though, that turned out to be easier than I expected in some ways, and more difficult in others. With a little searching online, I didn't have too much trouble trying to figure out what code to add to be able to check whether there was a logged-in user with administrative permissions. The tricky part was that there are apparently some quirks with the phpBB code that had odd interactions with the rest of the code, and while this wasn't too hard to work around once I realized what the issue was, it took me a while to figure out what was going on.

(Okay, I guess the next bit is going to delve into some programming minutiæ, so those with no knowledge of or interest in programming are welcome to skip them. Actually people who do have knowledge or interest in programming are welcome to skip them too, if they want to. Heck, anyone is welcome to skip this entire post, or any blog posts. I'm not forcing you to read them.)

For one thing, apparently for some reason the phpBB code turns off all the PHP superglobal variables. This meant, among other things, that I couldn't check what data were being passed in the form or which blog post the user was trying to access, because that information was stored in the $_POST and $_GET superglobal variables. As I said, the hard part was figuring out what was causing the problem in the first place; once I realized what was happening, it wasn't too hard to find a way around it. All I had to do was add the lines "$request->enable_super_globals();" and "$request->disable_super_globals();" before and after any part of the code that had to access superglobal variables. (Possibly I could have gotten away with just enabling superglobals right after the initial check for a logged-in user with administrative permissions, and then just left them enabled for the rest of the code, but I figured I'd turn them back off when they weren't needed just in case.)

Even when I got that sorted out, there was something going on with the interaction between phpBB and MediaWiki. I wanted to be able to preview the posts, which meant I had to call some MediaWiki code to format the wikitext, and while eventually I plan to deal with this more elegantly through an API call (which is what I should have done in the first place) rather than through calling functions in the MediaWiki code directly, I haven't implemented that yet. (Though really, I probably should have done that first, not only because it might have avoided this particular issue, but also because it would have had other, more direct benefits for the site's usability—for instance, I assume that would make redlinks in blog posts actually red, which they currently aren't. Well, that'll be my next priority.) But the calls to the MediaWiki code resulted in an error that I didn't know what to make of: "WikimediaServicesServiceContainer::get(string $name) must be compatible with PsrContainerContainerInterface::get($id)". Well, to make a long story perhaps not short but at least slightly less long than it might otherwise be (the potential prolixity of my rambling knows no limits), it turned out that this error could be eliminated by deleting two words from a certain MediaWiki sourcefile, vendorwikimediaservicessrcServiceContainer.php. Hopefully this won't cause any untoward consequences later.

So anyway, having eventually ironed these issues out, I did a little testing with the copy of the site on my desktop, found and fixed a few more errors that were due not to any quirks of phpBB or MediaWiki but to my own incompetence as a programmer, and then decided the site was ready to deploy. The MediaWiki code was still throwing some errors, something about "uncommitted DB writes", but I thought I remembered this always happening with the copy of the site on my desktop and assumed (or at least hoped) it was due to something about the way the site was hosted locally and wouldn't be an issue with the online version of the site, and so I went ahead and uploaded the changed files and hoped for the best. And so far so good; the "uncommitted DB writes" errors aren't occurring, and nothing immediately obvious is broken.

So, now at last I don't have to make blog posts by manually inserting records in the table through phpMySql as I have been doing for the last, uh, almost eleven years. Yeah, I really should have done this much sooner. This should make this process go much smoother; it's not that much hassle to do the whole phpMySql thing, but it's enough of a bother that I didn't want to go through it just to correct errors I found in the posts. Now that it's so much easier, I can do that; at some point I'm going to go through and edit the old posts. I'm not going to make any major changes, of course, just fix typos, add links, and make other similar refinements. Oh, and also the ability to preview blog posts before actually posting them is going to be a very welcome change; before if there was some error in my markup that I missed I wouldn't know it until I made the post, and then I'd have to correct it (which would involve saving the text file, uploading it to the record through phpMyAdmin, etc.)

I've also made another change to the blog posts, or at least laid the foundations for another potential change. The record for each blog post includes a "key" that's used to refer to the post in question, and that makes up the last part of the post's URL; up till now I've just been using as the key the date the post went up. This post, for instance, resides at wongery.com/blog/20231127. But... that's not a very interesting or useful key; it might have been a better idea to use keys that at least hint at what the posts are about; the titles, or at least words from the titles, would have been better keys than dates. Well, I didn't want to remove the old keys, to avoid breaking old links, but I added an additional field to the blog table for a secondary key, which I called the name just because "key" was already taken, and which can be used interchangeably instead of the date key. This post's name, for instance, is "GoodNews", and it can be also reached at wongery.com/blog/GoodNews. Or at least, it will be able to be reached there eventually; right now the names are in the table, but don't actually do anything. That will involve some minor change to another php file, which should be relatively quick and easy to do but which at the time I'm writing this post I haven't gotten to yet. (It'll probably be done by the time anyone reads this, though.)

Alas, however, while steps 1 through 9 in my overly complicated blogging process are now much streamlined, steps 10 through 16 remain the same. In order to put a copy of the blog post on the forum, I still have to copy the HTML of the blog page, convert it to UBBcode, and so on. I do have plans to make this easier as well. I was thinking at one point of having blog posts automatically posted to the forum as soon as they were made, but then I had (what I perhaps erroneously think is) a better idea. What I want to do is implement a custom BBCode tag that causes anything within the tag to be parsed as wikitext. Then I just have to transclude the blog post in that wikitext, and not only can I make a forum post for a blog post without having to do any formatting conversion, but it will automatically change if I change the blog post. (Which of course currently is not the case; if I change a blog post, the corresponding forum post is unaltered.)

I had thought that in order to do this I'd also have to add a custom tag to my MediaWiki installation, as well, in order to allow me to link to blog posts without their being treated as external links. But then I realized that I didn't have to do that at all, because there was already a way to do that built into the MediaWiki software—or at least built into an extension that now comes with the MediaWiki installation and that the Central Wongery was already using. Namely, the Interwiki extension, which allows users to define special prefixes that can be used to link to external sites with a similar syntax as to internal namespaces; all I'd have to do is define a prefix for the blog. This should have been obvious to me long before, but there is a very good explanation for why it took me so long to realize it: I am dumb. Anyway, that's done now.

Oh, hey, you know what it might be nice to have for the blog posts? A way to search them! I have no idea how to implement that! I could probably figure it out, given enough time, but that may be a lot of time, and it's not necessarily a priority. Still, something that might be worthwhile to add at some point. Oh, also it might be nice to include redlinks in blog posts in the "Wanted Pages" special page, but again, that's something I can deal with in the (perhaps distant) future.

So, anyway, there is finally a simple interface to allow me and the other Grandmaster Wongers to make blog posts! It is very stark and ugly, but that's okay; nobody but the Grandmaster Wongers is ever going to see it.

Now, admittedly, I haven't actually tested it on the actual production site yet. (Oh, hey, "production", in this context, is a word I picked up from the Udemy coding courses I'm taking! See, I'm learning!) I did some testing on the local version of the site on my computer, and it seemed to work, but I admit I am kind of nervous that I did something horribly wrong and that when I try to use the interface to make a blog post on the production site it will completely break everything. I backed up the site, just in case something does go horribly wrong, but I... still hope that doesn't happen. Anyway, if you're seeing this post, it means that either the blog interface did work as it was supposed to, or it didn't at first but after some fiddling I eventually managed to get it working. I'll edit the post after it's online to tell which of those was the case. Here goes nothing...

EDIT: Um, whoops. Creating the post went fine, but when I tried editing the post, it created a new copy instead. Uh... I had tested editing old posts, but I guess I hadn't tested editing a post right after creating it? (Incidentally, I didn't include in the interface a way to delete posts, so I had to delete the duplicate posts through phpMyAdmin, but, well, I don't see that deleting posts is something I'm going to have cause to do frequently enough to bother implementing an easier way to do that.) Well, it's not a big deal; I'm sure I can fix this eventually, but in the meantime it's not really much of an inconvenience to remember that I can't edit a newly created post without returning to the master list and selecting it from there first. So, anyway, aside from that minor glitch, which I can easily work around, the new blog post interface works!