I177dad88 introduced the skin version user preference field and
associated configuration values. Per T242381, the field is to presented
as a checkbox with the implied storage type of a boolean where a string
is needed. A PreferencesFormPreSave hook handler was added to adapt
values of either data type to the other. While this was a neat solution
to a minor nit, the adapter's implementation is incompatible with the
GlobalPreferences extension as the PreferencesFormPreSave hook isn't run
whilst saving global preferences.
Rather than adding an equivalent hook to the GlobalPreferences
extension, create a custom field based on a checkbox with the adapter
included. This allows us to:
- Separate the business logic concerned with preserving the user's
VectorSkinVersion preference if they've simply disabled Vector from
the adapter
- Simplify the adapter's implementation
- Forego adding hooks to the GlobalPreferences codebase
Additional changes:
- Replace repeated string literals with equivalent constants in
tests/phpunit/integration/VectorHooksTest.php
Bug: T258493
Change-Id: I628435a4ad676f55534191b8c10147be28be5d73
This allows us easily to identify in templates what messages are
used and where, as well as allow us an easy way to tell when
messages are no longer being used.
Change-Id: I610224d551ebea54ae32e9e79901befe80cfd5ce
Carved out from I8e6e283db5d4034861f8d50d9b3f211df1a78c6c.
It makes sense to have a variable defined for that value.
Change-Id: Iaaca1fd7c15a0c121e60b5ae6debf4bf6920168e
I overlooked the horizontal padding on the page container. This needs to be
included in the decision on whether to make the header 2 lines on 1.
Bug: T249363
Change-Id: I4fabac7d57e37db87d2363073317109f582de883
This hook is run on every page. The SkinTemplateNavigation hook
counter intutively is run only on pages which can exist. I think
it's clearer if we only use SkinTemplateNavigation::Universal hook
and keep the logic for when it runs inside our own code.
Bug: T255319
Change-Id: I0835074a6cadf6e9bdcc45299de37dd9328bf9b2
Following up I6bc4cf541eefd00e2e42 we also need to remove the
linear-gradient hack that only made sense in combination with the
now gone PNG fallback background-image.
Change-Id: I0e7ed0451884a6bd612cb1082555338a26129e2d
These are no longer needed. The classes remain where necessary for
gadgets but the CSS rules no longer need to apply to them.
Change-Id: I18afa15ddab75128463dc83c916e11436db0575a
The calculations were a little incorrect as I failed to consider the
sidebar button correctly and how the search's min width and max width
impact layout.
I also move rules from Sidebar.less regarding the placement of the button
into layout where I believe they belong. We do not have a header component, so the
positioning (margin) of the sidebar button in current form should be here.
This can be revisited if we introduce a header component.
Bug: T249363
Change-Id: I4ff640380eafc8beedb2c3c8fb00a56c71c5cb45
The feature manager abstracts away how a feature is enabled from the
consumer of that feature. Accordingly, replace direct instantiation of
SkinVersionLookup with usage of the Vector.FeatureManager service.
Supporting changes:
- Add Vector\VectorServices, a simple wrapper around
MediaWiki\MediaWikiServices that allows us to both document and
type-hint services specific to Vector
- Add Vector\Hooks::isSkinVersionLegacy to minimise repetition
Additional changes:
- Make the MakeGlobalVariablesScript hook handler return early if the
user isn't using the Vector skin like the other hook handlers
Bug: T256100
Change-Id: I93b5ef39802323c7ac658af8fa7cc312fff68aa7
The width comfortable should consider the max-width of the search
not the min-width.
This fixes the bug documented in T249363#6391041
Bug: T249363
Change-Id: I3e216a3705730092f88d1dcbb5193e411945a083
As part of moving search into header work, a min-width (via
@min-width-supported variable) was introduced on the body and takes
effect when the search feature is enabled.
However, given a min-width already exists on the page container from the
max-width work, I'm wondering if it makes sense to replace that one with
the @min-width-supported variable as it seems like we should only have
one min-width vs. having two.
Note: As a bonus, this has the (unintended but helpful) side-effect of
mitigating the sidebar button being blocked by the personal menu at
small viewport widths (T258465).
[1] I7f8059d43eaab49de362405784b34a4fe502c7b0
Bug: T258465
Change-Id: I920cd0e9d1564c82bcdc89b721352620158073c6
The wgVectorDisableSidebarPersistence config variable is only required
when the user is logged in. Don't send it to the client when the user is
logged out.
Bug: T255727
Change-Id: I27eda8c18b438ef3251b2c07a0ed8b0cef6cae64
* Remove the PNG fallbacks for chevronHorizontal-….svg and menu.svg.
As of T248061, these are no longer needed.
* Added the one line of trivial CSS directly to skins.vector.styles
instead of through its own module.
This helps recovers the module cost of vue module deployed this
week (from Ib6c8f890fb3d6e7), which is currently empty and unused.
With T253582, we'll be able to recover a lot more budget in
this area.
Bug: T258766
Change-Id: I6bc4cf541eefd00e2e428f918664a26da331c1a9
To support roll out and avoid issues with cached HTML the new
styles for the new search feature are restricted to HTML where
the body tag has `skin-vector-search-header` class.
For legacy mode, we introduce a new class
`skin-vector-search-header-legacy` and temporarily use a CSS3 `:not()`
selector to ensure the styles ship during the phase where cached
HTML can be served. While this will create some display issues in
browsers that do not support CSS3 selectors, all grade A browsers in
our compatability matrix support this.
Bug: T249363
Change-Id: I7f8059d43eaab49de362405784b34a4fe502c7b0
Keep variables concerned with layout in the master file but pull out
the default layout into a separate file.
Change-Id: I4acc2937f8e8a76274a3ffb76e3729dc89ce1ad7
Following on from I9445d5c, align the @package annotations in
the Vector\FeatureManagement namespace and subnamespaces.
Bug: T248399
Change-Id: Icd287a52d149123bca5d9f0c55154f932f55148e
