We expect the vast majority of requirements and features to be defined in services as possible. However, there are some "complex" requirements that require additional application/HTTP request state. Unfortunately, service wiring is done before some of that state is available. I65702426 attempted to work around this by requiring clients of the Feature Manager to pass that additional state on every interaction with the system. Those complex requirements would then select the parts of the state that they required when it was required. However implementations of \IContextSource are God objects and their use should be limited. Whilst reviewing I65702426, Stephen Niedzielski mentioned that the application state being available is a requirement. This remarkably simple solution: - Keeps the Requirement interface and FeatureManager API free of God objects; - Is true to the nature of the Feature Manager - it makes clear and centralizes the various checks for application state being available across the codebase; and - Inject a Requirement implementations' dependencies at construction time It just so happens that the $wgFullyInitialised variable flags whether the application state is available... Changes: - Add the the FeatureManager\Requirements\DynamicConfigRequirement class and tests. The DynamicConfigRequirement lazily evaluates a single configuration value whenever ::isMet is invoked - Register an DynamicConfigRequirement instance, configured to evaluate $wgFullyInitialised while constructing the Vector.FeatureManager service Bug: T244481 Change-Id: I7a2cdc2dfdf20d78e4548f07cf53994563b234b3 |
||
---|---|---|
.phan | ||
.storybook | ||
dev-scripts | ||
i18n | ||
includes | ||
resources | ||
screenshots | ||
skinStyles | ||
stories | ||
tests/phpunit | ||
.eslintignore | ||
.eslintrc.json | ||
.gitignore | ||
.gitreview | ||
.phpcs.xml | ||
.stylelintignore | ||
.stylelintrc.json | ||
.svgo.yml | ||
CODE_OF_CONDUCT.md | ||
COPYING | ||
Doxyfile | ||
README.md | ||
composer.json | ||
hooks.txt | ||
jsdoc.json | ||
package-lock.json | ||
package.json | ||
skin.json | ||
variables.less |
README.md
Vector Skin
Installation
See https://www.mediawiki.org/wiki/Skin:Vector.
Configuration options
See skin.json.
Development
Coding conventions
We strive for compliance with MediaWiki conventions:
https://www.mediawiki.org/wiki/Manual:Coding_conventions
Additions and deviations from those conventions that are more tailored to this project are noted at:
https://www.mediawiki.org/wiki/Reading/Web/Coding_conventions
URL query parameters
useskinversion
: Likeuseskin
but for overriding the Vector skin version user preference and configuration.
Skin preferences
Vector defines skin-specific user preferences. These are exposed on
Special:Preferences when the VectorShowSkinPreferences
configuration is
enabled. The user's preference state for skin preferences is used for skin
previews and any other operation unless specified otherwise.
Version
Vector defines a "version" preference to enable users who prefer the December
2019 version of Vector to continue to do so without any visible changes. This
version is called "Legacy Vector." The related preference defaults are
configurable via the configurations prefixed with VectorDefaultSkinVersion
.
Version preference and configuration may be overridden by the useskinversion
URL query parameter.