Rename template and CSS files to match updated naming conventions, replaces instances of "sidebar" with "main menu"
Bug: T316570
Bug: T317437
Change-Id: Ib4050768f20b1734d356104f18aa539f657099d8
Follow up to 49c8b5f514
Our PHP parser resolves >Menu to the parent directory which
differs from the frontend Mustache library.
Best to have different names for these files to avoid this problem.
Bug: T311319
Change-Id: Iea708718a0b928c4902dc7bac0c5ee304b89f961
SkinMustache in core provides most of what is required for Vector to
generate its menus. In the interest of having a canonical source of
truth for menus across all skins, Vector should use this data.
To ensure the HTML generated is (mostly) the same after this patch to
prior, a few modifications are necessary:
* The data from core is decorated so that Vector can continue having its
own custom class names on menus. This is done using the
decoratePortletClass method.
* There is no support for a menu having a header representing the
selected menu item, as is currently the case with variants. This is
achieved via an extension to getPortletData. It's assumed that later
when variants are merged with languages, this can be removed.
* Menus are agnostic to how they are displayed, so we must continue to
add the is-dropdown template variable to drop down menus. In future we
may want to rethink our Menu partial to make this unnecessary in PHP.
* The portal-first class is redundant in the modern Vector as we can
use the first-child selector. Previously we introduced a class to
service the legacy skin where this rule doesn't apply as #p-logo is
the first child. However, the legacy skin can do this using a special
next sibling selector instead.
Bug: T268157
Change-Id: I5f7adc1840441b508ffee40139b85b64021789e6
In preparation for using the data provided by SkinMustache class
we need to separate the opt out data from the rest of the sidebar.
The opt out data is specific to Vector.
Change-Id: I4461da92c1787d272bbf99e6644bdb9e6c388a68
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
The has-logo property is redundant:
The Sidebar in legacy is its own component. The logo is always
rendered in the legacy sidebar.
data-emphasized-sidebar-action can be unconditionally sent
The legacy sidebar doesn't use it, so there is no need to conditionally
add a check for legacy
These two changes allow us to remove the isLegacy property in favor
of the single use of the isLegacy method.
Change-Id: Ie7ee3cec29b20d07db81799484627254d4a78f5f
In preparation for moving the languages out of the sidebar (T256023)
and to facilitate experimentation in the Universal Language Selector
extension, we should separate the data from the languages portal
from other portals.
Note the languages portal has traditionally appeared at the bottom
of the sidebar, so this can be done safely in the same way we
introduced data-portals-first
Change-Id: I4be06278ec256cc55aee36c2946339fb49d21b46
To complete the refactor, the Portal is also refactored
as a Menu using the getMenu function.
An old code path supporting portals outputted by hooks with
strings is marked as deprecated to simplify this code in future.
array-portals-first -> data-portals-first (the value is not
an array)
Changes:
* $this->getLanguages and $this->getToolbox() always returns an array (see BaseTemplate)
but we previously supported portals made using raw HTML. Let's move away from that
behaviour and deprecate it.
* Hooks are moved into buildSidebarProps and marked as deprecated where possible
(SkinTemplateToolboxEnd). SidebarBeforeOutput can be used instead.
Bug: T249372
Change-Id: I2549af3e24e5d51c09e9a88ca50a0d9b2e154c3f
The opt-out link was missing a tooltip which is important for
accessibility and to help people gain more context as to what it does.
Bug: T250093
Change-Id: Ie6cbaf5c941615d1662700415b8f1823987a563d
Changes to support feature:
* ResourceLoaderSkinModule logo features are dropped
* New layout provided given the fork in layout between legacy and new.
* Legacy sidebar styles now pulled out
* breakpoint styles are not carried over from legacy Vector
The new Vector layout for now has one breakpoint.
Changes to storybook:
* The storybook script now pulls down image assets so that the logos can
be shown in storybook. The script is adjusted to make use of a static folder to
serve these images.
Note:
* The legacy mode is not touched as part of this patchset.
* The personal menu is unaffected by this patch and is out of scope.
* The alignment issue is noted, but will be solved at a later date.
* Changes to portal are out of scope.
* Adding storybook for modern descoped, given its not possible to load
both legacy layout and modern layout inside a storybook at current time.
Sample config:
$wgLogos = [
'icon' => 'https://di-logo-sandbox.firebaseapp.com/img/globe.png',
'tagline' => [
'src' => 'https://di-logo-sandbox.firebaseapp.com/img/tagline/en-tagline-117-13.svg',
'width' => 117,
'height' => 13,
],
'1x' => 'https://en.wikipedia.org/static/images/project-logos/enwiki.png',
'wordmark' => [
'src' => 'https://en.wikipedia.org/static/images/mobile/copyright/wikipedia-wordmark-en.svg',
'width' => 116,
'height' => 18,
],
];
Coauthor: Aron Manning
Bug: T246170
Change-Id: Ibc4b055150761388a6b78f9127da342c451ce0e7
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
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
This allows us to insert HTML underneath the first portal or wrap
the portal in a containing element in future if we want to target
additional CSS to it
Change-Id: Ied28d95407b8d59fc819bb07a2cce3242bd93088
* Following up on the work from
Idf90ee2a0f1c1d08a31cf50099c0bebc7b67e619, this commit renames the
storybook files/storybook names to their respective component name.
e.g. personalNavigation.stories.js => PersonalMenu.stories.js
Bug: T243281
Change-Id: I68054663c5a597f90a826b6f75bf399382dca609
2020-03-03 18:32:55 +00:00
Renamed from stories/sidebar.stories.data.js (Browse further)
