mediawiki-skins-Vector/includes/ServiceWiring.php

246 lines
6.9 KiB
PHP
Raw Normal View History

<?php
/**
* Service Wirings for Vector skin
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
* http://www.gnu.org/copyleft/gpl.html
*
* @file
* @since 1.35
*/
use MediaWiki\MediaWikiServices;
[Special:Preferences] [PHP] Add skin version user preference and configs Add a Vector-specific user preference to Special:Preferences for toggling skin version, either Legacy Vector or the latest Vector. The presentation of the new preference section and the default values for anonymous, new, and existing accounts are configurable via $wgVectorShowSkinPreferences, $wgVectorDefaultSkinVersion (to be used by the feature manager in T244481), $wgVectorDefaultSkinVersionForExistingAccounts, and $wgVectorDefaultSkinVersionForNewAccounts. These configurations default to the fullest experience so that third-party configuration is minimal. See skin.json for details. The configurations are each tested in VectorHooksTest.php. When presentation is enabled, the new preference appears as a checkbox; enabled is Legacy mode and disable is latest. There are a number of unfortunate details: - Showing and hiding a checkbox is supported by OOUI. Showing and hiding a whole section (Vector skin preferences, in this case) is not so this additional client JavaScript functionality is added in Core (see Iaf68b238a8ac7a4fb22b9ef5d6c5a3394ee2e377). - Stylization as a checkbox is wanted. However, the implied storage type for OOUI checkboxes is a boolean. This is not wanted in the event that another skin version is added (e.g., '3' or 'alpha'). As a workaround, the preference is converted from a boolean to a version string ('1' or '2') on save in Hooks::onPreferencesFormPreSave() and from a version string to a checkbox enable / disable string ('1' or '0') in onGetPreferences(). There a number of test cases to help cover these concerning details. Documentation for overriding the skin version as a URL query parameter is provided in anticipation of T244481. Bug: T242381 Bug: T245793 Depends-On: Iaf68b238a8ac7a4fb22b9ef5d6c5a3394ee2e377 Depends-On: Ifc2863fca9cd9efd11ac30c780420e8d89e8cb22 Change-Id: I177dad88fc982170641059b6a4f53fbb38eefad6
2020-01-23 21:53:09 +00:00
use Vector\Constants;
use Vector\FeatureManagement\FeatureManager;
featureManager: Add DynamicConfigRequirement requirement 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
2020-03-13 17:22:59 +00:00
use Vector\FeatureManagement\Requirements\DynamicConfigRequirement;
use Vector\FeatureManagement\Requirements\OverridableConfigRequirement;
return [
Constants::SERVICE_FEATURE_MANAGER => static function ( MediaWikiServices $services ) {
featureManager: Add DynamicConfigRequirement requirement 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
2020-03-13 17:22:59 +00:00
$featureManager = new FeatureManager();
$featureManager->registerRequirement(
new DynamicConfigRequirement(
$services->getMainConfig(),
Constants::CONFIG_KEY_FULLY_INITIALISED,
Constants::REQUIREMENT_FULLY_INITIALISED
)
);
featureManager: Add DynamicConfigRequirement requirement 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
2020-03-13 17:22:59 +00:00
$context = RequestContext::getMain();
// Feature: Languages in sidebar
// ================================
$featureManager->registerRequirement(
new OverridableConfigRequirement(
$services->getMainConfig(),
$context->getUser(),
$context->getRequest(),
$services->getCentralIdLookupFactory()->getNonLocalLookup(),
Constants::CONFIG_KEY_LANGUAGE_IN_HEADER,
Constants::REQUIREMENT_LANGUAGE_IN_HEADER,
Constants::QUERY_PARAM_LANGUAGE_IN_HEADER,
Constants::CONFIG_LANGUAGE_IN_HEADER_TREATMENT_AB_TEST
)
);
// ---
// Temporary T286932 - remove after languages A/B test is finished.
$requirementName = 'T286932';
// MultiConfig checks each config in turn, allowing us to override the main config for specific keys. In this
// case, override the "VectorLanguageInHeaderABTest" configuration value so that the following requirement
// always buckets the user as if the language treatment A/B test were running.
$config = new MultiConfig( [
new HashConfig( [
Constants::CONFIG_LANGUAGE_IN_HEADER_TREATMENT_AB_TEST => true,
] ),
$services->getMainConfig(),
] );
$featureManager->registerRequirement(
new OverridableConfigRequirement(
$config,
$context->getUser(),
$context->getRequest(),
$services->getCentralIdLookupFactory()->getNonLocalLookup(),
Constants::CONFIG_KEY_LANGUAGE_IN_HEADER,
$requirementName,
/* $overrideName = */ '',
Constants::CONFIG_LANGUAGE_IN_HEADER_TREATMENT_AB_TEST
)
);
// ---
$featureManager->registerFeature(
Constants::FEATURE_LANGUAGE_IN_HEADER,
[
Constants::REQUIREMENT_FULLY_INITIALISED,
Constants::REQUIREMENT_LANGUAGE_IN_HEADER,
]
);
// Feature: T293470: Language in main page header
// ================================
$featureManager->registerRequirement(
new OverridableConfigRequirement(
$services->getMainConfig(),
$context->getUser(),
$context->getRequest(),
null,
Constants::CONFIG_LANGUAGE_IN_MAIN_PAGE_HEADER,
Constants::REQUIREMENT_LANGUAGE_IN_MAIN_PAGE_HEADER,
Constants::QUERY_PARAM_LANGUAGE_IN_MAIN_PAGE_HEADER,
null
)
);
$featureManager->registerSimpleRequirement(
Constants::REQUIREMENT_IS_MAIN_PAGE,
$context->getTitle() ? $context->getTitle()->isMainPage() : false
);
$featureManager->registerFeature(
Constants::FEATURE_LANGUAGE_IN_MAIN_PAGE_HEADER,
[
Constants::REQUIREMENT_FULLY_INITIALISED,
Constants::REQUIREMENT_IS_MAIN_PAGE,
Constants::REQUIREMENT_LANGUAGE_IN_HEADER,
Constants::REQUIREMENT_LANGUAGE_IN_MAIN_PAGE_HEADER
]
);
// Feature: T295555: Language switch alert in sidebar
// ================================
$featureManager->registerRequirement(
new OverridableConfigRequirement(
$services->getMainConfig(),
$context->getUser(),
$context->getRequest(),
null,
Constants::CONFIG_LANGUAGE_ALERT_IN_SIDEBAR,
Constants::REQUIREMENT_LANGUAGE_ALERT_IN_SIDEBAR,
Constants::QUERY_PARAM_LANGUAGE_ALERT_IN_SIDEBAR,
null
)
);
$featureManager->registerFeature(
Constants::FEATURE_LANGUAGE_ALERT_IN_SIDEBAR,
[
Constants::REQUIREMENT_FULLY_INITIALISED,
Constants::REQUIREMENT_LANGUAGE_IN_HEADER,
Constants::REQUIREMENT_LANGUAGE_ALERT_IN_SIDEBAR
]
);
// Feature: T297610: Table of Contents
// ================================
$featureManager->registerRequirement(
new OverridableConfigRequirement(
$services->getMainConfig(),
$context->getUser(),
$context->getRequest(),
null,
Constants::CONFIG_TABLE_OF_CONTENTS,
Constants::REQUIREMENT_TABLE_OF_CONTENTS,
Constants::QUERY_PARAM_TABLE_OF_CONTENTS,
null
)
);
$featureManager->registerFeature(
Constants::FEATURE_TABLE_OF_CONTENTS,
[
Constants::REQUIREMENT_FULLY_INITIALISED,
Constants::REQUIREMENT_TABLE_OF_CONTENTS
]
);
// Feature: Sticky header
// ================================
$featureManager->registerRequirement(
new OverridableConfigRequirement(
$services->getMainConfig(),
$context->getUser(),
$context->getRequest(),
null,
Constants::CONFIG_STICKY_HEADER,
Constants::REQUIREMENT_STICKY_HEADER,
Constants::QUERY_PARAM_STICKY_HEADER,
null
)
);
$featureManager->registerRequirement(
new OverridableConfigRequirement(
$services->getMainConfig(),
$context->getUser(),
$context->getRequest(),
null,
Constants::CONFIG_STICKY_HEADER_EDIT,
Constants::REQUIREMENT_STICKY_HEADER_EDIT,
Constants::QUERY_PARAM_STICKY_HEADER_EDIT,
null
)
);
$featureManager->registerFeature(
Constants::FEATURE_STICKY_HEADER,
[
Constants::REQUIREMENT_FULLY_INITIALISED,
Constants::REQUIREMENT_STICKY_HEADER
]
);
$featureManager->registerFeature(
Constants::FEATURE_STICKY_HEADER_EDIT,
[
Constants::REQUIREMENT_FULLY_INITIALISED,
Constants::REQUIREMENT_STICKY_HEADER,
Constants::REQUIREMENT_STICKY_HEADER_EDIT,
]
);
// Feature: Title above tabs
// ================================
$featureManager->registerRequirement(
new OverridableConfigRequirement(
$services->getMainConfig(),
$context->getUser(),
$context->getRequest(),
null,
Constants::CONFIG_TITLE_ABOVE_TABS,
Constants::REQUIREMENT_TITLE_ABOVE_TABS,
Constants::QUERY_PARAM_TITLE_ABOVE_TABS,
null
)
);
$featureManager->registerFeature(
Constants::FEATURE_TITLE_ABOVE_TABS,
[
Constants::REQUIREMENT_FULLY_INITIALISED,
Constants::REQUIREMENT_TITLE_ABOVE_TABS,
]
);
featureManager: Add DynamicConfigRequirement requirement 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
2020-03-13 17:22:59 +00:00
return $featureManager;
}
];