Change 987721 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/BetaFeatures@master] Support conditional user defaults

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

Change 987722 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/CentralAuth@master] Support conditional user defaults

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

Change 987723 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@master] Support conditional user defaults

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

Change 987725 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/MultimediaViewer@master] Support conditional user defaults

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

Change 987749 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/WikimediaEvents@master] Support conditional user defaults

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

Change 987750 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/skins/Vector@master] Support conditional user defaults

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

Extension:LiquidThreads (no changes required)

I think that one needs to look up the user based on wl_user and apply conditional preferences. And since this is batch processing, it probably needs to batch the user lookup (which might or might not help depending on the condition, but it will for the one condition we currently have).

The other thing that would technically break is GenderCache, but then a conditional default for gender doesn't make any sense.

Extension:MediaSearch (no changes required)

This does need a change - it's the same as SpecialSearch which does get updated in the core patch.

Change 988506 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/MediaSearch@master] Support conditional user defaults

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

In T354329#9438997, @Tgr wrote:

Extension:LiquidThreads (no changes required)

I think that one needs to look up the user based on wl_user and apply conditional preferences. And since this is batch processing, it probably needs to batch the user lookup (which might or might not help depending on the condition, but it will for the one condition we currently have).

Technically, yes. However, the current code (for both branches) depends on the default to be (unconditionally) false (setting it to true would break the current code as well, even without conditional defaults). If the default was true, NewMessages:: getRowsObject (or more precisely, its usage in getNotifyUsers) would break, regardless of conditional defaults. This is why I listed it as "no changes required", because the breakage happens either way.

Granted, if the preference was hidden, the breakage would only happen for conditional defaults only, but dunno whether it makes sense to fix it half-way. I'll fill a task to refactor the code to work irrespective of site configuration. I probably should've clarified that somewhere :).

The other thing that would technically break is GenderCache, but then a conditional default for gender doesn't make any sense.

Yeah, agreed. Conceptually, fixing this might make sense as well though. Will fill a pro-forma task as well.

In T354329#9438998, @Tgr wrote:

Extension:MediaSearch (no changes required)

This does need a change - it's the same as SpecialSearch which does get updated in the core patch.

Good catch! Fixed, see https://gerrit.wikimedia.org/r/988506.

Change 987722 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Support conditional user defaults

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

Change 988506 merged by jenkins-bot:

[mediawiki/extensions/MediaSearch@master] Support conditional user defaults

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

Change 987750 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Support conditional user defaults

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

Change 987749 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] Support conditional user defaults

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

Change 987721 merged by jenkins-bot:

[mediawiki/extensions/BetaFeatures@master] Support conditional user defaults

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

Change 987725 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@master] Support conditional user defaults

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

Change 987723 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Support conditional user defaults

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

In T354329#9441740, @Urbanecm_WMF wrote:

I think that one needs to look up the user based on wl_user and apply conditional preferences. And since this is batch processing, it probably needs to batch the user lookup (which might or might not help depending on the condition, but it will for the one condition we currently have).

Technically, yes. However, the current code (for both branches) depends on the default to be (unconditionally) false (setting it to true would break the current code as well, even without conditional defaults). If the default was true, NewMessages:: getRowsObject (or more precisely, its usage in getNotifyUsers) would break, regardless of conditional defaults. This is why I listed it as "no changes required", because the breakage happens either way.

Fair point. It could just do a getOptions check instead of a direct database check, but fixing already broken code is beyond the scope of this task and probably not worth the effort anyway given how little that extension is used.

The other thing that would technically break is GenderCache, but then a conditional default for gender doesn't make any sense.

Yeah, agreed. Conceptually, fixing this might make sense as well though. Will fill a pro-forma task as well.

It cannot depend on the current user (since it's a sitewide cache) and needs to support batch loading users, which IMO makes fixing it way more effort than what's worth given the implausibility of the use case.