Now `wvui` is in core, there is no need for this to be conditional.
Depends-On: I91db16946e7ea46f69a6b57b116962f77ce3cd20
Change-Id: Icceaefc63d227ca772a986ad2c6ce28cbdb0a7d6
Vector has a wgVectorResponsive flag. This adds a ResourceLoader
module as well
I propose the configuration is repurposed to disable the min-width
on Vector and enable the viewport tag. This will allow us to use
test.wikipedia.org to test Vector at lower resolutions in future
as well as provide a suitable option for 3rd parties wanting to run
a responsive version of Vector that can be opted into using:
```
$wgVectorResponsive = true;
$wgVectorDefaultSkinVersion = '2';
```
As part of this change, the default skin version is set to 2, in
preparation for the next MediaWiki release. Note on Wikimedia wikis we
explicitly set this version so this will not impact any of our deployed
wikis.
Bug: T242772
Change-Id: I878920f49d18c5d60efd3ac45dc7912d2c62086e
FeatureManager allows the logic to be centralized and allows clients to
ask about its state. For instance, SkinVector will make use of it in
I70277c1082a504fbd5f6023e9873e8071de7e35d.
Also:
* Adds WvuiSearchTreatmentRequirementTest to test A/B logic
WvuiSearchTreatmentRequirement/Test logic are adapted from
I878239a85ffbecb5e78d73aed5568c56dbd7d659.
Bug: T270202
Change-Id: Ia02349a7b41c7caf26fbd728e0be7d47488b97e5
If the VectorSearchTreatmentABTest config variable is truthy and the
user is loged in, then pick the Core treatment (defined in the
mediawiki.searchSuggest RL module) or Vector's Vue.js-based treatment of
the search widget based on their user ID. If not, then fall back to
picking the treatment based on VectorUseWvuiSearch.
Supporting changes:
* Update initSearchLoader() in skins.vector.js/searchLoader.js to check
whether the body.skin-vector-search-vue exists
* Remove wgVectorUseWvuiSearch from the skins.vector.js RL module's config
* Update the performance-related metrics collection to check which
module is being loaded rather that use the above
Bug: T261647
Change-Id: Idc978392f5db14f0ae2b06ade0175fe534f4ae70
This allows better compatibility with FeatureManager (e.g. can use
requirements such as REQUIREMENT_LATEST_SKIN_VERSION). It will become
especially useful in I70277c1082a504fbd5f6023e9873e8071de7e35d and when
A/B testing search.
Bug: T270202
Change-Id: I3a063e0b085765ea1db3c4478fb30c11b0942b75
Add event listeners and associated helpers to emit SearchSatisfaction
events via the `mediawiki.searchSuggest` protocol.
Bug: T257698
Change-Id: Ica040cd18d6c4bf8a1b1f607bb4647c7e8eb7108
By default the API uses location.host as the host, however during
development it is useful to test against production wikis
For example to test against English Wikipedia:
$wgVectorSearchHost = 'en.wikipedia.org';
Note: Links when clicked will not take the user to the target page, and
instead will take the user to the search results page with a link to
create the page.
The following config can be used to workaround that page:
$wgDisableTextSearch = true;
$wgSearchForwardUrl = "/w/index.php?title=$1";
Change-Id: I5fbac7f54844d7a9d6976007bc0d0ff9938b9f2b
These are no longer referenced in the code and artifacts of a time
when these were feature flagged.
Change-Id: Ia850ac9fb92033d82a333836ba7ff32312f042a7
Uses ResourceLoader's virtual config feature to get the config and pass
it down to Wvui's typeahead search component.
Disclaimer: I'm a typescript noob and am not sure if the
config.json.d.ts is correct although it seems to make tsc happy.
Bug: T260167
Change-Id: I2eced14c7df3b795b4de0e5149c2ca9fd598c7be
Creates a new skins.vector.search module that
replaces the searchSuggest module from MediaWiki core.
This module creates a new Vue app using the WVUI
search widget for the new search experience.
The legacy search input form is still retains on pageload,
and the new search kicks on search input focus.
In order to manage that transition, the legacy search
input is styled to resemble the new WVUI input, and the
new input is manually focused after the component mounts.
Vue is also added as a dev-dependency to help with
type-checking.
Other changes:
* the entry in skin.json is reordered alphabetically after
skins.vector.js
Bug: T264355
Change-Id: Ibb9561a77a14734297cb4d0ddcd415fc0750b45d
This will allow us to add the A/B testing requirement for logged in
users.
In preparation for the new A/B test requirement, a custom requirement
is added as the feature management system does not
support OR operations and the desired effect is the case where:
* the SearchInHeader feature flag has been enabled
* OR the SearchInHeaderABTest feature flag has been enabled and the user is bucketed
Bug: T259250
Change-Id: If948603bd598e1b5597345f4268736417f4c3a24
Drop max width feature flag.
Max-width will continue to not apply on special pages.
This saves us development effort by not needing to worry about
the case where the flag is not enabled. This flag is not false
in any production wikis.
Change-Id: I7ace4046e6b93ce63dd804da32e576a709485bfb
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 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
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 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
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
Add onSkinPageReadyConfig hook that overrides module after page loaded
The new module is currently empty pending further work in the
feature branch.
Depends-On: I0dc38e74052027f26a70d58b5f520e5830e0d55d
Bug: T257706
Change-Id: Ib6c8f890fb3d6e751f5f01a6576614b9cc9b440c
Hooks are global, unlike the old Skin addToBodyAttributes() method, which was per-skin.
Follow-up to a04fc71f30
Change-Id: Ic8a581256c4775ba45b2c5188d678751ba9c7023
Please note I7e06a4cc226f3434c0f655212a464b8b98bcc7f4 should be
merged at the same time as this patch.
== The background ==
All extensions have been weaned of BaseTemplate hooks in
Wikimedia projects.
This change now means that Vector will no longer run
any BaseTemplate hooks. See the epic T253809 for the
implementation details.
== The change ==
BaseTemplate will now have nothing to do with the rendering of
Vector. The skin version is added to express the significance of
breaking compatibility with 3rd party extensions.
We TEMPORARILY remove SkinVector to retain git blame. SkinTemplateVector will
be renamed SkinVector in the follow up (see 2/2)
Update skin.json to use SkinTemplateVector for the skin (this will be fixed
in a follow up).
The isLegacy method is moved to SkinTemplateVector.
Changes of note:
* html-debuglog is no longer needed. SkinMustache includes this information on
the skins behalf
* html-printtail and html-headelement are now not needed in the master template
and added by SkinMustache
* Skin::getAfterPortlet does not provide the `after-portlet` wrapping element provided
by BaseTemplate::getAfterPortlet so this is added
* SkinTemplate::getFooterIcons does not support the options that BaseTemplate::getFooterIcons
does so any icons which do not have an image must be manually checked for and unset
Known changes to HTML output as a result of intentionally
delegating their output to the core SkinMustache class:
* A new line is removed between the body element and #mw-page-base
* #mw-html-debug-log now appears at the end of the body element
* #printfooter is now a child of #mw-content-text rather than sibling.
Bug: T251212
Change-Id: I4e89beb96f6401ed7e51bafdf0aac408f5a2c42f
- Creates a new user-preference called 'VectorSidebarVisible'
which stores the sidebar hidden/collapsed state for logged-in
users.
- Updates that user-preference on the client whenever the sidebar
is expanded or collapsed.
- Refactors the sidebar related javascript into a separate file.
Bug: T255727
Change-Id: Ib1ce934f3646cd8feebf0d3b15c38b5b969ec957
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
Move the body of enableResponsiveMode method into the onBeforePageDisplayMobile hook.
Replace BeforePageDisplayMobile hook with BeforePageDisplay hook.
Bug: T254378
Change-Id: I63da1b67bf2b85c644e4af196bf894efc4797433
This means dropping usage of Skin::addToBodyAttributes method
from Skin to pave way for its deprecation/removal.
The parent method is no-op, so this will not create duplicate with
the hook
Bug: T255698
Change-Id: Ieeccdd9ec3fdb3e3fc1a3016cfa87e0b8364aa3a
Use SkinTemplateNavigation hook instead and copy the collapsible
behavior to the menu function
The code inside getSkinData that checks VectorUseIconWatch is
redundant as it duplicates checks already inside
SkinTemplate::buildContentNavigationUrls
It is enough to simplify check whether watch or unwatch is
present in the array.
Bug: T251212
Change-Id: If6b10b0ddcbd4b21dd13a2813e60b604c3a23415
de76ab5 added the config,
`$wgVectorDefaultSkinVersionForExistingAccounts`. Its usage in
`Hooks::onUserGetDefaultOptions()` was invoked not only for existing
accounts but anonymous users _as well._ This is a bug, due to my own
misconceptions about the hook, that went against both the config's name
and its documentation.
Unfortunately, user sessions are unavailable in
`Hooks::onUserGetDefaultOptions()` so it does not seem to be possible to
determine whether the active user is an anonymous or existing account.
This patch drops the hook and centralizes all version determination
logic in SkinVersionLookup::getVersion(). SkinVersionLookup requires a
the active User object and can make the anonymous / existing account
determination by checking login state.
The issued was identified while responding to review feedback given by
@polishdeveloper / @pmiazga in
I52d80942b4270c008d4e45050589ed9220255a50.
Bug: T251415
Change-Id: I7982b4c34283ba81d0232ee6f501c44cf0a74b98
Sections can be nested. Using rendering/skin as the parent
means that Vector's skin preference will always come straight
after the skin preference and before Popups.
A change in core is needed to update the selector for the element which
shows/hides the subsection as well as provide a generic message key to
replace the one inside this repository.
Note: If the "Vector" specific heading is needed, we can achieve this
with a little more work but that is a conversation for another time.
Depends-On: Idd06bcfe7935e16732a6a95c1253dbf95c8aca2e
Bug: T246162
Change-Id: I4be9764ddca186e5bfd493678afd62d446072e8f
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
