Note that some bugs related to options / local exceptions with default values are being fixed today (T368595), so you may want to test again and see if there are still any inconsistencies.

Resolved via T344978, but the target should be specified with query param: https://test.wikipedia.org/wiki/Special:Contributions?target=imported%3EAlex+Shih

Well, you may set $wgDefaultSkin to the one for registered users, and use the hook for anon users instead.

The ULS may also consider switching to a simple new mw.Api().saveOption( 'language', langCode, { global: 'override' } ) call.

The globalpreferenceoverrides API is not working although the response was {"globalpreferenceoverrides":"success"}

This should be fixed, it seems no one wants to write the User-notice and I don't think we need one.

The default user option of skin would be overridden with the value of $wgDefaultSkin: DefaultOptionsLookup.php#114

Or if you want to set a different skin for new users, you should try $wgConditionalUserOptions

We don't create user_properties entries for default options, and you may want to set $wgDefaultSkin instead.

I think we may need some words from the Web team. Why was someone assigned to do T364347 just a few days before their "last day", on the codebase that is not the Web team's main focus, and then just left the bug for WMDE to look into? While WMDE was not involved in the bugged change and thus was not very familiar with either the original task or the problem.

In T366419#9899722, @Jdlrobson wrote:

How is this impacting users right now? My understanding is some logged out users might not be getting the feature on wikis where no gadget is enabled?

In T366419#9897375, @awight wrote:

I've approved the patches,

IMHO T366419: Default user option for Reference Previews changed for users created before 2017/08/16 without any justification should have been a train blocker for last week, but no one identified the bug before the weekend.

@Jdlrobson Sorry, I have to re-subscribe you since I identified the cause and there is indeed a real bug.

In T366419#9871453, @Bean49 wrote:

It is disabled for logged in users.

Ah, I see, I think I got something, but I cannot verify it myself, because I don't have an old enough account (though not sure if it's needed).

What is enabled for anon users, is the Reference Tooltips gadget. Gadgets cannot be disabled individually for anon users, you can only disable all local wiki scripts with the ?safemode=1 query string.

In T366419#9871200, @Bean49 wrote:

I noticed afterwards that disabled setting is from Reference Tooltips gadget. Remains my original problem.

That's simply because they reverted the Common.css removal.

In T366517#9858471, @stjn wrote:

Can you clarify why the desktop version does not have the similar problem with CSS caching, though?

For this particular case:

<title>Wikipedia, wolna encyklopedia</title>
<script>
...
RLSTATE={"skins.vector.user.styles":"ready","ext.gadget.wikiflex":"ready","ext.gadget.infobox":"ready","ext.gadget.hlist":"ready",...};
RLPAGEMODULES=["ext.scribunto.logs","site","mediawiki.page.ready","skins.vector.js","ext.centralNotice.geoIP","ext.centralNotice.startUp","ext.gadget.ll-script-loader","ext.gadget.veKeepParameters","ext.gadget.szablon-galeria","ext.gadget.NavFrame",...];</script>
<script>(RLQ=window.RLQ||[]).push(function(){mw.loader.impl(function(){return["user.options@12s5i",function($,jQuery,require,module){mw.user.tokens.set({"patrolToken":"+\\","watchToken":"+\\","csrfToken":"+\\"});
}];});});</script>
<link rel="stylesheet" href="/w/load.php?lang=pl&amp;modules=ext.uls.interlanguage%7Cext.visualEditor.desktopArticleTarget.noscript%7Cext.wikimediaBadges%7Cext.wikimediamessages.styles%7Cskins.vector.icons%2Cstyles%7Cskins.vector.search.codex.styles&amp;only=styles&amp;skin=vector-2022">
<script async="" src="/w/load.php?lang=pl&amp;modules=startup&amp;only=scripts&amp;raw=1&amp;skin=vector-2022"></script>
<meta name="ResourceLoaderDynamicStyles" content="">
<link rel="stylesheet" href="/w/load.php?lang=pl&amp;modules=ext.gadget.citation-access-info%2Chlist%2Cinfobox%2Csmall-references%2Csprawdz-problemy-szablony%2Cwikiflex&amp;only=styles&amp;skin=vector-2022">
<link rel="stylesheet" href="/w/load.php?lang=pl&amp;modules=site.styles&amp;only=styles&amp;skin=vector-2022">
<meta name="generator" content="MediaWiki 1.43.0-wmf.7">

CSS-only gadgets as stylesheet come with the HTML:

<link rel="stylesheet" href="/w/load.php?lang=pl&amp;modules=ext.gadget.citation-access-info%2Chlist%2Cinfobox%2Csmall-references%2Csprawdz-problemy-szablony%2Cwikiflex&amp;only=styles&amp;skin=vector-2022">

This is because ResourceLoader modules would be inlined into the page HTML, either as a stylesheet link and loaded directly (CSS-only gadgets) or in the RLPAGEMODULES array and loaded by the startup module (general gadgets), while the page HTML can be cached up to one week(?) in wmf-hosted wikis for anon users.

According to MainConfigSchema.php#2225 and the original commit 27105c21295dbc16532875feb3582a0555576e73 which added this config:

In T338342#8920280, @Aklapper wrote:

See also T27611 for previous discussion on this topic.

Variant names can be obtained from the meta=languageinfo API (see also T302200), play with API sandbox for more parameters

(For skins-demo.wmflabs.org, according to Wikitech doc, the primary maintainer of it is @Jdlrobson)

It's on 1.42 but not 1.41 as far as I can see. https://phabricator.wikimedia.org/source/mediawiki/branches/master/;21d8d9863b393e0bea608ac2f926b40bfecff9ad

In T365316#9811034, @Func wrote:

This is due to the removal of that deprecated class alias, you should report at their repo: https://gerrit.wikimedia.org/g/mediawiki/core/+/bb1f7e4aa2c87039e87291ef1ed31ca955a23eb7/RELEASE-NOTES-1.42#420

This is due to the removal of that deprecated class alias, you should report at their repo: https://gerrit.wikimedia.org/g/mediawiki/core/+/bb1f7e4aa2c87039e87291ef1ed31ca955a23eb7/RELEASE-NOTES-1.42#420

Note: mergeMessageFileList.php needs to be updated for wmf-hosted sites and wiki farms using manualRecache for $wgLocalisationCacheConf

Related: T200506

This is because of calls to Module:TemplateExist, and this report should be closed as invalid. cc @A2569875, the author of that module.

According to the protection log by Xiplus-abot, some "templates" already have 1026 transclusions as of 30 January.

In T361177#9744616, @SD_hehua wrote:

Or is it just cache? I cannot reproduce it stably.

In T282499#9730874, @cscott wrote:

1. Current Parsoid calls back to the legacy Parser to handle various types of content. That can cause there to be multiple $parser objects used on a given page. Most *present* issues with "linear parsing" are due to the fact that, even though the parse is technically in order, data being attached to the Parser object is lost because there are multiple parsers in play.

The current implementation of var_final (after commit 9597f365) is nothing more special than others, if anything will break in the future, that would be the whole extension.

In T361177#9669232, @daniel wrote:

So the fix would be this line? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1013392/9/includes/objectcache/ObjectCacheFactory.php#106

In T361177#9668964, @daniel wrote:

In T361177#9668179, @Func wrote:

Caused by commit d372626b97e83ec1f82b88e75fbaadf99ad2f89b for T358346

Can you explain how that patch is causing the problem? I fail to see the connection.