explain xkcd:Community portal/Technical

 Create a new topic!      Refresh

Technical Technical issues about the explain xkcd wiki, including bug reports, site stability, or requests for new gadgets or features. Create a new topic!

This page has archives. Discussions are usually archived after they have remained inactive for a long time or they are no longer relevant. Archive 1 Archive 2 Archive 3

Please replace Cloudflare bot fight mode with something else, like anubis.

I understand that “View History” is very resource instensive on old MediaWiki versions. However please instead of using CloudFlare Bot Fight Mode/Super Bot Fight mode, use Anubis because it is way easier. It took me 30 seconds of CloudFlare pages to log in, because it discriminates against weird browser configurations.

Using Anubis works fine for the Arch Linux wiki, and it uses FLOSS javascript and does not discriminate against weird browser configurations. (most bots use chromium anyways.) Anubis acts as a reverse proxy, that you are supposed to have another reverse proxy on top of. (I recommend caddy, but any TLS terminating reverse proxy works.)) -- Velocifyer (talk) 12:26, 13 July 2026 (please sign your comments with ~~~~)

I just wrote a long support for Anubis instead of the Cloudflare solution, explaining that I see no problems with it (unlike as stated on Reddit) in various other places I frequent, whereas this system seems to not be working on Android (with latest versions of Chrome or Firefox both tried), right now I'm on Windows (Firefox) and it seemed to work, however (going via the same internet connection).

