@matej_suchanek Profiling action=history shows a similar cost from ChangeTags::tagDescription that's still there via ChangeTags::formatSummaryRow and HistoryPager.

In T47514#9196663, @Esanders wrote:

Do you plan on supporting package files modules when in resource loader debug mode?

channel=authentication
level=INFO

MediaWiki\Auth\AuthManager::autoCreateUser: creating new user ({username}) - from: {from}

In T346832#9185507, @gerritbot wrote:

Change 959364 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] OutputPage: Client preferences should work for IP masked users

https://gerrit.wikimedia.org/r/959364

Why is Echo making internal HTTP requests in the first place? For the badge, it afaik reads the global database directly.

In T342201#9178264, @Tgr wrote:

[…] A race condition between writing the CentralAuth token to the memcached cluster of the other DC and making the followup request? Shouldn't memcached be much faster?

In T346853#9181413, @DLynch wrote:

I can't reproduce this. I have tried in Chrome and in Firefox 117.0.1 (both on mac).

In T63007#9192636, @Izno wrote:

In T63007#9192492, @Krinkle wrote:

[…] you could narrow your gadget to actions=edit,specials. […]

[…] but |namespace=-1 also would fit how special pages are dealt with (if that isn't already supported).[…]

In T63007#9190253, @Xover wrote:

In T204201#9127376 I describe a use case that needs OR semantics for conditions; specifically to load a charinsert-ish Gadget on all pages with contentmodel wikitext and on Special:Upload […] I think it's important to keep in mind for those with their fingers (and minds) deep in this area.

I've reconfigured the wikimedia/metrics-platform package back from GitLab to github.com because it seems one of GitLab and Composer doesn'tt support the other to produce a dist package, and thus rebuilding mediawiki-bendor became a mess even for older versions.

I see 58 queries:

But! The constructor does mutate groupLoadsBySection. It adds a subkey under section for "generic" with the equivalent sectionLoads data. And that implicitly also does something else. It implicitly creates the $section if it didn't exist yet.
[…]
In reconfigure, we first read a specific cluster key (thus assuming it exists) and then add sectionLoads to it.

Looking at this more closely...

In T151002#9188509, @dcaro wrote:

We have a static floating name redis.svc.tools.eqiad1.wikimedia.cloud for the shared redis, I think that should address the concerns here […]

Resolving it but feel free to reopen if that does not address the issue.

Make the $wgObjectCaches['mcrouter']['servers'] an environmental variable we can define in values.yaml.

In T75714#8961708, @SD0001 wrote:

@Legoktm pointed out that page properties are an artifact of parsing and should only be modified within the parse, so instead of validating post-save we'd have to validate synchronously during the save – which I suppose is just about fine. The other option would be to do it post-save but store the result in some cache or a new db table.

Are there more than 10 repos in all of Wikimedia Gerrit that don't simply use i18n/ as the directory for all localisation files? I don't have the data, but it seems likely to me that it would be true. Adding complexity to all 1000+ extensions for that edge case is worth weighing the pros and cons over.

There's a possible related issue in T288624: PHP Warning: curl_multi_remove_handle(): supplied resource is not a valid cURL Multi Handle resource, which @tstarling investigated at Gerrit change 957894, and made an upstream PR:

Untagging MediaWiki-extensions-Gadgets, since Gadgets already leverage ResourceLoader and its caching/compression features. This task is about user scripts which are in MediaWiki core.

Untagging MediaWiki-Platform-Team since MediaWiki-Configuration does not have an owner today (mw:Maintainers).

See also:

• T299369: Consider removing global $userLang from onPageContentLanguage hook
• T341244: ParserOptions and Title::getPageViewLanguage may disagree on the lang/dir