After some digging, it looks like up to https://github.com/TecharoHQ/anubis/pull/1155 (which was pushed on Sept 27, so about two months after we added anubis), anubis always redirected multiple slashes! That was fixed in v1.23, but there's a good chance we still have the old version.
@MusikAnimal : please tell me we're currently running on <v1.23 so we can finally get rid of this issue; and if so, could you please try and upgrade it?

Fix deployed.

Thanks for the report! looking into it.

Fix merged, will go live next deployment.

Deployed.

Fix merged (what was I thinking? I *think* I remember testing back then. But anyhow). @MusikAnimal : could you deploy that please?

Working on it.

I've temporarily commented out our two uses to prevent all the prod crashes.

Uh-uh, based on the 30 failmails with Unknown column 'revs.rev_sha1', I think we're too late on this one.

Thanks for the report!
We had a too greedy regex. Fix merged, will go live next deployment.

Pretty sure this is the same issue; triple-slash redirected to simple slash (here redirected to https://xtools.wmcloud.org/globalcontribs/NguoiDungKhongDinhDanh/all/2025-10-22T20:53:29Z, which is a 404 for the same reason as on the other side).

Quick testing (1, 2) suggests that the time to join on slots and content etc is negligible; I'm getting about the same run times by doing that as by fetching revision.
Plus, losing revert detection for the crushing majority of edits (2020 is pretty recent) would be a shame. It'd be nice if the tag was retroactively added, but it looks like that's not planned.
(Oh my, they said "in three weeks" on Oct 3, which means we likely have only a few days to fix it.)
Also, on revert implementation: would it be unreasonable to look for more than 1 sha1 back? MW does 15.

Noting for reference that in the end we do have access to information_schema.tables, which makes our life tremendously easier.

Done better by Musikanimal in #571.

(was deployed this summer)

@MusikAnimal : I believe this is another consequence of routing setup changes. From https://xtools.wmcloud.org/pages/en.wikipedia.org/Ortizesp/0/noredirects/all, the URL for the next page is https://xtools.wmcloud.org/pages/en.wikipedia.org/Ortizesp/0/noredirects/all///2023-10-04T05:59:30Z, which is correct: there are two empty spaces between slashes to say there is no start date and no end date; and the offset is indeed the third parameter after the deleted param. However, it at some point of the routing is redirected to https://xtools.wmcloud.org/pages/en.wikipedia.org/Ortizesp/0/noredirects/all/2023-10-04T05:59:30Z, which doesn't work: the offset is now being interpreted as a start date, which it doesn't match.
Do you think this is something easily fixable in routing (if an option like "collapse consecutive slashes" can be disabled), or should we just adapt for the start parameter to possibly be interpreted as an offset? I'm afraid we would also have other fixes to do in other places if it's the second case.

(From the XTools side) The regexes that define routes for ip ranges haven't changed in years, so I can't exactly tell you why escaped urls don't work anymore.
One possibility: we have this summer deployed Anubis to fight the bot traffic (T400229); during which work our routing setup has changed a bit, which could perhaps have changed our behaviour regarding escaped characters. (@MusikAnimal probably knows more about this.)
As far as I can see, this link should be changed in the CheckUser extension.

We're still on github (for the time being; we've been considering moving to gerrit but haven't yet), so you could just submit a PR over there if you really want to do this. (Regarding capacity, you'd be surprised how quickly one can learn.)

Adminscore is, to be frank, not a priority. What constitutes need for or readiness for adminship is extremely subjective, and (perhaps more importantly) extremely wiki-dependent. This tool is here because it was there in 2017 when MusikAnimal & co took over the project, and because some people out there want to keep it, but it should probably move to a new home if anyone really wants to take care of it. XTools is for statistics, and the idea of an "admin score" is pretty far from that (plus, we already have a lot of things on our hands (could always use some help)).

In T380262#11161076, @MusikAnimal wrote:

@Alien333 How important would you say turning line wrapping off is to Wikisourcers? Here we're forcing it to be on.

I won't claim to speak for everyone everywhere, but probably not that much? I didn't even know one could turn line wrapping off, tbh. I think that the intersection of people who know it was possible and people who routinely use it is pretty small.
It would perhaps be more of a problem for wikis where they have content much wider than tall. But then again, they already have a full-width window, so not that bad.
So in the end I think it'd be fine to force it on. If you want to be 100% sure, go ask at the mulws scriptorium; over there they have plenty of languages and different perspectives.
(Sorry for not being very responsive, a bit busy irl.)

@OpalYosutebito : Please don't reopen again. It's the same task and the same cause (the quote). Right now we're just waiting for MusikAnimal to deploy the fix.

Well, removed them in the translations, but there's still the issue of deciding whether we want them to be allowed.

There we go. @MusikAnimal : would you mind putting this in prod? It's a quite little thing but I'm pretty sure that the issue will come up often in the few weeks till we put out the next release.

Problem seems pretty straightforward; in that one place we're directly injecting parameters as-is instead of using :whatever and then letting executeProjectsQuery take care of the escaping. (My fault, too.)

Note: XTools is now using Anubis in production, and it's worked well. (See conclusions at T400229.)

@jsn.sherman : supported, yes, but not mandatory: there are still surveys that barge into page content.

In the end: added column and pie chart in PagesCreated, just kept the change tag pie chart for EditCounter, added column (but not pie chart) to TopEdits (all still in same PR, see there for details).