The installation of ReferenceTooltips for anonymous users by default which loads jquery.ui and oojs-ui-core (perhaps this could be revisited in light of T282999)

It works for me on mobile Chrome, it doesn't on mobile Firefox. This should be consistent with both of your screenshots.

If I'm correct, https://quarry.wmcloud.org/query/70320 lists 58 revisions created in last month not having their corresponding entry in the recentchanges table.

My cron jobs are now fully migrated to k8s. I am still inclined to using the grid for one-off jobs due to the current retry policy, but surely will go with k8s as soon as it is solved, too.

I don't see any change on mobile browsers (FF & Chrome) and plwiktionary (1.40.0-wmf.8), on-screen keys are automatically upper-cased when I focus the search bar. On a desktop browser using the Minerva skin the search input field has an autocapitalize="none" attribute.

Most cron jobs are now moved to k8s and email notifications have been fixed, but I noticed that failed jobs are re-run, which is highly undesirable for me: T304893, T315114.

After some testing, I'm considering T317998 a blocker.

Here are my Grafana logs. I didn't receive any messages neither on successful nor failing jobs, regardless of the selected value for --emails (onfailure/onfinish/all).

Hello, thank you for the heads-up. No surprise at all, I had already taken some initial steps toward the migration and thus found and reported a few issues about the new framework I'd like to see solved before that happens: T301901, T302211, T304421. Anyway, those are no real blockers for me, so let me analyze the matter once again to see how I can adapt my jobs. Most of them should work fine; I'm mostly worried about the "dumpWatcher" one, which needs to start jobs from within another job (T315729).

I can confirm that, thank you!

Any SQL query involving the templatelinks table (e.g. select *) on eswiktionary and plwiktionary (group1) now returns:

Change is live, resolving.

But when my cronjob hasn’t run for weeks because it’s been crashing while processing data (or has run out of disk, etc.), I’d find it super useful to get an alert.

Is this a duplicate of T301901? See also T302211 regarding the out/err merge option.

Thank you, I have addressed this issue in https://github.com/vega/datalib/pull/112. Anyway, it seems that the repo is no longer maintained (see the note in their README.md) and now they resort to a different implementation at vega-util/isString.js.

I guess it will work, but I stated no official support for cross-wiki usage of gadgets via URL yet.

I have written a script which restores this feature using API calls: w:pl:Wikipedysta:Peter Bowman/highlight-stubs.js. The page length threshold is configurable via global variable.

@ArielGlenn this should be solved now (5,324,215,919 > 4,294,967,295):

The patch for it got deployed. Is it fixed now?

Can you create a user sandbox page on that wiki with some simple example tables?

Expanding on T42618#434018, wikt:pl:MediaWiki:Gadget-autonumber.css works with both regular and sorted (class="sortable") tables, either HTML or wiki-syntax ({| |}), all basic skins (including mobile Minerva). No extra column needed, just add class autonumber. Example: wikt:pl:WS:STAT.

@ArielGlenn is this already deployed? I can still see an overflow in wikidatawiki-20211020-pages-articles-multistream-index19.txt-p37553268p39053267.bz2, at element 38762216:Q37386589.

I have only tracked the specific instructions that generate this stuff, but the cause is yet unknown for me. After compiling recompressxml and running the following command, the index file reaches offset 120,501,329,952 without overflowing:

So, index files are populated in the format offset:pageid:title through this instruction in recompressxml.c, where offset is formatted as a 64-bit integer with %PRId64. The value of *fileOffset is obtained via outputhandler_get_offset in iohandlers.c:

Interestingly, this is not an issue for recombined multistream dumps. The file https://dumps.wikimedia.org/wikidatawiki/20210901/wikidatawiki-20210901-pages-articles-multistream-index.txt.bz2 reaches index value 127,758,927,237 without overflowing.

Also happening on plwikisource. Here we have two built-in players: one originating from a simple [[File:audio.mp3]] transclusion (contained in the infobox), another one introduced by the musical score. Apparently they interfere with each other if present on the same page, but having either of them alone is fine. Remarks (tested on Firefox/Win10):

• I can successfully reproduce the File-based player, this action opens a pop-up window. If I click then on the score-based player, I'm redirected to File:Undefined.
• Conversely, if I attempt to play the score-based track first, nothing happens and I get the "TypeError: title is undefined" on console. The File-based player is unresponsive from that point on.

Same issue on plwiki (ref, 1.37.0-wmf.12): Flagged revision with ID 63918438 exists with unexpected fr_page_id.

