Background

To implement T359606 we need to duplicate PHP code in Minerva inside the Vector skin. This is the first time we have encountered this problem, and we decided it was important to pause and think carefully about how to do this for resolving this issue, but also to provide clarity in future work.

The code in question provides a specific type of configuration which allows us to make decisions about pages on a per request basis. For example: we might want to only limit code to certain pages e.g. diff page/main page.

We currently have this code pattern in several places. For example we:

• Allow page previews to be disabled on certain pages using $wgPopupsPageDisabled
• Allow certain pages in Vector to opt-out of the limited width feature: using $VectorMaxWidthOptions
• Allow certain pages in Minerva to opt out of night mode using $wgMinervaNightModeOptions
• Flagged Revisions can be limited to certain namespaces via wgFlaggedRevsNamespaces

The three options to be considered are:

• Duplicating the code and maintaining 2 identical sets of code
• Sharing code via composer plugin
• Sharing code via MediaWiki core.

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.

TODO

• Identify the three options and pros and cons of each
• Write a draft ADR with status "in progress" defining the outcome of the spike.

Mo's analysis

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.

1. 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.
2. 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.
3. 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.