I currently believe that this line in flaggedrevs.php is what's likely causing the attempted removals of movestable from the autoconfirmed groups on ukwiki & ruwikinews to not have an effect:

I mean, I guess I don't have a firm immediate opinion on that (though I guess my immediate reply would probably be something like 'if folks don't find package-lock.json results useful, that file name can easily be excluded from the results'). I admit that I've previously found Codesearch searching within composer.json file(s) to be useful, though.

Skimming through https://codesearch.wmcloud.org/deployed/?action=excludes & Ctrl+F-ing for the word probably, it seems like a large majority of excluded files with the reason "Trigram ratio too high" (at least, in the "MediaWiki & services at WMF" group) are false-positives.

Pasting the exclusion message here for searchability:

Trigram ratio too high (0.11), probably not text

Also noting that operations/puppet's modules/admin/data/data.yaml file is excluded for the same "Trigram ratio too high" reason.

Ah, okay :] In which case, I kinda defer to the Parsoid team on whether https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/704745 should be backported. From reading the commit message, it's unclear to me on whether that's necessary for Parsoid to work properly on >=PHP 8.4, or whether it (e.g.) modifies Parsoid to use some features that are newly available in PHP 8.4.
However... if it's not the former, I'm personally currently quite cautious about the idea of backporting it to 1.44/1.43; especially as (from testing locally just now) it doesn't seem to necessarily be backwards-compatible (and I'm not sure if we should be backporting code that doesn't have backwards-compatibility). Taking the PHPUnit tests I ran in T413573#11509656 as an example, they currently succeed for me locally when running PHP 8.4 on REL1_44; however, if I cherry-pick 704745 into REL1_44's vendor/wikimedia/parsoid, 19 of the same tests then fail.

@Dzahn checking just now on the device I used before, the 'Not Found' page was initially cached, but once I refreshed the page it now seems like it works :]

Just a note (apologies if there's a better place to raise this): When I click on any of the 'Transcript' buttons (at the top of each of the audio snippet windows), I get taken to a 'Not Found' page. E.g. https://www.wikipedia25.org/en/transcript/editor-robert-sim-why-wikipedia-is-trusted

(@DAlangi_WMF I think we might have reply-conflicted -- to be clear, I would have proposed backports to all the supported branches; but in this instance, the code causing these test failures (that was fixed by @matmarex's patch) seems to have been been present in MW 1.45 as its first release AFAICS)

In T414323#11521101, @taavi wrote:

Is this not an issue on the other supported release branches?

Yep, it does, thanks :D

In T403385#11502918, @Dzahn wrote:

In T403385#11502585, @Sebastian_Berlin-WMSE wrote:

I meant that as a way for people that don't already have an account (and don't know if they want one).

How many people exist who at the same time want to see Wikimedia Phabricator work boards but simultaneously never logged into a single Wikimedia wiki?

In T409283#11517260, @Jdforrester-WMF wrote

• Backport 1220366 to REL1_44, REL1_43 (REL1_45 already done in 1224160).

A PHP 8.4 check experimental build on the mediawiki/core change bumping Parsoid to 0.23.0-a11 has succeeded, so I guess PHP 8.4 CI now passes on MW Core (at least, on its own)?

What happens if you set $wgPHPSessionHandler = 'disable' in your LocalSettings.php? Does the issue go away?

Yep, the failure goes away with $wgPHPSessionHandling = 'disable'; :)
(I'm not yet completely clear yet on why this doesn't seem to show up in WMF CI - presumably if it did, the patch in question wouldn't have been able to be merged last September. I guess that $wgPHPSessionHandling must be set to either 'enable' or 'disable' somewhere in CI's LocalSettings.php, but a Codesearch didn't find where that might be happening...)

59467cab835a (1190344: Deprecate PHPSessionHandler and $wgPHPSessionHandling) seems to have introduced a new deprecation warning(/test failure) when I run tests locally on mediawiki/core:

Thank you! :)

Confirmed still occurring:

$ composer phpunit:entrypoint -- --filter "Thumbnail(404)?EntryPointTest"

https://packagist.org/packages/wikimedia/smash-pig has updated & the new homepage link works!

In T393869#10823548, @hashar wrote:

For this task T393869, enabling parallel testing for REL1_44 is the immediate fix this one, and I am inclined to mark it resolved now that CI passes :)

In T414273#11511413, @Aklapper wrote:

@SecurityPatchBot comments as there is some work to do, an issue to fix: Rebasing a patch. Which problem is solved [...]

Hmm, that's a good point. Thank you for bringing that up, @SomeRandomDeveloper :)

In T414290#11511128, @Ladsgroup wrote:

https://codesearch.wmcloud.org/_health/ says "only" /search endpoint is down.

I'd therefore propose that a task's status is only reset to 'open' when its current status is a 'closed status' (ie., resolved / declined / invalid).

In T413579#11489951, @A_smart_kitten wrote:

Noting that this causes a *lot* of console-spam when running (e.g.) composer phpunit:entrypoint locally on PHP 8.5 [...]

