For historical context, this screenshot used the "Group changes by page" (usenewrc) preference enabled, which was recently changed from opt-in to default in MediaWiki core (and is still opt-in on enwiki and other wikis today via wmgEnhancedRecentChanges).

This is still broken and makes various performance analysis and improvements hard or impossible.

In T349276#11429160, @Lucas_Werkmeister_WMDE wrote:

[…]
FWIW, what I had in mind was no option / CLI API at all. I think this should be enabled by default, so that developers in a Cypress-using extension can run fresh-node -- npm install and then fresh-node -- npm run cypress:run (or similar) and it will Just Work (Cypress having downloaded itself into the shared cache directory in a postinstall script if necessary). Though of course that doesn’t rule out options to change the cache “name” or to disable the cache.

@Samwilson It may be worth tracing with git-blame how that message came to be, but without context, I'd remove "This is permanent" from the button label, and instead append it as bolded text to the line of text above that button.

Perhaps in a few years, if/when there is a need for it, in relation to the purpose of the mirror. The purpose of the mirror is to read wmgRC2UDPPrefix, which is frozen per irc.wikimedia.org so there's not likely to be a need to update it. Don't wait for it.

These are read-only mirrors of the wmf-config repo. They don't need to be updated in real time, are not used in production, and are not used in relation to Metrics Platform.

In T399165#10992577, @Arendpieter wrote:

[…] I thought — perhaps incorrectly — that after SUL3 was enabled on all Wikimedia projects, all such actions were moved to auth.wikimedia.org. Is that not the case?

In T200629#11502366, @thiemowmde wrote:

[…] A much better solution would be to disable the feature in the PHP compiler that looks for known function names in unrelated namespaces. […]

In T302623#11499381, @Krinkle wrote:

Looks like we have a major regression in latency, starting in November.

Grafana: Backend Pageview Timing dashboard:

Test setup:

• latest master of MediaWiki and Math extension.
• default configuration.
• logged-in
• change math preference from default "native" (MathML) to MathJax (MathML+MathJax).

I think an auto-fix should be a requirement if we want to make this a rule.

In T413958#11499236, @Lucas_Werkmeister_WMDE wrote:

Ori said that “With [fully-qualified array_key_exists() calls], getAll() for enwiki goes from 0.952 ms to 0.688 ms, ~40% faster!” (IRC).

Looks like we have a major regression in latency, starting in November. This is visible on the Grafana: Backend Pageview Timing dashboard:

New plan for the remaining work (from Dec 2025, per @MSantos, @Physikerwelt and myself).

I think of PHP 8.3 support and ci-test-error as different, not overlapping. The former for fixing issues before CI is enabled for a PHP version (or issues not covered by CI), and the latter for CI errors (i.e. Jenkins-Bot sets V-1 and prevents merging a patch, because one or more jobs is failing).

In T408917#11379328, @Krinkle wrote:

[…] In the Arc Lamp client instrument, we set the main frame based on $_SERVER['SCRIPT_FILENAME'] when collecting trace samples. […] Given that auth.wikimedia has a special RewriteRule, maybe thats getting messed up? […]

In T413213#11496654, @Atieno wrote:

[…] I have in my command history git tag list that was supposed to be git tag --list that has caused this.

In T407122#11475111, @HCoplin-WMF wrote:

Can I assume this can be done in early-mid Jan?

disable H322

In T364245#11487519, @Ladsgroup wrote:

[enwiki]> select count(*) from revision left join recentchanges on rev_id = rc_this_oldid and rc_source = 'mw.edit' where rev_timestamp like '202512%' and rc_id is null;
+----------+
| count(*) |
+----------+
|   297489 |
+----------+

[enwiki]> select count(*) from revision left join recentchanges on rev_id = rc_this_oldid and rc_source = 'mw.edit' where rev_timestamp like '202512%';
+----------+
| count(*) |
+----------+
|  5193756 |
+----------+

Let's re-test and verify. I suspect this may still be broken, despite the three scenarios in T33639 being presumed fixed.

Task description in the year 2011:

In other words, even if you're capable of viewing a cache and your browser doesn't have a stale user cache in it you still won't get a cached page back. This means that logging in and then logging back out will make your wiki viewing potentially slower than being logged in.

1. MediaWiki core: ApiBase::logFeatureUsage() -> wfDebugLog( 'api-feature-usage' )
2. (WMF) wmf-config Monolog setup
3. (WMF) Logstash
4. (WMF) a sanitized version to the elasticsearch cluster used by CirrusSearch
5. ApiFeatureUsage extension: read from Elastic cluster

Final report for WE6.4.8 Support PHP 8.3 upgrade (m:FY2025-2026#Q2).

In T360995#11467234, @Novem_Linguae wrote:

Any thoughts yet on what version of PHP we should target next? 8.4 or 8.5? Picking this would let us create the next ticket in the series, since this one is close to wrapping up.

In T360995#11467234, @Novem_Linguae wrote:

Any thoughts yet on what version of PHP we should target next? 8.4 or 8.5? Picking this would let us create the next ticket in the series, since this one is close to wrapping up.

@Hokwelum This release is now live on Packagist. This task is marked as blocker for the next MW 1.43, 1.44, and 1.45 patch releases (to improve PHP 8.5 support). This means the core+vendor updates should be applied to these release branches as well, in addition to master.

In T360995#11437108, @Krinkle wrote:

Proposed changes for the checklist so far:

• (diff) In the Test phase, swap "Validation and end-to-end testing" and "Monitoring and fixing". […]
• (diff) Move "Beta Cluster switch" from Rollout to Preparation phase, and add "Create production images for PHP X.Y and add new flavour to MediaWiki deployments" to Preparation phase. […]
• (diff) In the Rollout phase, make inclusion of Dumps 1.0 (mw-on-k8s servergroup "mediawiki-dumps-legacy") and deployment server explicit. […]

Closing this task as the checklist is done, with the below remaining points delined this time.

Resetting assignee since this was auto-assigned to me in 2022 unrelated to the present day, as the Performance Team declining the task as a memcached/BagOStuff issue.

For context, I believe the reason $wgRestAllowCrossOriginCookieAuth is disabled by default and prod, is for CDN performance and (by extent) the hardware capacity for MediaWiki on misses.