However, on posting it immediately went through (re-)verification and then brought me back to the Edit. And backing up did not give me a chance to re-post (a trick sometimes I have needed to use when Anubis has decided it needs to do its daily/weekly renweal at some time inbetween going into an Edit and Submitting it (the only real occasional problem I've had with that system).

Now, I'm rewriting this, just to see if I can post anything at all, leaving out some of the old post and adding these new observations. (Will take a Paste Buffer copy in case it seems necessary/possible to try again.)

I will repeat my thanks for actually getting this fixed.

I'll also repeat that the "500 changes, 7 days" setting in Recent Changes says "No changes uring the given perio match these criteria." - but won't go into my fuller analysis of this, right now. (If I can actually post, at all, I can better go into it more fully under a new Section Header.)

Anyway, let's give it a try. If you're reading this, it (eventually) worked! 92.23.5.229 18:57, 13 July 2026 (UTC)

I don't have Bot Fight mode on, I have Managed Challenge on, though, for certain pages. I'll try to see what I can do. Celene (talk) 19:18, 13 July 2026 (UTC)

Yep, it does work (under Windows), at least that time. (I just had it re-request verification, right now, so I had to re-paste what I had precautionarily paste-buffered.)

Hpwever, for additional reference:

1. Android and Chrome browser (latest version) wants Verifying every time I try to get into an Edit page, and sometimes on other pages. It's a 'Verifying Loop', the tickbox wants ticking, so I tick it, it whirs, then it goes back to the tickbox needing ticking, repeat ad infinitum. (Occasionally it gives me a "Why is this veritication taking so long?" page.)
   • As a non-Edit-page example: from the Recent Changes page (that displayed, at least with only 50 changes - see below), I chose a "diff" link, and it went into the Verifying Loop. I backed out and the Recent Changes page now gave me the Verifying Loop. Had to revisit the Main page to even get back to Recent Changes.
2. Android and Firefox browser (latest version, again) goes into "Performing security verification" briefly then seems to return to the page that I wished to Edit. (On a couple of occasions, it's crashed the whole browser.)
3. Windows and Firefox browser initially seemed ok, but seems to want it (reverification) more frequently than I think is necessary.

Noting that I went to the Troubleshooting page for the Verification check, very early on (under Android) and did the 'direct' test-check and it was perfectly happy. Not sure why it is less happy with explainxkcd, though I think I've worked out that the settings may have been made to make it even more Verifying for any page with "edit" element in the URI (I can see why that would be a choice), so maybe the site-specific Verification requirements has been set far higher than default? I'm just guessing. Maybe can be toned back? Not sure if that'll help the Android situation, for me.

Anyway, just giving more information, while I have it. 92.23.5.229 19:39, 13 July 2026 (UTC)

I just had the issue that the Cloudflare thingy is "eating" edits when switching to preview mode. I made a lengthy edit on some comic's explanation and before submitting it I wanted to check if it was alright in preview mode. Clicking the "Show preview" button moved me to cloudflare and after returning my edit was entirely gone. Elektrizikekswerk (talk) 13:52, 16 July 2026 (UTC)

Yup, had the same issue a few days ago. FaviFake (talk) 17:07, 16 July 2026 (UTC)

Made some changes to cloudflare config, should hopefully be much less aggressive now. Additionally, it should stop eating edits (it's now only on for GET requests) and should be entirely disabled for logged in users. If there continue to be problems, please let me know. Celene (talk) 23:13, 17 July 2026 (UTC)

Recent Changes problems.

So... going to Recent Changes gives me the expected list (by default, "50 changes, 7 days" and not-bots as a separate default. Switching (without changing anything else) to 500 changes tells me that there are no results at all, and that's how it stays as I retreat back down through 250, etc, until back to the default 50. Suspect that it's due to technically not even having 500 changes to list (in the current incarnation, perhaps ignoring pre-migration examples), and looking for the last 500 changes gets a "not found" error that triggers the "not found anything" error.

Additionally suspect that it's an issue that will vanish once there are 500 changes to be found. With or without the limitation of 7 days, or any other of the available limits, encompassing/excluding the search-set. So it'll probably work properly by next week. But, again, FYI. Especially if it's something that will still need active fixing. 92.23.5.229 19:39, 13 July 2026 (UTC)

New Users situation?

I think the old-site protections against spam-account usage are a bit more permeable now. See User:Geoffreydixon15, and one more of today's new users has a similarly suspicious "Hey, here's a link!" pattern.

All new users, so far today, also have name-patterns that look like random bot/patsy-concoction, like was never completely stopped, previously, but at least included a wait-and-post-count threshold before they could start laying down user-pages (and thus often never did).

But it's not like I can be entirely sure, just going by long experience, without wanting to test any of the limits myself. I now seem to have more difficulty making genuine edits, so I just hope that spammers aren't having a reduced amount of oversight. 92.23.5.229 23:08, 13 July 2026 (UTC)

Heya, this was fixed yesterday. New users now can't create pages. FaviFake (talk) 17:07, 16 July 2026 (UTC)

Editing improvements (WikiEditor + VisualEditor)

Hi everybody, I've made some improvements to the editor. We now have WikiEditor (the bar on top of the editor) and VisualEditor (this is only enabled on content pages, but you can switch between source and visual editor as you please).

Some topics for discussion:

1. Should we add CodeMirror? This would enable optional syntax highlighting in the source editor, which some people may want
2. Should we add DiscussionTools? This might make discussion easier by adding reply/subscribe UI
3. What non-default configurations should we add to the editor improvements to make it more suitable for explain xkcd?

Celene (talk) 20:42, 18 July 2026 (UTC)

I'd like to throw my hat into the ring and vouch for CM. To reiterate what I said on the Discord: it's negligible extra burden on the server (serving an extra static file that weighs in at just over 230 KiB compressed) and fully optional for the client. Not to mention, with wikitext being such a non-obvious syntax, highlighting helps a lot.

I won't argue for VE until the server load situation is fully under control. I haven't used DT extensively (requires MariaDB/compatible afaik, I usually deploy w/ SQLite) but it will probably reduce the number of Please sign your comments with ~~~~

Eunakria (talk) 01:37, 19 July 2026 (UTC)

Never mind, apparently this is a lie. StructuredDiscussions (fmr. Flow) was incompatible with SQLite, and is now deprecated with DiscussionTools as a replacement, which supports all databases (SQLite schema here) Maybe I should give it a shot. Less said about explain xkcd, of course. Eunakria (talk) 02:32, 19 July 2026 (UTC)

CodeMirror seems like an easy win here, it makes editing wikitext a lot less painful to read. DiscussionTools also absolutely sounds worth it given how much of this wiki runs on talk page discussions. To quote Sodium on the explain xkcd:Discord, "I'd appreciate DiscussionTools. I've gone 'hmm I maybe should write a comment' but then gone 'ah it's too much work' and moved on". I bet most commenters feell the same way; I certainly do!

On top of all this, I think it'd be worth switching the default skin over to Vector 2022 as well. I've been using it here for a while now and haven't run into any template bugs, everything renders exactly as it should. And it's so nice! The reading experience is much better with the sticky table of contents, the shorter line lengths that are much easier to read, the sticky header, and the larger search bar.

And if anyone tries it and decides they prefer V10, remember there's a huge bolded "Switch to old look" button right in the sidebar so you can switch back in 1 click. Worth remembering that most of our readers are logged out or never touch the preferences, so it's best if we make the experience as welcoming as possible to them, also to attract new editors! The needs or preferences of power users shouldn't determine what the average readers sees.

Given we're already shaking things up with the editor, this feels like a good time to make the switch and get everyone used to both changes together. FaviFake (talk) 15:47, 19 July 2026 (UTC)

There's a "switch to old look" link, somewhere? Can't see it, but I'd rather like to regain some of the old-style features/functionality from the original site's Recent Changes page, and maybe, I'm thinking, any retroskinning would help do that. 92.23.5.92 17:56, 19 July 2026 (UTC)

I was actually curious about this since I distinctly remember it being a thing. It was removed in 2025 but it's still a thing in REL1_43 and as such in the copy of V22 this wiki deploys. It's no longer present on WMF wikis, since I guess they're officially comfortable with V22 being the new default for everyone.

With that, it's entirely a matter of taste. Both are available for logged-in users and you can choose whichever skin you like. It goes without saying the wiki in its current state is not suited for V22 dark theme, but not many templates need to be modified. Mostly it's just swapping out old colors for CSS variables. This userstyle goes a long way toward making V22 dark theme usable (although the proper solution would be to modify the actual templates that use inline styles):

.skin-theme-clientpref-night .comic-content,
.skin-theme-clientpref-night .disctemp,
.skin-theme-clientpref-night .notice,
.skin-theme-clientpref-night :has(#Latest_comic) + div {
    background-color: var(--background-color-neutral-subtle,#f8f9fa) !important;
    border-color: var(--border-color-base,#a2a9b1);
}

.skin-theme-clientpref-night .notice2 {
    background-color: var(--background-color-destructive-subtle, #ffe9e5) !important;
    border-color: var(--border-color-base,#a2a9b1);
}

.comic-content > tbody > tr:nth-child(1) > td,
.comic-content > tbody > tr:nth-child(3) > td > span {
    color: var(--color-emphasized,#101418);
}

Eunakria (talk) 05:04, 20 July 2026 (UTC)

Nah, I definitely don't think it's "entirely a matter of taste". V22 is objectively more accessible as it adheres to modern web design standards such as the sticky header, sticky TOC, and especially the much shorter line length which is proven to make reading easier. And I'm willing to bet most explain xkcd readers don't have an account, so they won't be able to choose their preferred skin. Clicking "Switch to old look" is an extremely minor burden to place on power users in favour of giving our readers a vastly more accessible and usable web interface, imo. FaviFake (talk) 13:54, 20 July 2026 (UTC)

Alright, I've added CodeMirror, Echo, and DiscussionTools.

Also, while investigating why DiscussionTools didn't work on the Community Portal, I discovered that in Template:Community links there was previously illegal HTML in the template, I've now fixed this and DiscussionTools works now. However, it doesn't work on the transcluded discussion sections in the main content pages, probably I will just have the discussion section point toward the actual talk page but I have been feeling very under the weather today and have a huge headache, so I'm not doing that right now.

I honestly kind of prefer V10 to V22, although it might be possible to configure V22 to preserve the things I like about V10 or to create a custom skin? Will look into this further. Celene (talk) 02:05, 23 July 2026 (UTC)

Actually—thought about this some more and realized it was mostly the absence of a logo that bothered me and in all other regards I prefer V22. Unfortunately, our current site logo and all logo proposals are all designed around V10, and we'd need to update it to V22. V10 logos are a single square image, but in V22 you need an icon section (square), a wordmark section, and an optional tagline, (both wordmark tagline are much wider than tall) meaning that we'd need to separate the imagery and branding. Unfortunately, none of the proposals at Category:Explain xkcd logo proposals work well for this, but it might be a good idea to announce some sort of logo redesign contest in the coming future. Celene (talk) 08:07, 23 July 2026 (UTC)

Strange loss of multi-diff information from Recent Changes

With viewing the Recent Changes page via the URI https://www.explainxkcd.com/wiki/index.php/Special:RecentChanges?limit=500&days=7&enhanced=1&urlversion=2 (thus showing back to 13 July), the latest change for the page Category:Cursed Connectors currently shows up as "18:56 Category:Cursed Connectors (diff | hist) +20 66.9.166.220 (talk)" (manually added links to 'diff' and 'hist' links, and minor formatting, these things being most relevant to this issue).

As can be seen in the History (as it is now, and even after changes you can scroll back), and also in the (single-edit) diff-page, the prior edit (in the same minute, by the same user, who was making a minor correction to their addition of the latest comic information in the Cursed Connector context table) did not appear in the Recent Changes list, which typically merges multiple (same-day) qualifying changes. e.g. in the line "13:55 explain xkcd:Community portal/Technical 3 changes history +2,033 [Eunakria; FaviFake (2×)]"

That's with the default Page-Style applied. Simply copied (with no attemmpt to add most of the formatting/etc) from the no-style version of the page, we have a line:

18:56 Category:Cursed Connectors diffhist +20 66.9.166.220 talk

...which represents only the second edit by 66.9.etc. Whereas the 'full' version of the 'compressed' Portal/Technical edits will display as:

13:55 explain xkcd:Community portal/Technical 3 changes history +2,033 [Eunakria; FaviFake (2×)]

13:55 (cur | prev) −395 FaviFake talk contribs (fixed! thanks so much Eunakria)

13:55 (cur | prev) +656 FaviFake talk contribs

05:04 (cur | prev) +1,772 Eunakria talk contribs (→Editing improvements (WikiEditor + VisualEditor): Add reply)

...i.e. the basis for the 'summary line' and then the component lines that get rendered hidden, unless and until further investigated/expanded upon by one of several different means.

Not that it wasn't easy enough for me to work out that I was viewing the Cursed Connector page having been re-edited from a prior edit, but... I should, by all rights have been getting a "2 changes" diff-page. In a similar manner to the "3 changes" currently correct (at least until I post this, when it will become a "4 changes" one, at least...) for this page's Recent Changes.

I have no filters set. And also it is not a Bot edit anyway, one of the obvious reasons to exclude an edit. And, as can be seen by Favi's double-edit here at 13:55, it should not be deciding to compress same-user-same-minute edits, even if it would have been a proper thing to merely ignore the first instance (rather than make it equivalent to a "2 changes" automatic double-diffed link) and present it as being an edit chain starting from an edit point that the Recent Changes should have also encompassed (i.e., given enough room in both limit= and days=, then everything back to the midnight of the day concerned).

Not quite sure what the basis is of this strange behaviour, or if it has caused me any problems in the past (by being given a truncated history of the "latest n changes" to a page that I'd have expected). I don't even know that it is not just a perfectly normal variation of behaviour that I have just been entirely oblivious to in all other cases. But it seems to be 'wrong' and not working as (previously?) advertised. But I document my findings here in case anyone else has either a similar concern or an easy answer regarding this issue. I'm also not excluding the possibility that nobody cares/considers it worth commenting about. Or that (for some reason that may or may not also be considered 'strange') it just isn't happening to anyone else anyway. But FYI. 92.23.5.92 20:43, 20 July 2026 (UTC)

Could you post a simpler TLDR without subclauses? I can't understand your question, if you have any. FaviFake (talk) 20:39, 21 July 2026 (UTC)

Apologies for not replying, to try to clarify it for you. I did not even see this update in the Recent Changes list. Which might have been my fault for just not seeing it, or else might have been another incarnation of the very issue I was reporting.

The issue at hand being that the Recent Changes list seemed not to have been displaying all the Changes.

I noticed this only when reviewing an apparent single change and it became obvious that the 'diff' was indicating that it was a re-edit of a prior change that should have been included in the diff-page I would have followed.

I don't know enough about the in-depths mechanics of the wiki backend to fully diagnose the possible cause, or possibly work out if it is my error in adapting to the 'improved' site. (Not sure I like this new inline editor, but... I'm giving it a go anyway!) However, from Celene's response below, it looks like I gave enough information for it to make enough sense to someone who does.

Not that I know it's fixed yet, but I'll take the confidence of that 'fixed!' reply at face-value for now. ;) 92.23.5.92 19:14, 23 July 2026 (UTC)

Specifically it's due to a weird interaction between a recent update to MariaDB and MediaWiki where writes get dropped sometime and then not retried. This is theoretically on MediaWiki to fix but they have not done so yet, luckily there is a compatibility setting that fixes this. Celene (talk) 21:57, 23 July 2026 (UTC)

Thanks for pointing this out! This should hopefully be resolved now. Celene (talk) 07:43, 23 July 2026 (UTC)

Template:template

I don't know anything of the decision behind this, but noting that Template:template is now redirecting to Template:tl, after one of many refinements. (On Wikipedia, it is indeed Template:Template link, hence the short-form name of the link, though it has for a vast majority of the time been just Template:template here.)

I would have thought that the practice should instead be that the shortcut term redirects to the full page, for all the obvious reason. But maybe I'm not party to some new thinking about this. Is this, then, something that needs to be done with everything else (e.g. {{Citation needed}} -> {{cn}}, or one of the other initialisms that may be prefered)? Or is it something that should be switched again, in this case? 92.23.10.248 23:45, 2 August 2026 (UTC)

Agreed, I had used the shorter form because it had a longer history. But you're right, and I moved it back to template:Template FaviFake (talk) 14:46, 12 August 2026 (UTC)

PSA: MediaWiki page IDs have changed

This will be of interest or concern to almost no one, but:

Doubtless as a result of the recent big rehosting shift, all articles on explainxkcd.com appear to have different MediaWiki page IDs than they used to.

For example, our article 3250: Flag Design used to have MediaWiki page ID 30166, but it's now 5110. You can see the page ID for an article (among other metadata) by clicking on the "Page Information" link under "Tools" on the left sidebar.

I discovered this while updating the cross-site links on Wikidata. For example, on their page Q140129320, the "explain xkcd ID" identifier shows the old MediaWiki page ID of 30166, not the new ID 5110.

Presumably the point of tracking MediaWiki page IDs like this is that, if the title text of a page changes for whatever reason, the page ID won't. Here we have sort of the opposite situation, in that the titles have stayed the same, but the page IDs have all changed.

But with that said, I'm not sure that's why Wikidata tries to record MediaWiki page IDs for its cross-site links such as "explain xkcd ID", after all. In this case, at least, it doesn't actually use the page ID in its links — it uses the page title, so the old link still works. (Actually, many of the older links have issues, for a different reason, which I'll be correcting at some point.)

I hasten to add — I probably should have opened with this — that I am not complaining here; I am not reporting this as a problem that needs to be fixed, or anything like that. This is an almost-invisible implementation detail, an inevitable consequence of the recent migration, of concern to probably almost no one. I'm reporting it here just in case there are any other oddballs out there who might want to know. —Scs (talk) 16:45, 8 August 2026 (UTC)

Yes, I've noticed this as well. When navigating to page that contains a [[Special:Diff/]] link, the target obviously doesn't work and it send the user to a completely different diff. But I don't think this should be changed; almost nobody uses diff links. FaviFake (talk) 19:37, 8 August 2026 (UTC)

Well, I have used diff-links. But usually for "oh, by the way..." Talk items or similar that have needed to address my own or others' specific edits (why I did something, or looking into why someone else did, usually). In the manner that I've seen others do it, 'cos that's probably where I picked up the habit! They have probably looong since become unnecessary comments only of historic interest, so I'm absolutely not concerned about them needing to be 'corrected' in hindsight.

Perhaps, though, if I'm remembering the circumstances correctly (haven't actively checked), some more permanent usages of {{diff}} may be in comics updated after publication/similar, where the diff-template may have been used to point to the exact-same-name-but-since-overwritten image of the old version for a Trivia link to what the pre-change version might have been. (Not applicable when the new image was uploaded as a "v2" different file, of course.)

It would be fairly simple to just check for every page with a usage of diff and review them all... with Comic Explanation pages as the highest priority. Most of the Community Portal sub-pages are likely to have many smatterings of "hey, <this happened>!" by people (like myself), but probably don't need trying to work out what they should now be (might be fairly impossible, anyway). Those sitting in Comic Talk and User Talk pages are probably not worth bothering with unless anything stands out as seeming important enough to not only dig into the correct number but also to deal with the long-standing issue that was highlighted. - In short, I also don't expect very many edits to arise out of any review of this situation. But maybe a handful can and should be, even if not the exact ones I'm imagining will arise. 92.23.10.248 18:57, 9 August 2026 (UTC)

Thanks for tipping me off on this, it is *possible* I could find the original page IDs and do something about that, but it seems like it would be a complicated operation. Celene (talk) 00:40, 10 August 2026 (UTC)

Yeah I really don't think it's necessary, there are much more important issues we should worry about, like the RSS feed. FaviFake (talk) 15:20, 10 August 2026 (UTC)

Damn you're right! I think I have used a diff link at least once or twice in the Trivia of one of the Category:Comics edited after their publication. Someone should check those sometime. FaviFake (talk) 15:19, 10 August 2026 (UTC)