(fwiw, using xdebug, I found out that these specific deprecation warnings seem to be coming from the SiteListTest data provider:

Deprecated:  Using null as an array offset is deprecated, use an empty string instead in /[...]/mediawiki/includes/Site/SiteList.php on line 153
Stack trace:
[...]
  17. /[...]/mediawiki/vendor/phpunit/phpunit/src/Util/Annotation/DocBlock.php:421
  18. /[...]/mediawiki/tests/phpunit/includes/Site/SiteListTest.php:30
  19. /[...]/mediawiki/includes/Site/SiteList.php:71
  20. /[...]/mediawiki/includes/Site/SiteList.php:92

(xref T263207: The `UserrightsPage` class is not safe to extend)

In T414077#11509524, @TheDJ wrote:

It seems we missed unknown/flac and unknown/mpeg are also possible suddenly.
https://commons.wikimedia.org/wiki/Special:MediaStatistics

(Merging into T414261: Exclude temporary accounts from Special:Statistics Active registered users - that task's title currently only mentions Special:Statistics, but its description links to https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:Aktive_Benutzer, so I assume the scope of that task covers Special:ActiveUsers as well)

Actually, a follow-up: I took a look at Codesearch (https://codesearch.wmcloud.org/deployed/?q=nodeValue&files=%5C.php for WMF-deployed code only); and, unfortunately, it seems like these failures relating to nodeValue might've been indicative of a wider backwards-compatibility problem.

See also T371662: Disable LonelyPages and Deadendpages on commons for a previous (currently-outstanding) request to disable some other special pages on Commons. (That task's history & patches contain some previous discussion on how that might be achieved from a technical POV)

One edge-case of the new IP block appeal tagging might be to do with partial-blocks. It seems like the current logic in SpecialMytalk.php might react to any blocks on an underlying IP address, not just sitewide blocks. So then, now that we also have the new tag, it seems like we're getting cases where:

• a temp account is created and its account-creation log entry is tagged with IP block appeal;
• ...but that same temp account is then still able to make edits elsewhere on the wiki (that aren't to appeal their IP block).

Maybe this might just be a matter of (currently untested):

Copying over a recent error message for this from IRC for searchability:

To avoid creating high replication lag, this transaction was aborted because the write duration (3.2673449516296) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead. [7cff12f6-3c48-4794-a63a-76d06ef36647] 2026-01-08 23:30:20: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"

In T413545#11486732, @A_smart_kitten wrote:

Also @Reedy FYI I filed T413573: CI failures on PHP 8.4 from some core tests that call Parsoid's `DOMCompat::querySelector` method just now

welp, turns out that one wasn't Parsoid's fault after all :p (but it's fixed now either way!)

For the record - confirming that, in a local dev environment (with mediawiki/core & mediawiki/skins/Vector), the reported tests pass using PHP 8.4 following @cscott's patch :)

This leads to a situation that some Core tests can fail without having Vector skin installed, introducing a dependency to Core tests.

I just came across a situation like that myself (with a PHPUnit test), and I guess the question that I have is -- should mediawiki/core tests be expected to pass without the Vector skin installed? Right now, I can see some arguments going both ways:

• On the one hand, MW Core is an independent repo to Vector (and so, the logic goes, it shouldn't depend on Vector - or, arguably, anything that isn't in its composer.json file - for its tests).
• On the other hand, maybe some functionality in MW Core wouldn't be expected to work properly without a skin installed(?)

In T414083#11504343, @Sophivorus wrote:

Perhaps the CSS can be reverted by a user-style or user-script for those that don't like it or need it for some specific workflow reason?

Ah, sorry - thank you for correcting me :)

In T414077#11503194, @Aklapper wrote:

I wonder if rMW5542962f2f0cdf1763ef352ed8ac94366e91d93a could have had any influence here.

git bisecting locally, that commit (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1222605) does appear to be the cause here FWICS

I mean, for a UX change, I feel like subjective 'I do/don't like it' opinions might hold a bit more weight than (say) for a change in logic/a change in an application's behaviour.
In this case, FWICS, part of the reasons (in T393289's task description) for it being deployed with Phab in the first place - which, to be clear, I'm not objecting to! - were 'lots of folks find it useful'; but then, wouldn't that mean that the opposite reason (ie., 'some folks don't find it useful/find it interrupts their workflow') might also be a valid case for introducing this sort of preference? /genq
But FWIW, there were some more specific use-cases that would (IMO) be applicable to this idea shared in T393289#10793673 & T393289#11502713.

FWIW I concur with generally wanting to see the full version of @Stashbot comments - I believe I made the same change to the user-styles myself locally before they were deployed with Phab - but I obviously don't know whether that opinion is shared by the majority of people who used these styles / who use Phabricator :)

Claiming this because, from the preliminary investigation I've done into the relevant code prior to filing this task, this seems (hopefully) relatively easily do-able; and because (after having looked at the code) I think I hopefully have a decent idea of how this could be implemented :)

In T403385#11386185, @Dzahn wrote:

It seems shutting down Diffusion has more of an effect on web crawlers than the workboard access.

(removing assignee automatically set when previously closing task in T175158#10018623)

Another follow-up @ T414003: Gerrit patch status comments have/cause inconsistent spacing on mobile devices