In T325062#8580167, @Umherirrender wrote:

In T325062#8496526, @Nintendofan885 wrote:

FWIW look like https://en.wikipedia.org/w/index.php?title=Special:Log&user=ST47ProxyBot&type=block works

That looks for a specifc log type and is not affected, only viewing the default public logs.

In T369898#10409773, @daniel wrote:

In T369898#10409595, @Joe wrote:

I don't see how we can stop caching and purging the rest api urls.

We are currently not using the CDN cache for the new page/html endpoints. This may however change when they get used more.

In general, the access pattern for these APIs is much more "flat" than organic access, since they tend to be used bycrawlers. So they benefit a lot less from caching, the hit rate is likely low.

In T379482#10411741, @gerritbot wrote:

Change #1105275 had a related patch set uploaded (by Xqt; author: Dorna):

Sorry, wrong Task.

Change #1105275 had a related patch set uploaded (by Xqt; author: Dorna):

[pywikibot/core@master] Fix: Implement ISBN retrieval and handle missing data

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

Time is a flat circle, back to loading extension information from PHP it seems :) This was proposed as part of the original RfC even:

Reading and parsing a JSON file will be slower than loading a PHP file due to APC and other factors. However, we can mitigate that by providing a script to "compile" all the required JSON files into their PHP equivalents.

In T369898#10409595, @Joe wrote:

I don't see how we can stop caching and purging the rest api urls.

I don't see how we can stop caching and purging the rest api urls.

In T369898#10399898, @Joe wrote:

Right now, we send purges for each edit as follows:

• the main on-wiki url
• the main on-wiki url with action=history
• the mobile on-wiki url
• the restbase url for page/html

A workaround is install https://addons.mozilla.org/en-US/firefox/addon/wikimedia-debug-header/ and load (edit) this property using one of debug hosts.

Change #1103502 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/Kartographer@master] Switch Kartographer fullscreen button to Codex

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

Wait a sec. Are we talking parsoid mode or old parser mode ?

In T381915#10403899, @Jdlrobson wrote:

Another mitigation approach to take here is to load the library when the map is scrolled into view. The leaflet library is also pretty big and loaded on page load.

Another mitigation approach to take here is to load the library when the map is scrolled into view. The leaflet library is also pretty big and loaded on page load.

In T381915#10402851, @awight wrote:

Okay, I found that it's actually the dependency on mediawiki.router which depends in turn on oojs. This module provides OO.Router and uses OO.Registry.

Okay, I found that it's actually the dependency on mediawiki.router which depends in turn on oojs. This module provides OO.Router and uses OO.Registry.

The ResourceLoader modules already attempt to do exactly this, and the only direct OOUI dependency in static mode is currently oojs-ui.styles.icons-media which was not supposed to pull in the entire bundle. +1 to switching to codex styles.

For context: We worked on this extension in our past WMDE-GeoInfo-FocusArea. We are very interested but unfortunately can't make promisses. The issue appears to be quite old. I believe it goes back to 2016 when the static mode for high-traffic wikis was originally implemented, see T148070 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Kartographer/+/317018/8/modules/staticframe/staticframe.js#84. I guess the assumption back then was that OOUI will be loaded anyway on every page load. This is apparently not always true any more since we are slowly migrating to Codex and Desktop Improvements (Vector 2022).

Mentioned in SAL (#wikimedia-operations) [2024-12-12T14:30:08Z] <Amir1> ladsgroup@mwmaint2002:~$ foreachwikiindblist all userOptions.php --delete VectorSkinVersion (T54777)

In T369898#9990753, @cscott wrote:

For completeness, another option is the varnish "x-key" system, which involves two research projects. One is that implementation of x-key in varnish appears to be incomplete, and the second is that the assignment of appropriate x-keys to URLs is non-trivial as well. There are too many templates used on a page like [[Barack Obama]] to naively assign one x-key to every recursively-included template, so we still need to come up with a mechanism to determine which of the templates deserve an x-key assigned, likely based on purge statistics.

My primary concern here would be the article namespace, but generally given the increased adoption of Codex, OOUI on page load anywhere is probably not a good idea (particularly if that page is already loading Codex)

Is this considered a bug for all namespaces or for some in particular? cc @Jdlrobson-WMF

This might be a reasonable pair of hypotheses for annual planning:

1. Instrument edits to identify edits with the highest rank (edit frequency * usage count * % no op edits) and analyze to determine edit reason and whether website scalability could be improved by omitting CDN purges for these edits.