RestrictionStore looks good.

The following places remain to be migrated:

The following places remain to be migrated:

This should be done besides Special:RecentChangesLinked (T411577) and SpecialUnusedTemplates.

^ During the closure (T411501), I reassigned crwiki and klwiki from group2 to group0 and moved them to wmf.5 to match the train’s current stage.

There is a single row in gorwikiquote which expired.

cc @Ladsgroup

@Marostegui this is can be done now

^ The sec patch can be removed from prod since it got trough Gerrit.

Need to wait until T408273 is done.

In T409743#11361300, @Catrope wrote:

An additional complication: MediaWiki no longer writes rows with pr_cascade=1 unless pr_type='edit', and hasn't done so since September 2008. However, the page affected by this bug hasn't had its protection settings changed since March 2008, so it still has a legacy protection row with pr_type='move', pr_cascade=1. The number of affected pages is probably pretty small: I looked at a few large wikis and saw only this one on enwikibooks, 30 on enwiki, 0 on dewiki, 0 on commonswiki and 1 on metawiki.

Thanks!

The code is clearly only allowing you to vanish yourself (unless there is a way to bypass disabled fields). Why this design was chosen is a different question.

FTR all three patches above got reverted since it makes it actually way worse on all wikis except metawiki.

actually a deprecation warning is not ubn

lets backport

This also needs fixing in ApiQueryInfo and BacklinksCache.

Imo its low rate and its only a deprecation warning

Follow-up to that, we might want to drop PHP 8.1 support in MW 1.45? If that is desired, we should update that sentence accordingly.

It works. Thanks!

Running on a debug host, the url is working.

The url it should be using is http://localhost:6206/published/datasets/querypage/MostTranscludedPages/testwiki.json, see the following.

Wiki has been created

Wiki has been created

Wiki is live

Wiki is live

Looks like dewikivoyage and itwikivoyage are fixed. (We expect rev_sha1 and comment_sha1 to contain the same value since both wikis only have one slot role.)

I also tested that this does not affect upgrading to 1.44.

I did test this.

I think this should only affect upgrades to 1.45 since https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1182149 was not part of 1.44.

It uses rev_timestamp instead of rev_page_timestamp which is a bad decision in this case.

Thanks for the help!

In T406027#11232397, @Lucas_Werkmeister_WMDE wrote:

[...]
Not sure if Wikibase is wrong to throw the exception, or if MediaWiki core is handling it wrongly. But anyway, that reapply change seems to work for now.

In T309738#11274873, @Scott_French wrote:

Internally, analytics.wikimedia.org is analytics-web.discovery.wmnet:8443 (note: what looks like a discovery service there is really a CNAME pointing to an-web1001.eqiad.wmnet). In any case, it looks like the analytics-web listener was added to the service mesh as part of the work in T380623 earlier this year.

Without knowing anything about the client or its use case [0], the k8s service where it will run will need to have (1) the listener enabled (i.e., will listen on localhost:6206) and (2) the network policies updated to allow connectivity to the relevant IP/port pair(s) (in this case, singular, if indeed it's backed by a single host).