An error in both of these modules. This module is additive (it doesn't
replace the existing user module) so only needs to add new pages, not
append to existing pages.
Bug: T300070
Change-Id: I3ba2ce82ba924972d0f9fea763328510aef41f8e
Working correctly. No longer needed.
Additional change:
* add tooltip to menu
Depends-On: I418ce75bda8015520d1f1742ddcdfefbc8b9a162
Bug: T289619
Change-Id: I42f21ca8836e5042d07102e1516ca386478dfabc
While editing I was seeing a fatal due to this error being null
Err on side of caution and check for existence of menu
Follow up to I8309492881142d47eec4da5cc4aa5c6febbd1b35
Bug: T289619
Bug: T299352
Change-Id: I62562969a00eb96c83af4519e0e34e4a77ed8b19
Field name without 'wp' prefix (which is used as the key in html descriptor) is required.
After I58f9df384df8ecc5ebae8cac68ec2251351bc984, values of fields that are supposed to be disabled would be loaded from default, use a miss-matched field name would be treated as disabled.
It works in UI now, but it's not a good idea to strip the 'wp' prefix on the server-side.
Bug: T298819
Change-Id: If98368ad400986afaef3187867f201044ebf0efb
For vector-2022 skin:
* MediaWiki:Vector.css and MediaWiki:Vector.js are added via the
existing ResourceLoader hook.
* User:<name>/vector.js and User:<name>/vector.css are added via new
VectorResourceLoader modules
Bug: T297758
Change-Id: I37e9a9d353695502213c7a651530995252d9505f
A new vector-2022 skin is added. This will be the eventual home
of the new Vector skin when we are ready to migrate.
Please see SkinVector class for the migration plan to simulate this
as part of testing.
Bug: T291098
Change-Id: Ibaddf94a5bfb5e21bbbaf1e0aa1b343a3f566d2d
In preparation for I30c670e3f195f77a27715c6b494a3088b7a55712, refactor
the search component expand behavior so that it can accomodate the new
changes in WVUI while maintaining backwards compatibility with the
status quo.
Additionally, pass/enable the `auto-expand-width` prop to the main
header's search. This will be inert until the new changes in WVUI have
landed.
Bug: T297531
Change-Id: Id8d3bd4aa74113b91ecaf66cb58cf5625db8a302
This will currently remove table of contents in article body
for legacy and modern skin.
To prevent us deploying this in current form, a check is
added in generateHTML
This requires an adjustment of OverridableConfigRequirement to
support requirements which do not vary on whether the user is
logged in or not.
Bug: T297610
Change-Id: I847a284229e498b3aa04c16ea3f84c360e735052
The existence of this code means we can't safely use this service
inside the skin's constructor.
We no longer need this, so that's fine.
Change-Id: Iffd82c00030c4cf1238a931dc971ffb4686d2620
The H1 is available with the correct attributes in core now, so
we can use that instead of our own markup. This also means Vector
will benefit from updates to the heading in core such as main page
special handling.
Bug: T297728
Change-Id: I4d10370678fad6455d73994bf340891760543b71
The generation of JavaScript will throw a RuntimeException
making it obvious when an invalid A/B test has been setup.
Bug: T297662
Change-Id: I75b0e923463bf52f8fc5b5c6b7f9baf586053154
In Commons languages appear in sidebar.
The language button shouldn't show in the sticky header on these wikis
Bug: T297362
Change-Id: I17d283a7c0ad20bdcaf39b234a7fe766880ab28a
Follow up to 9dcfc1f
This simplifies the template by removing the need for the html-class.
The font-size can be provided to the entire content area meaning we don't
need the link-only class
Change-Id: Id5c49358f6ec007b3205ee390cf68334a1e56de5
Per the ticket, when this flag is enabled (and the
VectorLanguageInHeader config is enabled) we want to move the language
button from the bottom of the main page to beside the main page's title.
This config can be toggled with the `languageinmainpageheader` query
param (e.g. `?languageinmainpageheader=1`).
Bug: T293470
Change-Id: I41b4677f80b939810d16907b508ab29936f8629c
Remove using of User:getOption since this method
will be hard-deprecated. Now it is soft-deprecated.
Bug: T296083
Change-Id: I3194a9c1c5c70592f88bc4dbedc78846d1141768
After I628435a4a, we were asserting a boolean was given because we're
extending HTMLFormField which requires a boolean value. This was safe
because GlobalPrefs would provide a boolean, but that changed with
I594f6297.
We could rework GlobalPrefs once again to ensure only a boolean is
passed in, but since HTMLLegacySkinVersionField already has special
handling around the data types, it seems to make sense to contain the
type transformation in this class.
Simply removing the Assertion is enough to prevent T296068, however
depending on when the global preference was saved (such as since MW
1.38.0-wmf.9 but before wmf.10), it's possible either a bool or a string
was saved, hence we check for both to ensure correct display.
Bug: T296068
Change-Id: If10b948617d2bb8346475f207fe425fb768cb987
