* Using the new ConfigHelper, support disabling night mode on certain
pages via configuration options
* In addition, adds test coverage for this case and the query parameter
case (in a new integration test file as we now require accessing the
service container for request context)
* Finally, supply a default configuration in skin.json with all the
values set to null
For the easiest possible approach while we evaulate our general feature
management system, this logic is handled inside of getFeatureBodyClass
using the new shouldDisable general function. In the future, it may
make sense to break this out into its own requirement class, but for now
that feels premature
Bug: T359606
Change-Id: I3e7a4720ec3cc2afd9777e36f59aa56b682258f0
This is a common need for features, and having these use a standardized
class name will make using them a lot easier.
Change-Id: I0e16c26878e7d4399d2bf57f236523d214951a27
- `MediaWiki\Skins\Vector\Tests` is now the prefix for all tests in the skin
- we followed PSR conventions of following folder structure after the prefix
- Optimize imports/use order
- update namespace in skin.json
Bug: T303102
Change-Id: Ib76374d81d973c83adfd6c8e7863ff6d797e655d
FeatureManager::registerRequirement registering an instance of
SimpleRequirement with ::registerComplexRequirement was awkward.
Changes:
* Rename FeatureManager::registerRequirement to
::registerSimpleRequirement, which is exactly what it does!
* Rename FeatureManager::registerComplexRequirement to
::registerRequirement
Bug: T244481
Change-Id: I612af959cee4cdcd0bdcda51a81b86ed61ee2e16
FeatureManager::registerRequirement established the interface for a
requirement: its name and whether it's met.
However, the Feature Manager also needs to handle scenarios where a
requirement needs additional context before it can be considered met.
That context may not be available when the application is booting, e.g.
checking if the user is logged in; or the logic is complicated enough
that it should be under test.
Changes:
- Add the Requirement interface and update FeatureManager to work with
implementations of it
- Maintain B/C by constructing an instance of a the SimpleRequirement
DTO
Bug: T244481
Change-Id: Id95d9e5d7125492968d0e15515224aadbc3075f8
I735fd640 bumped the required MediaWiki version to 1.31. That version
dropped support for PHP 5.x.
Wherever possible, update FeatureManager's methods to use PHP 7.0.x's
scalar and return type declarations.
Bug: T244481
Change-Id: Ib5636d0ec5ec7f0c93b5b3317a12635668b589e2
As was noted in https://phabricator.wikimedia.org/T244481#5859513, the
term "set" doesn't seem natural. Piotr Miazga (polishdeveloper, pmiazga)
and Nicholas Ray (nray) suggested a number of good replacements,
including "requirement." Serendipitously, this term is already used in
FeatureManager's documentation.
Bug: T244481
Change-Id: I559c2d4149db69235cdd4bb880697deb1a145743
With complex additions to Vector's codebase like the Desktop Improvement
Program upcoming, it's important that we have a shared, intuitive
language to talk about features and their requirements. Centralising
the registration of features and creating an API satisfies does exactly
this.
This change introduces a greatly-reduced version of Piotr Miazga's
(polishdeveloper, pmiazga) original proposed API and associated
scaffolding classes for feature management in Vector, which itself was
based upon his work in MobileFrontend/MinervaNeue. This is done to
establish a foundation upon which we can build the more sophisticated
parts of Piotr's proposal in a piecemeal basis, thereby minimising risk.
Distinct from Piotr's proposed API is the ability to register sets and
features that are always enabled or disabled.
Additionally:
- A Vector.FeatureManager service is registered but not used
- A list of proposed immediate next steps is included
Bug: T244481
Change-Id: Ie53c41d479eaf15559d5bb00f269774760360bde
