The number of generic menu entry specific files is growing which is
cluttering the Menu/ directory. Move the entries to a new subfolder.
Bug: T214540
Change-Id: I807d6f6034ee1924e3a606f5e6782c3298896825
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
* Introduce a HomeMenuEntry class and use it for adding the home menu link
* Provide override methods for text and CSS class
Bug: T223210
Change-Id: I37160887478cba829a6e2f10a4d8f87d95167556
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
MediaWiki Core defined $wgHideInterlanguageLinks that can be used to
disable the interwiki links. Minerva skin should respect this config,
furthermore, this config should take precedence over the Minerva's
$wgMinervaAlwaysShowLanguageButton config.
Bug: T214540
Bug: T221792
Change-Id: Id4fe8b67a17f9c28c00a8a3a207946e146502cde
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
The Language switcher will be used in couple places:
- Toolbar, if the AMC is off
- both overflow mmenus when AMC is on
To make code DRY, first we should provide a single way to
create Language Switcher menu element, so we can use same way
in all possible scenarios.
Bug: T224735
Change-Id: I5ba0dbad7089012c7fd1bfc43787775c7e36d575
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
Previously we were passing the $tpl->data['nav_urls'] array,
because of that all params were called $navUrls. That approach
was incorrect and we have to pass $tpl->getToolbox(), which
means all $navUrls variables/paramters have to be renamed to
$toolbox for better clarity
Changes:
- renamed $navUrls to $toolbox
- update phpdocs blocks
- renamed buildEntry() into build()
Bug: T222630
Change-Id: Id0023cfbb9779c502edc0f91e31a2a912af84084
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
Upon building the menu components for logged in users, the logoutToken
was not properly appended to the logout URL. The URL is supposed to be
`?title=Special:UserLogout&returnto=...&logoutToken=...`
and not what was rendered previously, see below
`?title=Special:UserLogout&<token>`
The absense of the 'logoutToken' param prompted an intermediate step asking
users to confirm the logout action. We don't need this in Minerva if users want
to logout from their accounts and asking users to confirm this action is annoying.
We want the user to be able to logout when the "Logout" button is clicked
and the system would have generated a logout token and appended to the logout
URL in the format specified above. This patch has been tested locally and
everything works just fine.
Bug: T225220
Change-Id: I20f30db707915179a0604a1dc9061d8db225a230
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
If the option is not default, system will throw OutOfBoundsException
when trying to access OPTION_TABS_ON_SPECIALS value.
Bug: T225279
Change-Id: I01ff016caea0bfd961c71e15388d670cd93acc7f
The Growth extension would like to override the the profile link in
the main menu. We can replace the MenuEntry from group, but
modifications of each component shouldn't be allowed. That approach
is too much error prone. Furthermore it won't allow us to change
how the Login/Logout link works.
The Menu/Group accepts IMenuEntry objects, instead of building
complicated Login/Logout menu entry, let's encapsulate all that
logic into small, well-contained AuthMenuEntry object.
Now, as we have the AuthMenuEntry, we can add an `overrideProfileURL'
method to allow the profile url modifications. That approach will
allow modify profile links, and "how to modify links" logic in
one place.
Changes:
- extracted Definitions::insertLogInOutMenuItem() body into new
AuthMenuEntry class
- renamed some variables like $logoutUrl for better readability
- introduced `AuthMenuEntry::overrideProfileUrl()` method that
allows modification of the Profile url, label and tracking code.
Bug: T222834
Change-Id: Ib7356acbd3373c7a4b591c9c133d7d02a55239b0
Instead of using Title::quickUserCan() and User::isBlockedFrom()
we have to use the PermissionManager.
Bug: T221792
Change-Id: I5bffd859140f73a78fa2fc155b7b2343eefd3807
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
