Per conversation, the team agreed to scope this task to the Appearance menu in Vector and create a new task for Minerva.

Minerva version here https://phabricator.wikimedia.org/T361505

Note: right now client preferences will only render if a client preference class is in the HTML element. Therefore in addition to skin-night-mode-page-disabled you will also need to add skin-theme-clientpref-light to pages where night mode has been disabled. From there, it should be a straightforward modification to resources/skins.vector.clientPreferences/clientPreferences.js to add some kind of note property in a similar way to how we do "callback".

This has a lot of overlap with T361158

There are two approaches to consider:

Option 1: Move all configurations to a separate JSON file accessible by both the frontend and backend.

• Pros:
  • Centralised configuration for managing features and client preferences.

• Cons:
  • Requires a significant restructuring of the code (a major refactor).
  • Involves maintaining separate logic in both the frontend and backend codebases, which can be complex.

Option 2: Follow the approach we used for managing themes (night/day/os) by using a specific class for disabled features.

• Pros:
  • Centralises decision-making, in the backend.
  • This method has been tested before and is proven to work.
  • Simplifies the frontend logic by allowing easy checks for class status.

• Cons:
  • Requires consideration during the migration of common files between Minerva and Vector skins, which could complicate future developments.

Quick Recommendation:

The second approach is preferred. It builds on a tried and tested method, offering simplicity and efficiency without the need for extensive refactoring.

Change #1016383 had a related patch set uploaded (by Mabualruz; author: Mabualruz):

[mediawiki/skins/Vector@master] feat(POC:clientPreferences): Adjust prefs based on options config

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

Notes from sync - work to be done:

1. Make sure that both classes are present in Vector, updating skin-night-mode-disabled to a more feature generic format (I believe we proposed skin-theme-excluded)
2. Update client prefs JS code to be able to handle the i18n label/message for letting users know the page is incompatible
3. For night mode handle the exclusion logic in the CSS using not selector
4. Figure out approach with Minerva (whether to use both classes or keep things roughly as they are currently and update the toast only)

...although, now that I'm writing this out I'm not confident we'll be able to support Justin's ideal of having the radio buttons be selectable because if we let the class be changed and rely on the disabled/excluded class to know when night mode is on, then tempate editors etc will also have to be using not selectors for their styling

@Jdlrobson might be nice to get your input here. We talked about doing things this way to allow for the design specified approach that allows the radio buttons to be interactive even on disabled pages, but I'm realizing this might not work if those classes are an exposed user interface

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

[mediawiki/skins/Vector@master] POC: Handle client preferences menu when night mode disabled

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

Rather than updating classes, I would suggest updating the clientPreferences library to allow forcing of display of client preferences and disabling the radio buttons. This is going to be the most elegant solution we do here, and will avoid opening the possibility of readers being able to override the night mode preference during page display and forcing it into a broken state.

Please see https://gerrit.wikimedia.org/r/1017191 - let's keep this as simple as possible. No more classes! :D

@JScherer-WMF could you clarify, on pages where the settings are overridden, should the radio buttons still be active or should they be disabled? It looks like Codex does have a disabled+selected state for radio buttons: https://doc.wikimedia.org/codex/latest/components/demos/radio.html#interaction-states That would reflect the users last chosen setting, but prevent them from changing it on the overridden page.

We want to let them change the settings on the overridden page, still. This is primarily to address the edge case where someone might want to make a change to the settings while on an overridden page. e.g. If you change the text size from large to standard on a small page, the a change will still take place. Also: if they want to change the settings for when they are back on the normal pages, they aren't limited while they're on overridden pages. Let me know if that makes sense!

Change #1018820 had a related patch set uploaded (by Jdrewniak; author: Jdrewniak):

[mediawiki/skins/Vector@master] [WIP] Add exclusion notice for night mode feature

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

In T361158#9699102, @JScherer-WMF wrote:

We want to let them change the settings on the overridden page, still. This is primarily to address the edge case where someone might want to make a change to the settings while on an overridden page. e.g. If you change the text size from large to standard on a small page, the a change will still take place. Also: if they want to change the settings for when they are back on the normal pages, they aren't limited while they're on overridden pages. Let me know if that makes sense!

Can we video chat about this some more before we add some complicated not selectors? I don't think we've really thought through this use case and I don't think it works as Justin might expect. I think if we don't disable this feature we will create a really bad and confusing experience here.

Change #1018820 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Add exclusion notice for night mode feature

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

The patch for this task only added a notice for the night mode setting. I've created a task to add this functionality for the remaining Appearance menu settings here: https://phabricator.wikimedia.org/T362911.

@ovasileva @Jdlrobson The night mode feature is present but usable as seen in the gif, unlike the one in beta from above.

Test Result - Prod

Status: ❌ FAIL
OS: macOS Sonoma 14.4.1
Browser: Chrome 124
Device: MBA
Emulated Device:NA

Test Artifact(s):

QA Steps

❌ AC1: Expected: the night mode feature should be present but unusable. There should be a message explaining night theme is not available.
Test link: https://en.wikipedia.org/w/index.php?title=bannana&vectornightmode=1

Test Result - Prod
Status: ✅ PASS
OS: macOS Sonoma 14.4.1
Browser: Chrome 124
Device: MBA
Emulated Device:NA

Test Artifact(s):

QA Steps
✅ AC1: Expected: the night mode feature should be present but unusable. There should be a message explaining night theme is not available.
Test link: https://en.wikipedia.org/w/index.php?title=Special:Preferences&vectornightmode=1