With 08315c2031e62e3e0688f169944313e7c5bb9934 MediaWiki dropped PHP 8.1 support, making this much more urgent :/

Yes, sadly this never materialized in the way initial planned. Given I don't think I (or anyone else) will pick this up anytime soon, let's drop this for good.

Unassigning myself / moving back as I don't have a lot of progress on this, yet (ended up getting stuck on T403974#11372348).

Currently (on master / beta) adding a new entity type statement doesn't result in a drop down (but a simple text field). See: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1204644

Stumbled upon https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1204644?forceReload=true while working on this, will investigate further.

The initial patch caused T409740: Beta cluster is down due to 'No such service: WikibaseRepo.Settings', thus it got reverted. Re-submitted as https://gerrit.wikimedia.org/r/1203484.

Tested, looks fine now.

We're tackling T406844: wdio-wikibase depends on wdio-mediawiki v2 first.

After playing around with XDebug for a bit, I have to agree… I don't see any way to do this short of comparing the statement in the ChangeOp with the base revision (which is not only inelegant but also entirely at odds with the current structure of the editing code).

Adding the respective data types to VueNoScriptRendering::WBUI2025_SUPPORTED_DATATYPES does the trick.

This reminds me of T389199 (which ended up not being reproducible, just noting for reference).

The changes to the CSS scoping I will do on top of https://gerrit.wikimedia.org/r/1177962 tomorrow.

After more poking both on mwdebug1001 (hacking ClusterConfig::getInstance()->isDumps()) and by comparing identical runs on snapshot1015 / snapshot1016, I think that the performance differences are not reproducible anymore. Earlier on I missed that snapshot1016 has a considerable faster CPU than snapshot1015 which should explain the timing difference I saw between these hosts (which I couldn't reproduce on mwdebug1001).

One edge case that is not currently handled is links to the repo where the link text is a valid (maybe namespaced) entity id that deviates from the actual link target. An example could be: [[wd:Item:Q42395533|Q42]].

I looked into this a bit (by comparing manual script runs on snapshot1015 [which has /etc/wikimedia-servergroup] and snapshot1016). The additional time the scripts need seems to be almost completely user time and increase when lowering the batch size.

Note for parser caching: T394291#10836697

I'll have a more thorough look tomorrow or next week, but one thing to quickly test would be: Run the script with --dbgroupdefault somethingthatdoesnotexist and compare that to the speed without that parameter. AFAIR this will make MediaWiki "fallback" to the usual DBs.

Not quite sure where to leave this, so I'll put it here. Currently EntityView expects that it can produce html only depending on the language (code) that can canonically be used (and cached!). If we want to allow this feature, at least temporarily, to depend on the user (settings), we will need to break this assumption. One way to adopt the above change to T394704: [MEX] M1 - Create a beta feature (untested):