Change Details

== User story As a reader, I want pages that are unreadable in night mode to appear in day mode, so that all parts of the page are readable == Background In T355705 we created additional configuration for Minerva to allow us to disable certain pages in night mode. In this ticket we will seek to do the same in the Vector 2022 skin. # Requirements - [] It must be possible for us to share configuration between Minerva and Vector skins. For example the configuration in Vector 2022 should be identical to -Minerva. e.g. `$wgMinervaNightModeOptions = $wgVectorNightModeOptions` - [] We should minimize duplicated code. In future we may want to modify how this works, and do not want to maintain two versions of the same code. -- [] present the options to the team and the associated trade offs (google doc) -- []Facilitate discussion either async in the document or in person -- [] Collect a consensus about how we want to approach this. -- []Document decision in an decision record (ADR) in the patch. # QA steps NOTE: Ask a developer to setup a test instance for this one or disable the Banana page on the beta cluster. * Visit desktop site * Enable night mode. * Go to Banana page. Expected: The banana page appears in LIGHT mode. * Open the edit page in a new window (right click) * Click random Expected: the page appears in **night** mode. * Switch to the history page by clicking the last modified bar are the bottom of the article. Expected: The history page appears in LIGHT mode. * Click a diff. Expected: The diff page appears in LIGHT mode.

== User story As a reader, I want pages that are unreadable in night mode to appear in day mode, so that all parts of the page are readable == Background In T355705 we created additional configuration for Minerva to allow us to disable certain pages in night mode. In this ticket we will seek to do the same in the Vector 2022 skin. # Requirements - [] It must be possible for us to share configuration between Minerva and Vector skins. For example the configuration in Vector 2022 should be identical to -Minerva. e.g. `$wgMinervaNightModeOptions = $wgVectorNightModeOptions` - [] We should minimize duplicated code. In future we may want to modify how this works, and do not want to maintain two versions of the same code. -- [] present the options to the team and the associated trade offs (google doc) -- []Facilitate discussion either async in the document or in person -- [] Collect a consensus about how we want to approach this. -- []Document decision in an decision record (ADR) in the patch. # QA steps NOTE: Ask a developer to setup a test instance for this one or disable the Banana page on the beta cluster. * Visit desktop site * Enable night mode. * Go to Banana page. Expected: The banana page appears in LIGHT mode. * Open the edit page in a new window (right click) * Click random Expected: the page appears in **night** mode. * Switch to the history page by clicking the last modified bar are the bottom of the article. Expected: The history page appears in LIGHT mode. * Click a diff. Expected: The diff page appears in LIGHT mode. # Feedback In response to the feedback and the need for a refined approach to managing night mode settings across different skins, particularly between Minerva and Vector 2022, this amendment aims to enhance the clarity and direction of the development process, ensuring that the objectives are met efficiently and effectively. #### Code Duplication Minimisation: It is imperative to reduce code duplication to the greatest extent possible. Future modifications to night mode functionality should not necessitate parallel maintenance efforts. By streamlining the codebase, we aim to enhance maintainability and facilitate easier updates. # **Utilising a Composer Library for Shared Options:** This strategy involves creating or utilising an existing Composer library that contains the shared functionalities, making it accessible across different skins. * **Pros:** This method promotes code reuse and maintainability, ensuring that any updates or bug fixes are centralised, thus reducing the overhead in managing similar code across multiple skins. It could also enhance the consistency of features like night mode across different user interfaces. * **Cons:** However, this approach may introduce dependencies on external libraries, which could potentially affect the deployment process and require additional maintenance. It also necessitates a well-designed interface for the shared library to ensure it meets the diverse needs of each skin it supports. In addition to that it needs to wait for the security team queue which is a long one. # **Moving Code to Core MediaWiki:** This approach involves integrating the shared code directly into the core MediaWiki software. This also means it have to be generic and more adaptable tho things other than skins and probably be called ConfigDecisionEngine and will be a bigger refactor * **Pros: By moving the relevant code to the core, it ensures that the functionality is available globally across all skins and extensions, without the need for duplication. This can streamline the development process and facilitate easier updates and bug fixes. * **Cons:** On the downside, incorporating too much skin-specific functionality into the core can bloat the core codebase and potentially slow down the system. It also requires careful consideration to avoid introducing features that are too specialised for a general-purpose core. # **Duplicating Code in Skins:** This option means maintaining separate copies of the code for each skin that requires the functionality. * **Pros:** Code duplication allows for faster, skin-specific customisations without worrying about the impacts on other skins or the need for extensive testing across different environments. It provides a high degree of flexibility for skin developers. * **Cons:** The major drawback of this approach is the increased maintenance effort. Bugs fixed or improvements made in one skin's code need to be manually replicated across others, which is inefficient and error-prone. Over time, this can lead to inconsistencies and a fragmented user experience.

