Changes:
- Add the LatestSkinVersionRequirement requirement class, which lazily
evaluates the application state to get the version of the skin for the
request.
This majority of this class is taken from Stephen Niedzielski's
Vector\SkinVersionLookup class, which was introduced in d1072d0fdf.
- Register an instance of LatestSkinVersionRequirement and register the
'LatestSkin' feature that requires that requirement
- Re-introduce SkinVector::isLegacy and make it defer to the Feature
Manager
Bug: T244481
Change-Id: If6b82a514aa5afce73e571abdd8de60b16a62fa8
To minimise reports from users with mismatched skins an MediaWiki and given the
pending changes anticipated by the updates to Vector, we will bump Vector's version.
This repo is not meant to have supported 1.31 in master for years
(since the REL1_31 branch point, which for this repo is f0327dc55 from 2018-04-17 yet very few
backports have been made to this repos REL1_31 branch.
This will massively reduce work for Wikimedia development teams;
we don't need to try to maintain backwards compatibility.
Change-Id: Ie4635fa0a7cbc2d115b2093bc5bc1a72a160afaf
Going into the new version of Vector, we'll want to rewrite the layout
rules entirely and decouple the sidebar from the logo.
To prepare for this we will move the layout file into a legacy folder.
We also separate Sidebar styles needed for the legacy mode from the old mode.
This will allow us to make changes to the header in new Vector without having to touch
or test the legacy codebase via a new file layout.less and using the existing sidebar
code.
Bug: T246170
Change-Id: Ieb4f8f2b2f0e4f48d76a210ab30acd08e3e83bcb
In new Vector, the logo will no longer be present, so we need a more
future proof way of determining what the first portal is.
A new class `portal-first` is added (no decision about adopting BEM
has been made yet).
Cached pages will continue to use the old selector for now.
Change-Id: I6ac4493bb1f63686b48ff0c22b18d50d9fffb51d
Amending Base10 to slightly darker `#202122` to fulfill WCAG
requirements in connection to Accent50.
Also sligthly adapting hover derivative to `#404244` and amending
corresponding opacity hover value.
Bug: T248393
Change-Id: Id72829d837d9e8d37bbec6092e5055f7c182db7a
This unblocks work on the header which will rewrite the layout
code.
This corresponds to a 0.06kb increase in CSS size, which is zero
after gzipping.
Bug: T249073
Change-Id: I23f18fc5f078da3331cad540bbaf533d348f2108
VectorTemplate has various functions that repeat themselves, only
differing in their choice of names.
This refactor begins by focusing on the personal menu and introducing
a generic getMenuData function. Hardcoded `p-personal` is replaced with
an `id` template key and `msg-label` is renamed `label`.
Future patches will simplify VectorTemplate by using this new
function.
You'll note the resulting PersonalMenu.mustache file is identical
to VectorTabs. These will be merged in I098e6921e8f7ef65dacacf09b9c25f70c945e58e
Bug: T249372
Change-Id: I5ae44a1008b065381eeff93f9fa625be5c5a9de9
Move all Vector JavaScript to ResourceLoader `packageFiles`[0] which are
much more compatible with modern development practices:
- The entrypoint is the first `packageFiles` entry (unless specified
otherwise). All other JavaScript must be explicitly executed.
- Remove a level of indentation due to IIFEs from every JavaScript file.
Regretfully, ESLint does not support modules except in ES6+ so the
otherwise useful `no-implicit-globals` rule must be disable. The
change comes with a comment so we always remember.
- IDEs and other tooling understand Node.js-like `module.exports` /
`require()`.
This change seemed the most sensible way to start developing new
JavaScript in Vector needed by the collapsible sidebar.
[0]: https://www.mediawiki.org/wiki/ResourceLoader/Package_modules
Change-Id: I287e604d5b1055aa97b5f987c24872755757ea1a
The Mustache templates were a bit of a mix of tabs and spaces. I like
spaces personally but dislike inconsistency within the project more. Use
tabs.
Change-Id: I22b777489d7281b42d1ab1981b47b2a71d3b639a
Adding `margin-top` property only with sibling selector for now
until cache is cleared.
Also removing already inherited from
`.mw-body-content` properties `position`,
`font-size` and `line-height` of same value.
Bug: T248761
Change-Id: I1ea5e08927a96ac69c1b65f248ae0420968b4d00
Going into the header work, we'll need this variable available so
that we can align the header with the personal tools menu.
Per Volker's request we change the value to `px` from `em`s.
Previously it was 5.28333px. It will now be 6px.
Bug: T246170
Change-Id: Ic1514e8592db8ef168fc846b8f8e485fdd465e49
Instead, for the subset of Grade C browsers without SVG support (currently
IE8), we remove the icon and display the label text instead –
in a hacky, but acceptable way.
Bug: T248062
Change-Id: I87660b69fe65b9ec2989ea606e5f76d427c28fee
As described in the readme but not implemented until now, this patch
enables the skin version to be specified as a URL query parameter. This
is useful for testing both skin versions during development and on wiki,
as well as enabling sharing URLs with a specific skin (Vector) and skin
version (1 or 2).
Obtaining the actual skin version requires tying together three input
sources, WebRequest, User, and Config. It seems simple but it'd be easy
to botch. For this reason, a helper class to correctly interrogate them
and tests are provided.
Bug: T244481
Change-Id: I52d80942b4270c008d4e45050589ed9220255a50
Move all the LESS `z-index` settings to variables.less so it's easy to
conceptualize how UI will be layered. jQuery CSS rules are untouched but
documented.
Also, remove the seemingly redundant re-setting of the `mw-searchButton`
`z-index`:
#mw-searchButton
z-index: 1;
}
This rule was added in 0c77e4f.
The sidebar work will require `z-index` properties and this refactor
eases the comprehension of those changes, as well as prevents the
accrual of more `z-index` technical debt.
Bug: T246419
Change-Id: Ic112a0ee3f701f87432838797be45c6069fdb522
The new template 'index.mustache' drops the Navigation
template partial (component) - instead embedding it in
the master template given its lack of usability.
Note to reviewer: Please ensure index.mustache and
legacy.mustache are identical.
Change-Id: I580fe55ca6aeb35dae8afee41e87172a5a729c7b
It is not the most useful of components and adds an additional layer
of complexity similar to multiple inheritance chains that we find in
Object oriented programming.
I suggest we use index.mustache going forward for laying out the different
components and use components/template partials for reusable components.
Change-Id: I6fd5fe1c3d3826d737ccd8ed5a38890305664876
This adds the same end margin as the portal container making the
opt-out-link more visually pleasing if it overflows its container.
Bug: T243281
Change-Id: I42eb3ec4a18ad9e4f6bcdb451593fec7e6e4992a
IE 9-11 cuts values 2 digits after the decimal point leading
to small miscalculations throughout the interface derived from `.mw-body-content`'s `em` value.
With `calc` it's forced to use same parent value for its
rendering calculations.
Bug: T102364
Change-Id: Id4ba39bc90174bab445ae0fb4d039c28a4f0b300
This commit is singularly focused on adding a link to the sidebar for
Vector, logged-in users. It does the bare minimum to fulfill the
requirements of T243281.
Additionally, it will help to answer the question "Do we need to use
abstractions (other than maybe different templates) to separate Legacy
Vector from Vector" by intentionally leaving out any abstractions in
order to make it easier to compare with a follow-up patch
(Ib2ef15180df73360cc1de25b893e49d415d23e1a) which does use abstractions.
It is a good thing to question whether or not we need addtional
abstractions in VectorTemplate and if they will help us as unnecessary
abstractions can have the opposite effect and just lead to further
frustrations down the road.
Therefore, I urge you, the reviewer, to let me know your thoughts! If
abstractions are viewed as not making our lives any easier, the
follow-up patches may be completely discarded and that's totally okay
with me. :) I think it's a good think to talk about now though.
Important changes:
* The VectorTemplate constructor was changed to allow injecting the
config, templateParser, and isLegacy boolean (only the config was
allowed before this commit). According to MediaWiki's Stable Interface
Policy, "Constructor signatures are generally considered unstable unless
explicitly declared stable for calling" [3]. Given that VecorTemplate's
constructor is not marked as stable, it is justified to do this without
warning according to the policy.
* Due to the above, the 'setTemplate' method is no longer needed and was
marked as deprecated.
* VectorTemplateTest was made to adapt to the new VectorTemplate
constructor. Additionally, it now extends from
MediaWikiIntegrationTestCase which my intelliphense server can pick up.
I *think* MediaWikiTestCase is just an alias to
MediaWikiIntegrationTestCase [1] and MediaWikiTestCase file was renamed
to MediaWikiIntegrationTestCase in [2], but I'm willing to change it
back if there is pushback to this.
Open questions:
* What are VectorTemplate's responsibilities? To me, it acts right now
as a controller (because it echos the full HTML string from the
template), a model (because SkinTemplate::prepareQuickTemplate sets data
on it which it later retrieves through `$this->get()`), a presenter
(because it adds data tailored for a web-centric view), and a view
(because it renders HTML strings instead of letting the view/template be
solely responsible for that). Arguably, some business logic might be
mixed in there as well (because it checks to see if a User is logged
in/has necessary permissions to show x which my changes here add to).
This might not be a problem if we keep VectorTemplate relatively small,
but will it remain this way as we progress further in Desktop
Improvements?
* How do we write tests for VectorTemplate without exposing unnecessary
public methods? For example, if I want to test the `getSkinData()`
method to see what state will be sent to the template, how should I do
this? One option might be to use `TestingAccessWrapper` to expose these
private methods which is what
`VectorTemplateTest::testbuildViewsProps()` does. Another option is to
accept this method as public. Is there a better way? Keep in mind that
even with access to this method, there might be many things to mock.
[1] 0030cb525b/tests/common/TestsAutoLoader.php (L64)
[2] Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
[3] https://www.mediawiki.org/wiki/Stable_interface_policy
Bug: T243281
Change-Id: I0571b041bcd7f19bec9f103fa7bccdd093f6394d
