This allows '.vector-main-menu' to correspond to MainMenu.mustache, and 'vector-page-tools' with PageTools.mustache
Bug: T317900
Change-Id: I65c0d7cffbdf1cf9e59cde0c0fc4dca788e799de
- getTocData is moved into VectorComponentTableOfContents and it's test file
The following changes were made to the main menu, toc and page tools PHP components
- Avoid passing in $skin to the constructor
- Handle isPinned logic inside the component
- Add a public ID constant to the components
- Dropdown data for each feature use the same naming convention
Bug: T317900
Change-Id: I77a617a6c1d93bccd3b6e59353299f5534624e53
Uses all of the changes from Jon's patch in 866503 to move all of the sidebar
menus after and including the tools menu into the page tools component. The rest
of the menus remain in the main menu.
Additionally:
* Per T317898#8468437, the "Tools" label should be "General". It was also
assumed from the prototype that the "More" label should become "Actions"
Bug: T317898
Change-Id: Ic9c1586febd8ebfff4a17285e6bd59cee509bd34
This partially reverts 94c7f31082.
Headings inside wrapper divs etc. actually are rendered in the table
of contents.
Bug: T318044
Bug: T324869
Change-Id: Ie3181d9e9605cd2b5897b12931572057e80d6661
The UnpinnedContainer and PinnedContainer are versions of the
same component but with different states. Recognize them by
organizing them in the same subfolder. Update all existing usages.
Bug: T317900
Change-Id: I2c25937190997764fa23e0b581be5538ba4d06de
While removing this we also noticed that we check the value of
isMainPage. This doesn't seem like a good idea as most main pages
do not have a table of contents, so it seems like adding
unnecessary complexity for a state that doesn't exist in practice.
The existing code path also doesn't work as it adds a table of contents
unstyled to the page.
Bug: T324874
Change-Id: Idaeff6ace5912ea74ed9d335526027c4690ac8fa
Follow-up to c1ebfd58, when removing the toolbox menu from
the sidebar, calls current() on the value of array_splice()
in order to return the actual toolbox menu data,
instead of an array containing that data.
Bug: T318434
Change-Id: I79fd0f98cb1491dec0810408ad91c7a855cea9cf
This was an artifact that remained after the switch from data-is-persistent to
data-feature-name. It can and should be removed now.
Change-Id: I6b50d243c7de3d46fb8c4baf398574d5c4247497
* Leverage the infrastructure around feature management to handle the page tools
pinning and persistence
* Make pinnableHeader.js leverage features.js if the data-feature-name attribute
is set
* Sets tests/.eslintrc.json ecmaVersion to 2018 to enable destructuring in test
files.
* Adds a isPinned helper method to pinnableElement
* Add a logged in requirement so that the pinned feature is disabled for
anon users.
Bug: T322051
Change-Id: Ib86282216882fa94e37b7088a3f4bd0c1bcf6cd4
Our previous use of unset was leaving an undefined index of 0 in
the array of portlet links.
Use array_splice instead so we update keys.
This removes the "phantom" main menu that is displaying in the
main menu when the print menu is enabled.
Bug: T318434
Change-Id: I59d9f00636a6302a679599a2b829cd107980a1e3
In preparation for 856718 where pinnableElement.js makes use of features.js,
move features.js and limitedWidthToggle.js out of the skins.vector.js module and
into the skins.vector.es6 module. This will make it easier to use by
pinnableElement.js without needing the es6 module to depend on the es5 module.
This does have the negative side-effect of causing the limited width feature to
not be supported by IE11 (and other non-ES6 browsers), however this tradeoff was
discussed with our product manager to be acceptable. Additionally, this
maintains the status quo as the toggle button does not currently show in IE11
(which may be a bug).
Bug: T322051
Change-Id: If0e8cb98deabe847c2cc71fddb90ca36d15e5f8f
This is an incomplete styling of the menu.
This should be enough to start an initial design
review and unblock other work on the dropdown.
Out of scope for this patch:
- Pinning (being done in T317900)
- Design (will be done in follow up)
This should cause no visual regressions in Pixel.
Bug: T317899
Change-Id: Id7b47cc16fc8cf93d406687198ba37acf7a9cf24
As we build out these components further we should be encouraging using
the component system rather than the SkinVector function calls.
This allows us a way to gradually move code over as needed.
Bug: T322089
Change-Id: I7b38ae5b6fe2aa42759ae482e7647a26fcedfc38
As far as I can tell, this has been dead code ever since it was
introduced in change Ica040cd18d (commit aa10668e6d), and was never
called; the effective search URL was initially constructed via inputs to
the search form (e.g. a hidden input for wprov), and later the separate
urlGenerator.js was added. (Also, “suggestion” is not a valid
Special:Search paramater as far as I can tell.)
Also add some tests for the separate urlGenerator.js, to make up for the
other tests being removed.
This reduces the module size of skins.vector.search enough that we can
decrease the bundle size test config to 3.2 kB [KiB].
Change-Id: I6be5ba362402c2c2ec582d9a0192c80f46e7a7ce
If the wgVectorSearchClient supports it (the default implementation
doesn’t), add a visible-item-limit to the cdx-typeahead-search, and wire
up the resulting load-more event (new in Codex v0.3) to load additional
search results on scroll.
The hard-coded visibleItemLimit (7) is chosen to match the default limit
of the wbsearchentities API, but ultimately arbitrary; we can look into
how to make this number configurable later, if necessary.
This increases the module size enough that we need to bump the bundle
size a bit more.
Bug: T322333
Change-Id: Iadade9cbf48457cfeabc78439624602ec3f98782
Co-Authored-By: Jon Robson <jdlrobson@gmail.com>
Needed-By: I67fac3b209d6a1ab2661e1e1c0681edd8472ac6c
