A list that toggles visibility via the checkbox hack is needed in at
least two spots: the page actions overflow menu and the user menu. This
patch makes several refactors to turn what was previously hardcoded into
page actions a reusable component:
- Start a new components directory. Components are reusable and
composable. The subdirectories are organized by function, not
ResourceLoader module bundling which greatly improves the ability to
see a component's full functionality in one directory instead of
examining the entire codebase. See updates to README.
- Extract pageactions.less into:
- ToggleList.less: LESS for any checkbox hack list.
- DropDownList.less: LESS for lists that open downwards.
- MenuListItem.less: LESS for list items of menus.
The division makes it easier to see concerns, dependencies, and change
code.
- Move pageActionMenu.mustache to a component and extract ToggleList
template.
- Extract ToggleList.js from Toolbar.js.
Bug: T214540
Change-Id: I171831469a6733c458bc5c7ba249a5096ca975b8
We would like to hide the user links and show only toobar when
OverflowMenu is visible. The User contributions link is available
only in user_links section only, as we're going to hide this
section, we need to move that link to the Toolbar.
Bug: T224735
Change-Id: Ib4f297993213fcc8fc3dd998e282e5b39957485e
User links bar has the items already rendered in toolbar/overflow
menus. There is no need to render user links if the overflow menu
is available.
Bug: T224735
Change-Id: I613fa68b6cd43acf07bcb85af77d0239dc6bba6b
The MainMenu is built using Builder pattern. The hamburger icon
is always the same, and it should be defined in the Menu builder,
not as a separte UI element.
For better code organization, all things related to MainMenu
building should stay in the Menu Director/Builders, not in the
SkinMinerva class.
Changes:
- moved hamburger icon build method into MainMenu/Director
(as the menu icon is the same for all builders)
- renamed stuff in BaseTemplate for better readability
- use MediaWikiServices::getInstance()->getSpecialPageFactory()
instead of deprecated SpecialPageFactory class.
Change-Id: Ie5b30c0dd1649d38a4023ccb40c99dee2a127a70
Is used only in Minerva, and it's so simple, there is no need to
have a special function for that (no improvement no performance,
nor readability)
Change-Id: Id5a4edb077671dc12f58df31273f00a1a816f097
We can define return types using `function(): TYPE` notation.
We should do that when it's possible.
For now, it's not possible to type nullable return type (PHP7.1
supports that, but PHP7.0 and most probably HVVM doesn't),
Change-Id: I6b58a882383832313ef47a296c726a4044a97954
The isAllowedPageAction is used in multiple places (SkinMinerva
and in PageActions toolbar builder). This logic should be defined
in separate service, easy accessible for different parts of the
Minerva skin.
Changes:
- Introduced MinervaPagePermissions as a centralized place to manage
user permissions
- Introduced MinervaNoTitlePermissions, an NullObject pattern to
handle situations when we do not have Title object (like in CLI)
- removed Minerva.ContentHandler service as it's not required any
more
- moved all permission names into constants
- moved isTalkAllowed() into MinervaPermissions
- renamed isAllowedPageAction() it `isAllowed()` to not mix it
with PageActions. Those checks are used in many places, not only
on PageActions menu
- made isAllowed( watch ) more robust - now it checks that Title
is watchable
Bug: T221792
Change-Id: I87d44a9c717b5f752b8d1fd2f146d7f5eef3c53f
Rename SkinMinerva->prepareUserButton() to
prepareUserNotificationsButton(). The function is responsible for
inflating the button that displays notifications when pressed. This name
would be especially confusing when an actual user button is added in
T214540.
Bug: T214540
Change-Id: I8965ef4c5b29ea692d67e821a06131ad5f287287
* Add a container around the tabs and use flexbox
to position the tabs on one line and make it
scrollable.
* Add some JS to scroll the currently selected
tab into view.
Bug: T223142
Change-Id: Ie2205e6836797c2ac000e12a01f78a4aa7bc5b81
Instead of using $group->insert(....)->addComponent() we can define
our own small SingleMenuEntry that defines a standard menu entry with
a label and one icon. The icon name and tracking code by default will
be the same as the menu entry name.
Changes:
- introduced SingleMenuEntry class
- updated Definitions class to use new entry instead of using old
MenuEntry class
- changed the Contributions meny entry name to match icon/tracking
This should simplify code a bit, thanks to this approach we should be
able to remove the Definitions class in some future and keep building
MenuElements in the builders.
Bug: T221792
Change-Id: I1f145e8cd173b72b01a145b2dba3704593f17ab7
The director is now passed the array from `BaseTemplate::getToolbox()`
as all of the server rendered links we show in the main namespace/user
namespace overflow menus (including wikibase) will be in the toolbox
array except for the "Uploads" link in the User overflow menu which is
added in the UserNamespaceOverflowBuilder.
Bug: T222630
Change-Id: I280537c6b8b32036d68a5a004571bb5a41c2e703
Before this commit, the filters form would stay collapsed and the user
couldn't toggle the visibility of the form. This commit fixes that by
loading the necessary modules for the history action to make the form
toggleable again:
- mediawiki.page.ready
- jquery.makeCollapsible
- jquery.makeCollapsible.styles
Additional Changes:
- The explicit addition of the 'mediawiki.action.history' module to the
defaultModules array in SkinMinerva was removed because this module
should already be added by HistoryAction.php and all we are doing with
Minerva is styling it differently.
- The styling to hide the filter revisions box in
skinStyles/mediawiki.action.history.styles.less was removed now that
this functionality should work again
Bug: T223204
Change-Id: Icf4a22a62228aca5a120bcdf3d6fede35b3c928e
The PageActions menu shouldn't be built inside SkinMinerva class.
All menus should be build in similar way so it's easier to understand
how different parts of the system work. This will allow us to easily
track different menu elements/move elements between different menus.
Additionally we should allow extensions/3rd party to modify both the
toolbar and overflow menus.
Changes:
- Removed PageActions logic from SkinMinerva class
- introduced new PageActions/Director to build page actions menu
- introduced Builders for toolbar, and different types of overflow
menu
- because Overflow menu elements require the
BaseTemplate::data['nav_urls] array, instead building all links,
pass the array when building PageActions menu. Code for getting
menu entries had to be rewritten (use $navUrls array instead of
$this->tpl['nav_urls'];
- ServiceWirings file contains logic on what to pass to
PageActions/Director class (which builders)
- PageActionsMenuEntry setTitle() and setNodeID() returns $this
so we can use method chaining. Only a syntax sugar.
- if AMC is not available/Overflow menu is disabled via config,
system will pass EmptyOverflowBuilder. System will not add
"show more" icon to toolbar menu when $overflowBuilder returns
empty set of options.
- both ToolbarBulder and OverflowMenuBuilders (except
EmptyOverflowBuilder) will run 'MobileMenu' hook. Extensions should
listen to hook, and inject it's own menu entries at their leisure.
Required follow-ups:
- SkinMinerva provides isAllowedAction() method which is used
both in the skin code and in Toolbar builder. We should extract
that method into separate service
- SkinMinerva provides getHistoryUrl() method which is used
both in the skin code and in Toolbar builder. We should provide
MinervaUrls service that knows how to build custom mobile URLs.
Bug: T221792
Change-Id: Ie08c4b61cea60c3a42fbf796a39360feea22bc33
To simplify and make code reusable all menu elements should be built
by using Builder pattern. This a first step, first we the pageActions
methods should return Group object/IMenuElement objects, then in the
second step we will extract this logic into Director/Builder
classes leaving SkinMinerva class much smaller.
Bug: T221792
Change-Id: Ic51c4ca4139919fc3c5f3ada8b1b2fe5d23031d7
In some edge cases the RequestContext::getTitle() can return null
instead of Title object. Similar situations already happened in the
past (see T179833). The RequestContext::getTitle() documentation
says it can return null, therefore code should be resilient and
support such situations, even if there are not common.
Bug: T221792
Change-Id: I842f8c49f20e511fda3b081e59a06586810bc748
Ensure SkinUserPageHelper::isUserPage() returns true for user pages
that are IP addresses.
Also adds the page-action menu to all user pages.
Bug: T220114
Change-Id: I3703899bc9ff0042c74260d36f48a388b78b0b6b
If viewmywatchlist|editmywatchlist permisions were set to false for
anonymous user, MinervaSkin would show a watchstar icon that links
to LoginPage, even if user was logged in. Clicking watching action
would cause browser to reload the page without any effect.
Under the hood - system would redirect to login, and then the login
page would redirect user back to the article page because user is
logged in.
MinervaSkin should respect viewmywatchlist|editmywatchlist
permissions. If user do not have access to watchlist, do not show
watch icon.
Bug: T221792
Change-Id: I26a1133a7ccff6a4adcdc72d594d0902bfa8ff79
The SkinMinerva::createWatchPageAction() was depending upon
$tpl['content_navigation']['actions'] object, which is created by
SkinTemplate::buildContentNavigationUrls(). Although only 'watch'
and 'unwatch' keys were used, moreover, code was using only 'href'
property from both 'watch' and 'unwatch'. All other props are
overrided, not used when rendering. Also the title of unwatch
icon was set to "watch this page" which was incorrect.
This system was bit complex to manage (we should provide dependencies
not pass the whole 'content_navigation']['actions'] array). It would
also make further refactoring more difficult, as watchstar icon
shouldn't depened on quicktemplate stuff. We were using only href
attribute which is super easy to calculate.
Changes:
- do not depend upon $actions, get href by using $title->getLocalUrl
- set proper title for unwatch icon
- simplified SkinMinerva::createWatchPageAction() logic
Bug: T221792
Change-Id: I9609949b60a7e2f2f0a947c05c80c89be32d4cb1
Styles the action=history page to resemble it's desktop
counterpart for users in AMC mode.
Bug: T219895
Change-Id: Ide359724a4628f69ef03acee7718d70c698b8faf
The Skin::getNewTalks() is already called in SkinTemplate::prepareQuickTemplate.
There is no need to call this function again, as is pretty heavy. Instead of
calling it second time, just re-use the value stored in the QuickTemplate
Change-Id: I0e9491405f4d760278db3a423ee14e8f80720291
There is no need to call SkinTemplate::buildNavUrls() as the 'nav_urls'
from QuickTemplate are used only when OverlfowMenu is present. There is
no need to do that heavy calculation unless we really need it.
Change-Id: I003efcdeffe10f6a3a155932a20c09e8f62c747e
MinervaNeue doesn't show any sidebar, only MainMenu and
PagetActions menu. There is no need to call original
Skin::buildSidebar() as the result is not used.
Change-Id: Iec60491d4b45b7b6f6ba23525a4f6af08903bb31
When advanced mobile contributions is enabled and the overflow menu is
shown:
- The initial state should have no transition. This prevents the menu
from flickering initially. Move the transition to the checked state
only.
- The icons should be available for server-side rendered HTML without
JavaScript. Add wikimedia.ui to the SSR modules.
Bug: T216418#5129152
Change-Id: I3b91f6cdefd4b727c2fb512272d8c4282af632bf
Cleanup ranges from removal of unused variables, fixing of method
case mismatch, collapsing of multiple `if` statement that can be
combined into one.
Change-Id: Ib9d6e2e4d747da699067c0c0a9aab5e8af29aef2
When advanced mobile contributions mode is enabled and
`$wgMinervaOverflowInPageActions` is set, show a secondary overflow menu
on main namespace articles and user namespace pages. The menu content
varies for each namespace. The new submenu is *disabled* by default,
even when AMC is active. This feature should not be deployed until
instrumentation is available.
The secondary menu is rendered in PHP using the existing menu system
with some changes to the template. The checkbox hack is needed for no-
JavaScript keyboard navigation until :focus-within is supported. CSS
additions are documented in the source.
All client side toolbar execution occurs in Toolbar.js. Enhancements are
documented in the source.
Minor changes to the existing download button:
- Move download and edit button initialization to Toolbar.
- Update copy (not visible) from "Download" to "Download PDF".
- When the overflow menu is present, use the "hasText" / label style.
Wikimedia UI icons are copied from OOUI at d00a0ac and seem useful to
expose as HTTP URIs (not data URIs).
The overflow menu does not show for pages provided by the content proxy
since its entries depend on $tpl->data['nav_urls'] being populated.
Bug: T216418
Depends-On: I0781151a8232b6a7b52f79a34298afcecb8e4271
Change-Id: I4b50a0e519024a7ab91dae6ab40b23cf14a03861
Changes:
- moved all menu elements definitions from SkinMinerva into
a separate Definitions.php file
- moved menu building from SkinMinerva into includes/menu/Main
folder
- introduced Builder pattern for easy menu building
Minerva/Menu/Main/Director takes an Minerva/Menu/Main/IBuilder
and builds the menu. The IBuilders use definitions from
Minerva/Menu/Definitions file, so all definitions can be shared
across different menus
- used ServiceWiring file to register MainMenu Director as Service
- left class_alias for old MenuBuilder as some extensions still use it
- The hooks system have to stay like that as some extensions
are using it (BlueSpiceMultiUpload and GrowthExperiments).
- introduced AdvancedMenu builder for the AMC mode
Bug: T216152
Change-Id: I210c3f1fa36bbd2f9108d728b12cbb21ee210354
SkinOptions array was used to determine which options are available
for current session. Once we started extracting things from
SkinMinerva class, we found out that lots of things depend on
SkinOptions.
For example MainMenu/PageActionsMenu depend on skinsOptions var.
We could pass $skin object as dependency to a menu builder, but
this would cause a circural dependency (Skin depends on menu builder,
menu builder depends on skin) which is an anti-pattern.
In order to avoid such situations lets prepare first, and extract
the SkinOptions to a separate class, register it as a service
so different parts of Skin Minerva can freely use a single instance
of SkinOptions object.
Bug: T216152
Bug: T221012
Change-Id: Icd5da546e1bfaf8d9bfe86dab3b659a88eae19e4
SkinMinerva cached the ContentHandler object for better performance.
In the future the ContentHandler will be also used in the Menu,
for better readability, store ContentHandler as Service.
MediaWikiServices will initialize service on first access and cache
it for future needs. Same applies to SkinUserPageHelper,
Bug: T216152
Change-Id: Ia98dc860862360a68556272714669f0c3a13eb1e