Tool pbbot has been moved to k8s. I'm a bit surprised that it stays well within default memory limits (512 Mi), while this would not be possible in sge (needs 5-6 Gi).

And here is the rationale for said newline (9b530b2b5a5008765ab0a226df8b5ec5f7182bd2):

I've tracked down the Status::getWikiText call, it is invoked from inside the default clause in EditPage::handleStatus. Turns out this is a regression introduced in T280766 by c87462097c89dd0711fa05c3bcec275ad6176f44, i.e. switching back from Html::errorBox to a plain <div class="error"> fixes the formatting of list elements.

The code generating those warnings should be TemplateStylesContent::getParserOutput and the ParserOutput is processed in EditPage::getPreviewText() and neither invoke it.

There are four tomcat-xxx jobs currently running (sge-status), mine included.

I can confirm this is an issue in plwiki and plwiktionary. Regarding the latter, I observed that bot accounts are able to move reviewed articles, whereas users with the editor right can't (both have in common the autoconfirmed flag). See wikt:pl:Special:ListGroupRights.

This issue also affects ?action=history and user contribs, where <li> elements used to have a prominent blue background (on plwiki and plwiktionary).

One word of caution, esp. re: automation:

In 2015, this information was moved from global variables named wg* to mw.config.

Is there any way to tell the difference between old and new Vector skins in CSS? I mean, both variants seem to use the same skin-vector class in the <body> element, but there might arise a need to address specific tweaks to either one. I'm thinking of the From Wikipedia, the free encyclopedia text (a.k.a. sitesub?) which is not present in certain projects, e.g. plwiki. A prominent blank space is created beneath the first heading after this change, as you can see in T248761#6757107, so restoring it (only on the new Vector skin) could actually help.

(...) since anonymous readers would have compact interwiki list anyway.

Temp hack deployed on plwiki (diff):

Diffs (i.e. "Show changes") are still rendered in sans serif when requested via Live Preview (plwiktionary, 1.35.0-wmf.30 (rMWcbce38f71d1d)).

In T249526#6035209, @valerio.bozzolan wrote:

(...)
Having said I'm not 100.00% sure about my inspection - I think that one of my problems is that the server was replying some headers with "not-canonical" fields. See the set-cookie instead of the traditional Set-Cookie. This is maybe weird but legitimate as per RFC2616 so it was a client code fault.

What do you think about that "not-canonical" set-cookie? Can you reproduce it?

In T224712#5920479, @Dvorapa wrote:

After some other tests:
zh.wikisource.org API sometimes generates invalid new token (using action=query&meta=tokens). This token gives login response of NeedToken with another invalid token generated. This token gives login response of NeedToken with yet another invalid token generated. And so on...
After a couple of attempts I successfully reproduced it also using zh:ws API sandbox

I can confirm this is working as expected, thanks!

This just happened to me when I requested https://es.wiktionary.org/w/index.php?title=Especial:Restaurar&target=Discusi%C3%B3n%3Aelefanta&timestamp=20191115152327&diff=prev.

Same happens on plwiki. Please note that namespace File is listed at Page review statistics (and pages therein can be marked as reviewed) even though it is not configured by the FR extension on this project (per NOC, look for $wgDBname == 'plwiki').

As reported on enwiktionary (ref), users are unable to create pages starting with an uppercase letter if their lowercase equivalent already exists. It seems that the converse is not true: I can start editing a lowercase-first page while its uppercase counterpart had been already created.

@bd808 Thanks, increasing -mem value from 5g to 8g made my jobs respond again, I'll try to adjust it to something in between. I was hoping to ultimately avoid this - unable to create native thread seemed unrelated to the amount of memory (IMO, in spite of the OOM error class) and 5g was already high, compare with the default vmem size as specified in that link. I never had to increase this limit in over 3 years and something changed just a few days ago, so I wanted to leave my feedback here. Please feel free to close this task if it's OK to raise -mem that high.

I've been checking linter errors on eswiktionary, it should qualify now.

Hi, @jcrespo. Per your comment at T138283#2412013, I disabled connection pooling only for the replicas and -somehow- convinced myself that the tools-db config was good to keep as it was. Excuse my (severe) lack of understanding, I've just killed all connections and corrected the settings for any db resources that were making use of pools.

Much better now, although I find it a bit too hard to tell the difference between unchecked pages and pending edits. Compare:

Thank you for the quick response and explanation. In case someone gets confused, those restrictions become evident when the generator= query is applied to more than one title.

There is an use case for /api.php?action=purge on plwiktionary, see the task description in T109638: Page categorization logs expose user's IP.