The change was unintentional, this happened because we renamed the field for coding convention reasons (having adopted eslint for JS recently) and the API passes along the array. I don't want to make a special case of not passing along the array as-is just for one field, so probably I guess we should normalize it to day_of_week and silence some linting in a few places.

Eh, we can't do much about that right now.
We'd need to update our chart library a lot. We're currently running a quite antique version of it, and I think newer versions take better care of stuff like that.

Bug found, fix uploaded.

@MusikAnimal
tl;dr: just going back to using information_schema.tables as that patch previously did should fix it.

It counts (Re)blocks, so blocks and block modifications. You were blocked two times and reblocked once, so that makes three. The first block was 3 days and the second was 1 week, so the longest is one week. The results are accurate.
You may instead be looking for what T392752: Add "total time spent blocked" counter suggests.

Oh well. This is the same kind of thing as T203315; again no solution but harcoding that accounts created between X and Y used that method, between Y and Z another one, since Z yet another one...
(Also, self-reminder: we need to figure out what the rule applied depends on. Is it account creation date? Say a user became autoconfirmed at time t-1 by the current rule then the rule gets changed at time t and now they're supposed to only become autoconfirmed at time t+1, what happens?)
We should also keep in mind T392551 and the wider work to function on third-party setups.
Settings for automatic rights can also be wiki-dependent (T321097 for something on ptwiki).

@Vladis13

But, I also can't find this category on ru.Wikisource.

(Re

FlaggedRevs is my current suspect

Wikisources do not have FlaggedRevs.
This seems to be happening exclusively on Wikisources, in one namespace created by the ProofreadPage extension, so it's probably related to that.)

We have lost CSS in one of our main content namespace, and this actively hampers editing.

This page was created three times, including once by Fillos X (log). So there's nothing wrong here.

Hello, this is an on-wiki gadget issue (see edit request at https://en.wikisource.org/wiki/MediaWiki_talk:Gadget-PageNumbers-core.js#Double-encoding_bug_with_=_in_filenames_(phab:T427111)) and not an issue with software that is tracked in Phabricator, therefore it is the wrong place for this.

Ok, sorry about <noinclude>. Visibly I was wrong
Another idea: when we remove templates etc, it looks like we could sometimes remove the child of an already-removed element, which would be compatible with this error message. I'll try and test that and report back. If the error depends on the traversal of the Crawler's nodes it could explain some things.
And no, it's not an issue about FlaggedRevs.

Ok, so after some investigation:: a number of huwiki templates have unclosed <noinclude> tags at the end for documentation. We are going to mitigate the issue (and anyhow the stats causing this error are not really meaningful for templates).

I think we're good to close this as done (with many thanks to @Krinkle)? Are we still missing anything? (Now both l10nbot and libraryupgrader automerge their patches.)

Fixed!

I can't reproduce locally, so I suspect this is a temporary issue due to some network problem or other.

Found, there's an error in the regex for the bot revert automated tool (an error that's been there for at least 6 years!). Thanks for the report. See edit request at https://meta.wikimedia.org/wiki/MediaWiki_talk:XTools-AutoEdits.json#Regex_mistake_for_"bot_revert"

In T424388#11857433, @Bhsd wrote:

I will not call it undoable, but it seems to me really difficult as it requires good understanding of both ProofreadPage and CodeMirror. Maybe we should consider a workaround instead at least for now? Do you have any alternative suggestions to mitigate the annoyance?

Well, nothing to do really and we're doing mostly fine.

After:

• removing the white-space: nowrap
• removing the width: auto that prevented the toc from taking the full width
• adding a max-width: max-content so that on wide screens it doesn't take useless estate (now the auto is away)
• slightly reducing the text size for one to still be able to sort of see the top of the section

looks like this:

Nothing to do on XTools' side.

Fixed.

Fixed in #622.

Note: some users are still reporting major usability issues with editing window height, though it doesn't happen to me and I don't understand exactly what has been done. From this:

Something new has just lost my ability to resize the edit window in the Page namespace. I will have to stop editing until this is fixed, since I cannot see enough of the text at one time to be able to proofread. I had a properly sized window until a few minutes ago, when I started a new page without window resizing. This problem exists on other Wikisource projects in their Page namespace equivalent as well, not just here.

Well, works now, so nothing more to say I suppose.

@Samwilson The changes introduced in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/1229438 to modules/page/ext.proofreadpage.page.edit.js, and more specifically

		// Initialize the height of the text UI to match what the resizing bar has stored.
		mw.hook( 'ext.WikiEditor.resize' ).add( ( resizingBar ) => {
			$editForm.find( '.wikiEditor-ui-text' ).css( 'height', resizingBar.getResizedPane().height() );
		} );

are breaking proofreadpage editing layout in at least some situations. It adds a very low height constraint (in my case 448px), which makes it impossible to see the whole image:

Deployed.

Deployed.

@Fnexy : This is not enough information for us to do anything.

Indeed, that, and we removed a user parameter that is I think still used, and we had a problem with slash support.

Errs as 404, probably we broke the deletionsummary routing. Looking into it.

@Kallichore It's been fixed already, just gotta deploy the change.

Don't intend to work on moving to -s everywhere in the near future.

Had to be undone because of mistake, to be redone.

Been deployed for a while I think?

Indeed.

(Typo of loadinganimation for loadingAnimation.)

@Stephan.Klage : this is (by far) not enough information to be acted upon. At least provide the URL you got the error on.

Gah, we'll have to go for - I suppose. AFAICS only 2 tools are affected for now: pages & globalcontribs. I've done it in #593. @MusikAnimal : Could you take a look? (Side note: beyond this issue the pagination in PC has issues; like no "back" buton; but that's a question for later). (Also, it appears that CI is broken again).

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?