VectorGOLEM/includes/Constants.php

117 lines
2.6 KiB
PHP
Raw Normal View History

[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
<?php
namespace Vector;
use FatalError;
/**
* A namespace for Vector constants for internal Vector usage only. **Do not rely on this file as an
* API as it may change without warning at any time.**
*/
final class Constants {
/**
* This is tightly coupled to the ConfigRegistry field in skin.json.
* @var string
*/
public const SKIN_NAME = 'vector';
// These are tightly coupled to PREF_KEY_SKIN_VERSION and skin.json's configs. See skin.json for
// documentation.
/**
* @var string
*/
public const SKIN_VERSION_LEGACY = '1';
/**
* @var string
*/
public const SKIN_VERSION_LATEST = '2';
/**
* @var string
*/
public const SERVICE_CONFIG = 'Vector.Config';
/**
* @var string
*/
public const SERVICE_FEATURE_MANAGER = 'Vector.FeatureManager';
// These are tightly coupled to skin.json's config.
/**
* @var string
*/
public const CONFIG_KEY_SHOW_SKIN_PREFERENCES = 'VectorShowSkinPreferences';
/**
* @var string
*/
public const CONFIG_KEY_DEFAULT_SKIN_VERSION = 'VectorDefaultSkinVersion';
/**
* @var string
*/
public const CONFIG_KEY_DEFAULT_SKIN_VERSION_FOR_EXISTING_ACCOUNTS =
'VectorDefaultSkinVersionForExistingAccounts';
/**
* @var string
*/
public const CONFIG_KEY_DEFAULT_SKIN_VERSION_FOR_NEW_ACCOUNTS =
'VectorDefaultSkinVersionForNewAccounts';
/**
* @var string
*/
public const CONFIG_KEY_DEFAULT_SIDEBAR_VISIBLE_FOR_AUTHORISED_USER =
'VectorDefaultSidebarVisibleForAuthorisedUser';
/**
* @var string
*/
public const CONFIG_KEY_DEFAULT_SIDEBAR_VISIBLE_FOR_ANONYMOUS_USER =
'VectorDefaultSidebarVisibleForAnonymousUser';
Implement Page, Workspace, Content, and Article Toolbar Containers This patch closely follows the desired guidelines/desired styles Alex Hollender has put forth in his prototype, but uses multiple containers to achieve this look since our DOM order/structure is different than the DOM structure in the prototype. The following containers are used, but unlike his prototype, they are sometimes used more than once: * Page Container: Contains every other container and limits the overall max-width of the white part of the page. * Workspace Container: Contains the sidebar and content container. The sidebar is displaced ~30 pixels to the start (left) of the workspace container at all times. * Content Container: Contains the content. The max-width of this changes depending on whether you are on a special page/history page vs. other pages. * Article Toolbar Container: Contains the article toolbar. The max-width of this is always the same as the max-width of the article content as we don't want the toolbar to move when going from the article page to the history/special page. Changes to be aware: * To test locally, `$wgVectorLayoutMaxWidth = true;`. This design is temporarily feature flagged and defaults to being "off". * Note that layout-max-width.less is a temporary file made to meet the feature flag requirement of T246420 (intended to derisk the deployment). After the deploy, we should merge most if not all of the rules into layout.less where the max-width design will become the default. * Per Jon's code review comment, I have relaxed the indenting of skin.mustache to make the diff easier to reason about. If desired, the correct indenting can be achieved in a (much less risky) follow-up commit. Bug: T246420 Bug: T153043 Change-Id: Ie49f629bc705850c6996164a516957476c034048
2020-06-23 18:02:32 +00:00
/**
* @var string
*/
public const CONFIG_KEY_LAYOUT_MAX_WIDTH = 'VectorLayoutMaxWidth';
[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
/**
* @var string
*/
public const PREF_KEY_SKIN_VERSION = 'VectorSkinVersion';
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
// These are used in the Feature Management System.
/**
* Also known as `$wgFullyInitialised`. Set to true in core/includes/Setup.php.
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
* @var string
*/
public const CONFIG_KEY_FULLY_INITIALISED = 'FullyInitialised';
/**
* @var string
*/
public const REQUIREMENT_FULLY_INITIALISED = 'FullyInitialised';
/**
* @var string
*/
public const REQUIREMENT_LATEST_SKIN_VERSION = 'LatestSkinVersion';
/**
* @var string
*/
public const FEATURE_LATEST_SKIN = 'LatestSkin';
// These are used for query parameters.
/**
* Override the skin version user preference and site Config. See readme.
* @var string
*/
public const QUERY_PARAM_SKIN_VERSION = 'useskinversion';
[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
/**
* This class is for namespacing constants only. Forbid construction.
* @throws FatalError
*/
private function __construct() {
throw new FatalError( "Cannot construct a utility class." );
}
}