Allow editors to define a different URL for random
by editing
/wiki/MediaWiki:Randompage-url
e.g. Special:RandomRootpage
Bug: T188697
Change-Id: I72bfbb9b02c99faa0c42c3212939f59b9b87149b
* 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
Two tests are failing. These are false positives that
obscure real failures. Both are removed for the following reason.
1) Editor test is covered by the redirect tests - failing due to
concurrent edits (possibly because multiple browser tests act on the same
page at the same time). However, editing is already covered by the other
2 cases.
2) Remove unwatch test - this is failing as there is a problem in the
setup - the page starts unwatched when it should be watched. The test
for checking that an article can be watched should suffice here.
Bug: T224947
Change-Id: I3049e1b190c3cb2ddc198a45681f59782f770d6a
Do the scrolling math manually, and only do horizontal scrolling on the
tab container. Don't do vertical scrolling, and don't scroll the
viewport.
Bug: T226112
Bug: T223142
Change-Id: Ie67e15bd51252906897a213505ae82cf29ba5cf2
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
Add package-lock file. The previous version of Node.js did not support
package-locks but v10.15.2 does.
Bug: T179229
Change-Id: I987bfb6f4c4cd0fe5c3f24d45e29c906e18a9e2b
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
This icon's stroke was explicitly set to `#000` before this commit, but
we need its color to be `#54595d` to match the other icons in the
overflow menu [1]. Unfortunately, although we set a variant in skin.json
for the icon to be colored this way [2], there are 2 problems that
prevent it from displaying this color:
1) The icon sets an explicit black color for its stroke attribute
2) ResourceLoader currently only sets the fill color on the `g` element
when applying the variant style [3]. It does not set the stroke color. Even
if problem 1) was removed, we would need RL to set the stroke color, but
I'm not sure how that would affect other variant icons that RL deals
with.
The simplest possible solution is to to change the stroke attribute on
the icon itself, although it unfortunately introduces technical debt as
this icon now differs slightly from the OOUI one :(
[1] https://phabricator.wikimedia.org/T222630#5266575
[2] https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/skin.json#L262-L267
[3] 4e59467427/includes/resourceloader/ResourceLoaderImage.php (L331)
Bug: T222630
Change-Id: I8c10a6012c7d32ab8555b874e766bc2f36437cf8
wgRelevantPageTitle is generally the same as wgPageTitle.
It is different on special pages that act on a page.
For example, on Special:WhatLinksHere/Moai
wgPageTitle => Special:WhatLinksHere
wgRelevantPageTitle => Moai
This change would allow Special:Homepage to have the talk overlay
connected to its talk tab.
If Minerva has such special pages that act on a page AND those
pages have talk links AND the 'skins.minerva.talk' happens to
be loaded, those links would now show the talk overlay.
I found no such cases but I cannot say they don't exist.
I also don't know if this change would be a regression
or an improvement.
Bug: T225659
Change-Id: I5d60ff3f0295f44a6d59cd772e27656b69ef0972
* 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
