Previously it always used the global context RequestContext::getMain(),
which is basically equivalent to using $wgTitle or $wgUser, and will
not produce the correct results when used in other situations than
regular web requests (e.g. API requests or jobs).
MinervaPagePermissions is required to parse pages (due to the custom
section edit links in SkinMinerva::doEditSectionLink), which is often
done in API requests or jobs.
Pass the appropriate context in SkinMinerva::getPermissions(). This
fixes T234868. Note that MinervaPagePermissions is also used elsewhere
and I am not fixing those cases.
Depends-On: Iaa83e5f801c7776bf8218d8ce7484e2485b227d4
Bug: T234868
Change-Id: I2d6fd525f20a0b6beeeaa731f6b8caa471b8529d
For compatibility and consistency/convergence with Vector, Minerva's
menus are linked to their Vector counterparts.
This allows us to get mw.util.addPortletLink to work inside Minerva
Bug: T231925
Change-Id: I121f12497eac6fcf0b63b9ccce561320eb8b3e62
Managing the transition from old implementation to new:
* A version number is exported from skins.minerva.scripts to
tell dormant code added to Echo in I09c27a084100b223662f84de6cbe01bebe1fe774
to begin running.
* A skinStyle is added for the new `ext.echo.mobile` module.
`mobile.notifications.overlay` will soon cease to exist but is kept registered for
backwards compatibility reasons
- Drop ev.preventDefault call from onSkinClick - it is no longer necessary and will ensure
notifications overlay closes when shield is clicked while it is open.
Integration:
* A server side hook SkinMinervaReplaceNotificationsBadge allows Echo to replace
the current Minerva notification badge
* A to-be-created client side hook is subscribed to to deal with the navigations drawer
like functionality using the mainMenu code
* id and class names are added to the container for the NotificationBadge for compatibility with
ext.echo.init in Minerva's desktop mode (it will work like Vector)
See I09c27a084100b223662f84de6cbe01bebe1fe774 for understanding the bigger
picture.
Depends-On: I09c27a084100b223662f84de6cbe01bebe1fe774
Bug: T221007
Change-Id: I4c11f1b241d629e1b294ebaec17472fbf944f8c7
If JS is disabled and you are logged in, no icon shows.
Icon class is incorrect.
I also update the test.
Change-Id: I786ced58171f4ffb4a9d75dcfc6f993647399065
uses the CSS :last-child selector to align the last item in the header
with the edge of the container.
This is usually the notification icon in "normal" mode and
the user menu icon in AMC mode.
Bug: T229440
Change-Id: I4430f5659093f76896e2b86e076526a0b51d9630
The Minerva permission manager distinguishes between user edit
permissions and content model edit support. Rename EDIT constant to
CONTENT_EDIT to help clarify the distinction.
The resolved name in skin.json is not updated to avoid deprecation
policy.
Change-Id: If86b8b5cd9d04ec2881931a3b629bc50e1dd9252
When a user is blocked, only present the "locked" page edit link. Omit
the section edit links entirely.
The logic for checking user permissions already existed in
ToolbarBuilder. Move this logic to MinervaPagePermissions and add a new
"EDIT_OR_CREATE" action distinct from IMinervaPagePermissions::EDIT.
These names will be revisited in a following patch.
Bug: T206265
Change-Id: Ia43a670a259cabc313c004fe06c91e078bd41562
Changes:
- added support of event-data-name to toggle list and all menu
entries
- track main menu open actions
- prefix all menu interactions with `menu.`
- prefix menu opening with `ui.`
- track tab clicks (also a part of new ui)
- track notification icon clicks
We're not tracking the Download icon as it has it's own
instrumentation.
Bug: T220016
Change-Id: I442103c1f8967c6710429329f024f266c9b11ea6
Two new feature flags:
1) MinervaPersonalMenu
2) MinervaAdvancedMainMenu
Changes:
* AMC defaults to false on desktop - desktop doesn't have AMC mode it just
enables several skin options.
* WHen inserting a link at the bottom of the page check whether the talk at top
of the page (tabs) is enabled.. not AMC
* Update ServiceWiring to construct menu based on MinervaAdvancedMainMenu
and MinervaPersonalMenu - note when former is enabled but not latter there is
no way to logout. Noted in README.
* Use one entry point for skins.minerva.amc.styles/index.less
* Document files inside skins.minerva.amc.styles to make it clear which features
they are associated with
* Drop history page styles when AMC is disabled - it's not possible to ever get to
these as the history page redirects in non-AMC mode
* Rename the class .minerva--amc-enabled to minerva--history-page-action-enabled
to reflect its real purpose and move styles from skins.minerva.base.styles to skins.minerva.amc.styles
No need to worry about cached HTML as AMC runs without cache...
* Remove isAnyAMCOptionEnabled - it's an antipattern and should be discouraged as it discourages the
art of feature flagging. Nothing is using it after these changes.
* The AMC_MODE flag is disabled. There is no need for this - AMC is not a feature and therefore not a
skin option. It is a mechanism for turning on other skin options. Tests are updated.
Testing:
It should now be possible to enable any feature in `beta` and see it in the beta of the
site.
Bug: T229295
Change-Id: I48959905f5c09721b14a27aa1a5ad82849ac6263
It is expected that in mobile mode, onRequestContextCreateSkinMobile
hook will explicitly set skin options based on the user configuration.
The desktop should however reflect everything with AMC enabled.
Bug: T229295
Change-Id: Ib3bf09c25d9bcf9b31d994b92a1d016cca8a6224
* New module skins.minerva.icons.wikimedia provides icons
from Wikimedia UI in Minerva
* search selector in skins.minerva.content.styles.images is
retained for cached HTML
* skins.minerva.icons.loggedin now a
ResourceLoaderOOUIIconPackModule and bell removed from repo.
* userAvatar replaced with userAvatarOutline
Bug: T224070
Change-Id: Ibed609371060acc4b69e5cd4cd4f20edc871b3ba
The $hasLangauges and $hasVariants checks were used in couple places,
which lead to the same code used in many places.
Following the DRY rule, let's implement a Service that can do that
check, and use that service everywhere in code.
Bug: T224735
Change-Id: I46d58758356e870c408a74b2c087a42d6ad0ddea
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
* 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
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 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
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 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
The Group shouldn't depend upon concrete MenuEntry definition.
Different Menus can present different MenuElements. Code should
allow easy extensions, not limit only to single MenuEntry
definition.
Changes:
- introduced IMenuEntry interface
- MenuEntry implements IMenuEntry
- removed isJSOnly from logic as it's related only to one menu
element (Watchstar) and Group shouldn't be aware of some special
handling for some elements. The IMenuEntry shouldn't define this
method
- getName, getComponents, getCSSClasses should have defined return
types
Bug: 1221792
Change-Id: I0646df734e869c26bfa8c3a772200e8258a8acce
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
To help us test special pages prior to moving them on mobile it
would be useful to make AMC the default on desktop
where the special page override does not exist
This is also probably what editors on desktop using the Minerva
skin want out of the skin.
On top of this, add an amc class to the body tag so we can
target styles at AMC and/or non-AMC users
Change-Id: I7f3141bae71181131ae4878fd21fb6ff4322c8ca
To make things neat, use "MediaWiki\Minerva\SkinUserPageHelper;" at the top
of the file and then mock class directly (shorter and easily readable).
Change-Id: Ie2ee64e75c38fff77d41af20bdea01015ed39a87
* Enable discussion button on main page in mobile view so users
can view discussion topics related to the main page on mobile.
* Update test to make sure only 'talk' and 'switch-language' actions are
enabled on the main page and 'edit' and 'watch' are disabled on the main
page.
* Minor typo fix for doc type. Use "array" instead of "Array" and CSS
alignment fix issue with Discussion button when displayed together with
Language selector button.
* [Suggested by: @Jdlrobson] Use a generic "a" CSS selector to style the ".talk"
and ".language-selector" classes on the main page. This also avoids fixing the
CSS for future buttons if added (future proofing the code), so if any other
button is added in the future, the same css rule will be applied to it at once.
Very wise idea from @Jdlrobson, thanks!
Bug: T206406
Change-Id: Iedce84595adc357f3a707f8b94d23b2ffea3476c
It's presumed that skin options will eventually become the default or be removed from the skin.
While they are not the default, it would be helpful to package them in one single module - as ResourceLoader
modules are costly bloating the dependency graph in the MediaWiki startup module.
In T167713 we talked about grouping our entry points by page rather than feature, which this seems consistent
with. A page with special options enabled is different from a page without.
Change-Id: Id948f913d4743532ba3442d2059a03c122419ff2
String concatenation should use . operator, not +, otherwise it will
report some Warning
Bug: T195645
Change-Id: Id27c981622e5ed87519324193abd2249aa1df7b6
Instead of requiring a full IContextSource object and only using the
Title, only ask for the Title in the first place.
Change-Id: I33034193140ca53919f29f847a03caf26250ce54
Important note: Make sure to distinguish unseen from unread
One way to reproduce minerva and non-minerva notification inconsistencies:
- Have all your alerts and notices seen. This is displayed with grayed out
number on vector skin or no number at all, if you have (marked as) read.
- Generate new alert or notice (one is enough) in your preferred way.
- You can check minerva and non-minerva at this step. Both should be in sync.
But don't perform any additional action.
- Open the notification popup in some non-minerva skin (I have tried with
vector and monobook), marking it as seen.
- Check the notification icon in minerva. At this point, you should see
notification displayed as unseen.
The reason bug appeared in the first place is that alert/notice timestamps
were mixed up when seen time is obtained. We get seen time from
EchoSeenTime class, where we get smaller of the two timestamps,
using PHP method `min()`. See I27109ee6a248. Then, we get last unread
notification timestamp (which can be either alert or notice), and compare
that to seen time. That leads to the situation when you have only one of
alerts or notices with unread items, smaller timestamp is used for seen,
and most recent for unread, at which point we compare timestamps for
two separate things.
Previous behavior of getting seen timestamps (using max instead of min) would
probably solve the problem, but some other inconsistencies might arrise.
This should prevent any weird and unpredictable behavior to happen.
Bug: T183076
Change-Id: I20bbd6c590086b1c3eccf82983aad59eb3144a7a
Fontchanger code now runs on all skins under the `mobile` target.
All the code will now live in MobileFrontend meaning developers
can operate inside one code base.
Depends-On: I857cfe2d9be9fe49c04c860bc234384c787239b2
Change-Id: I2759455cb6d7ddf13798e94452cb74baf502bafe
Changes:
* Minerva now maintains a MinervaUI - a simplified version of
MobileUI that provides iconClass and buttonClass helpers.
* Minerva now maintains its own ResourceLoaderParserMessageModule
Remaining issues:
* Main menu links to '#'
* Unknown dependency errors are thrown due to the missing
JS libraries e.g. mobile.watchstar
thus JS based UI components are unusable e.g. search autocomplete,
and edit button
* Language button navigates to a missing special page without
MobileFrontend (see T104660)
Bug: T169569
Change-Id: I89e2e15faabab73b0cba91afc2f2c5e785edef29
Changes:
* Update docs
* Update browser test artifacts
* Update comments
* Update phpunit test groups
* Update phpunit test namespace
* Update `die` when MobileFrontend not installed
* Remove the migrate script which is no longer needed
Change-Id: I83432b3f7f0bcd07ed08259972b8ff89147104b6
Sniffs that are currently failing are disabled in phpcs.xml.
Additional changes:
* Fix problem in test file
Change-Id: I53642e9d7bc1ef96e359cfe04a8f93dabbc977eb
Test scenario for getContextSpecificModules() mocks only Skin->getTitle()
behavior, but while executing isAllowedPageAction() Skin will create a
UserPageHelper with default RequestContext. As RequestContext is not mocked,
$context->getTitle() will return undefined what could lead to tests crash
Changes:
- instead of mocking SkinMinerva::getTitle() pass test context with injected
title. Other tests will work properly as MediaWikiTestCase::tearDown() always
restes RequestContext to default
Bug: T170624
Change-Id: I872fddf8d9c52a6875bb6c69a12407a8125fba4c
This is programmatic output from python3 scripts/migrate.py
This will result in a Minerva skin dependent on MobileFrontend.
Post merge we will rename message keys to have minerva- prefix
Bug: T166748
Change-Id: Iff1f7e63e796cc5d4a6d2ab0370e0c33248d2fce