Going Wider

A forum for discussion of the front-page blog posts on the Wongery.
Post Reply
Clé
Posts: 111
Joined: Thu Dec 20, 2012 12:41 pm

Going Wider

Post by Clé »

D minus eight days and counting...

As I've referenced several times before, I don't generally sit down and write a blog post all at once. In fact, I generally have multiple blog posts in progress at any given time, and unless the post in question is about some current event it may take a week or longer between my starting a blog post and my actually finishing it and posting it. In the interim, it may happen that there's something I intend to include in a blog post, but by the time I finally finish it and post it I had forgotten to include it.

Such was, in fact, the case for a blog post I made three weeks ago, "Going Wide". The main point of the post, although as usual I didn't get to it until many paragraphs of digression, was that I had intended to, well, go wide with the features I wanted to include in the Wongery by the time of hard launch, trying to implement many of the new namespaces rather than focusing on one, and (though this would apply more after the hard launch than before) to not restrain myself from posting articles on multiple new worlds. I had intended, however, to also say that there was one aspect in which I was decidedly not planning on going wide: with the Meta:articles themselves. Yes, I could write a whole lot of short articles and cover many different subjects rather than make each article as long as it has been, but I really didn't want to do that; I would rather have a smaller number of articles that delve deep into the topic in question than a lot of short articles of just a few sentences.

Well, maybe it's just as well I didn't say that, because I'd kind of have to take it back.

I frequently refer in these blog posts to the fact that since the hard launch hasn't happened yet, nobody knows about the Wongery, and I'm writing these posts even though nobody's reading them. That's slightly hyperbolic, in that I was aware of at least the faint possibility that despite my failure to publicize it someone had found out about the Wongery and had been reading some of what I wrote, even if they hadn't made themselves known. Well, as it turns out, at least one person did, and they did make themselves known; a couple of weeks ago I received my first non-spam reply to one of my posts. (Which also does something to alleviate a worry I had that the anti-spam measures I'd put in place might discourage anyone from posting.) The poster, "Libre", said they had "been following the Wongery on and off for a couple years now", and that with the hard release imminent they figured they "should finally make an account and post something", and... well, there's no need for me to repeat everything in the post here; you can read it yourself if you want. But there is one thing they said that's directly relevant to this post. I'll just quote the most relevant sentences below:
Obviously as you've stated before filling in the red links is an important part of improving the Wongery, but I think you've been too stuck on the idea of only allowing fully completed perfected articles when right now what is really needed is more of just a glossary of terms. Having either a glossary page that current undefined red links can link to or creating single line Stub pages that define the terms and can be improved later would massively increase the usability of the site.
And yeah, they have a point. Like I've said before, I do use a lot of neologisms, and currently the vast majority of them aren't really defined anywhere—there are Meta:links to articles corresponding to them, but they're currently Meta:redlinks. And it's not that I didn't think that having all those terms undefined would be a problem. It's that I fully anticipated (well, maybe more vainly and unrealistically hoped) that before the hard launch I'd have enough time to write those articles and fill in the most important of those redlinks. But of course, with the hard launch just over a week ago, it's very clear that that's not going to happen. And while I don't really like the idea of having a bunch of stub articles cluttering the wiki, it is probably preferable to just having a bunch of weird words all over the place that aren't defined anywhere.

Besides, as it happens, one of the biggest reasons not to have stub articles is no longer a concern. I guess it's not really a big deal if someone can run across a stub article browsing the wiki, especially if they clicked on a link specifically to find out what some word meant, but I don't really want stub articles showing up in the "Random Article" sidebar on the main page, or being selected by the wiki's "Random page" feature. And now, hey, thanks to my new extension, that won't happen!

Oh, yeah, about that extension. When I wrote the last blog post yesterday, it still wasn't fully working. I'd gotten it partially working as far as confining the Random page feature to pages in specific categories, but it wasn't working with templates, it wasn't working to exclude categories (or templates), and it wasn't working for the sidebar. And while I put in those additional features in case other people wanted to use the extension, what I really wanted for my own purposes was, well, basically the exact converse of what it was currently doing: rather than only including pages in certain categories from the Random page feature, I really wanted it to exclude pages with certain templates from the sidebar. (Well, and the Random page feature, but that was less important.) Still, I figured now that I'd got one part working, it shouldn't be too hard to do the rest.

(Yes, in a slight break from my usual practice, rather than going off on a lengthy digression about a mostly unrelated topic before getting to the main point of the blog post, this time I'm waiting to go off on a lengthy digression about a most unrelated topic till over halfway through my writing about the main point of the post.)

Oh, but before I did any more work on the extension, I wanted to push what I had to Github. But like I said in the last post, I'd been unable to do so because I was logged into a different Github account without permission to push to my Clay Salvage account, and I couldn't find a way to log out or switch accounts. Well, it took me... way longer than it probably should have, but I eventually got that issue resolved. What it turned out I had to do (maybe there was another way to do it, but this is what ended up working for me) was go to the Windows Credential Manager and delete the entry for Github. (Not just change the credential information to my other account; I tried that and for whatever reason it didn't work. I had to delete the entry entirely.) Then the next time I tried to push the project to Github, it asked for my login information, and once I entered that it went through. (Well, eventually; first I had to deal with a different problem in that when I created the repository Github had for some reason created a License file there, and so when I tried to push to Github, I got an error that "Updates were rejected because the tip of your current branch is behind its remote counterpart." This I eventually got around, after a failed attempt to revert the spurious update, by forcing the push (

Code: Select all

git push -u origin main --force
)). So, yeah, the RandomRules extension is now up on Github, if anyone wants to take a look. It's very poorly documented, and it involves a kludgy workaround (more on that below), but it's there. I really ought to add better documentation, but... I'll do that after the hard launch. I've got too much else I need to get done before.