== User story As a reader, I want pages that are unreadable in night mode to appear in day mode, so that all parts of the page are readable == Background In T355705 we created additional configuration for Minerva to allow us to disable certain pages in night mode. In this ticket we will seek to do the same in the Vector 2022 skin. # Requirements - [] It must be possible for us to share configuration between Minerva and Vector skins. For example the configuration in Vector 2022 should be identical to -Minerva. e.g. `$wgMinervaNightModeOptions = $wgVectorNightModeOptions` - [] We should minimize duplicated code. In future we may want to modify how this works, and do not want to maintain two versions of the same code. -- [] present the options to the team and the associated trade offs (google doc) -- []Facilitate discussion either async in the document or in person -- [] Collect a consensus about how we want to approach this. -- []Document decision in an decision record (ADR) in the patch. # QA steps NOTE: Ask a developer to setup a test instance for this one or disable the Banana page on the beta cluster. * Visit desktop site * Enable night mode. * Go to Banana page. Expected: The banana page appears in LIGHT mode. * Open the edit page in a new window (right click) * Click random Expected: the page appears in **night** mode. * Switch to the history page by clicking the last modified bar are the bottom of the article. Expected: The history page appears in LIGHT mode. * Click a diff. Expected: The diff page appears in LIGHT mode. # Feedback In response to the feedback and the need for a refined approach to managing night mode settings across different skins, particularly between Minerva and Vector 2022, this amendment aims to enhance the clarity and direction of the development process, ensuring that the objectives are met efficiently and effectively. #### Code Duplication Minimisation: It is imperative to reduce code duplication to the greatest extent possible. Future modifications to night mode functionality should not necessitate parallel maintenance efforts. By streamlining the codebase, we aim to enhance maintainability and facilitate easier updates. # **Utilising a Composer Library for Shared Options:** This strategy involves creating or utilising an existing Composer library that contains the shared functionalities, making it accessible across different skins. * **Pros:** This method promotes code reuse and maintainability, ensuring that any updates or bug fixes are centralised, thus reducing the overhead in managing similar code across multiple skins. It could also enhance the consistency of features like night mode across different user interfaces. * **Cons:** However, this approach may introduce dependencies on external libraries, which could potentially affect the deployment process and require additional maintenance. It also necessitates a well-designed interface for the shared library to ensure it meets the diverse needs of each skin it supports. In addition to that it needs to wait for the security team queue which is a long one. # **Moving Code to Core MediaWiki:** This approach involves integrating the shared code directly into the core MediaWiki software. This also means it have to be generic and more adaptable tho things other than skins and probably be called ConfigDecisionEngine and will be a bigger refactor * **Pros: By moving the relevant code to the core, it ensures that the functionality is available globally across all skins and extensions, without the need for duplication. This can streamline the development process and facilitate easier updates and bug fixes. * **Cons:** On the downside, incorporating too much skin-specific functionality into the core can bloat the core codebase and potentially slow down the system. It also requires careful consideration to avoid introducing features that are too specialised for a general-purpose core. # **Duplicating Code in Skins:** This option means maintaining separate copies of the code for each skin that requires the functionality. * **Pros:** Code duplication allows for faster, skin-specific customisations without worrying about the impacts on other skins or the need for extensive testing across different environments. It provides a high degree of flexibility for skin developers. * **Cons:** The major drawback of this approach is the increased maintenance effort. Bugs fixed or improvements made in one skin's code need to be manually replicated across others, which is inefficient and error-prone. Over time, this can lead to inconsistencies and a fragmented user experience.