Anyway, what I thought would be the hardest part in getting the rest of the extension's features working was... well, not easy, but not as hard as I had anticipated. That being figuring out how to get the query to exclude pages in certain categories instead of exclusively including them. After a few unsuccessful attempts to do things a different way, I eventually had to resort to using a Subquery—winnowing a table by calling another query the results of which I would use in the main query—which I thought was kind of inelegant, but eh, it worked. After getting the category exclusion working, I'd hoped that I could just reuse that code almost as it was for templates, just changing a few names of variables, fields, and tables, but it turned out there was a bit more to it than that. While I only had to deal with two tables for the categories, the page table that held the main information about the actual pages and the categorylinks table that recorded what pages were in what categories, for the templates there were three tables I needed to access, the page table, the templatelinks table, and a table called linktarget that held the actual names of the linked-to templates, and the necessary query was a little more complicated. Still, I got it done. Feast your eyes on what may be the most convoluted line of PHP code I've ever written (though I may have written far worse lines in C# or C++):

Code: Select all

$tables['nested]=['templatelinks', 'exclude' => new Subquery("SELECT * FROM `linktarget` WHERE lt_title IN ('" . implode("', '", str_replace(" ", "_", $templates["list])) . "')")];
Now, having gotten everything working for the Random page wiki feature, I thought (or hoped) that getting it working for the API call and thus for the Random Article sidebar would, again, just be a matter of copying and pasting the code and making minor changes. However, when I tried this, nothing happened. The Random Article sidebar was unaffected. In fact, it turned out that my function wasn't being called at all. Why not? Well... the documentation for the hook I was using, "Manual:Hooks/ApiQueryBaseBeforeQuery", said that this hook was "[c]alled for (some) API query modules before a database query was made" (emphasis added). Apparently random queries are one of the modules for which it was not called. I did some experimentation to see what hooks were being called before the query was sent, and I found a couple—Manual:Hooks/ApiBeforeMain, Manual:Hooks/ApiQuery::moduleManager—but neither presented any apparent means of altering the query.

There was one relatively obvious means of getting this all working. There was a particular line of the MediaWiki code a minor change to which would, if I was understanding it correctly, make the random query call the ApiQueryBaseBeforeQuery... but obviously this was not really a preferred way to do things. Extensions were supposed to just use the hooks; they weren't supposed to involve actually hack the code itself. But after struggling for some time to find another way to do things, I eventually just decided my first priority was to get the extension working for the Wongery; making it something easily usable by others was a desirable goal, but secondary; and if getting it working for the Wongery involved changing a line of the MediaWiki code, so be it.

So I did, and then it worked fine. I installed the extension on the production version of the Wongery this morning.

So, bringing things back to what was supposed to be the main point of this post, the fact that I now have an extension that can prevent certain articles from being chosen by random queries means that the biggest strike against having stub articles is removed. As long as I remember to tag them with the appropriate template, I can have all the stub articles I want, and users will only see them if they specifically click on links to them; they'll never show up as random articles. So, with the extension installed, I went to create a template called Unlisted that I could put on articles that I didn't want to show up in random queries... only to find that I already had created that template, back in January 2022. Huh. (At the time, of course, it didn't actually do anything, but I guess I'd created it in anticipation of someday... uh, doing what I just did.) So then I went ahead and created another template, Stub, that transcluded the Unlisted template and that I could put on stub pages. (I wanted a separate template for this because there are some articles that I'd want to put the Unlisted template on that aren't stubs, like articles about real-world topics (human, Earth, etc.).)

And then I, and some of the other Grandmaster Wongers (if any), went ahead and started creating some stub articles, focusing on articles that were (red)linked in several places and were not common concepts that readers would already be familiar with. There are twenty such stub articles so far: æalogy, anek, convergent etymology, darsis, desis, djel, etory, faunum, Herit, hosper, pagerics, pantach, paracarminical magic, pocket plane, rhegus, thelxis, Wicik, ylifaction. There will be more later.

I've said before that when and if I have a Patreon/Ko-fi account for the Wongery (which won't be at hard launch, since I'll probably first have to have the Wongery set up as a private limited company with its own bank account, which I haven't had the time or money to do), one of the subscriber rewards will be the ability to vote on what redlinks we'll fill in next, and so help guide the progression of the Wongery and bring more development to worlds and concepts that subscribers are more interested in. Well, now that'll go not just for redlinks but for stub articles as well; subscribers will (when and if this is set up) be able to vote on either redlinks they want to see filled in or stubs they want expanded into full articles.

I still kind of have mixed feelings about having stub articles like that; I'd certainly rather have full, in-depth articles... and I hope someday I will have full, in-depth articles for each of those stubs. But in the meantime, in the absence of full articles for those links, Libre was right; it's better to have stubs than nothing at all.

D minus eight days and counting...
Post Reply