Page MenuHomePhabricator

Menus 2.0: Simplify how we modify menus in MediaWiki
Open, MediumPublic

Description

There are various problems with skin menus. There are menus across the MediaWiki interface - in the footer, sidebar, personal tools, but all use different hooks. This task suggests a long term plan for how to simplify the current skin ecosystem for registering and modifying menus.

Note: many skins have built their own menu systems, e.g. Minerva has a MenuBuilder class, and certain skins want nested menus (e.g. T62656). We will look to these for guidance.

Suggested spec (draft)

Required

  • Extensions and skins can register new menus
  • There will be one hook for modifying menus. This will replace all existing hooks SidebarBeforeOutput, SkinTemplateNavigation::Universal, SkinAddFooterLinks and PersonalUrls
  • It should be possible to use the hook to model and edit the footer, categories, sidebar, user personal menu (think Vector 2022 user dropdown), namespace tabs (Article | Talk), action tabs (edit, watch etc..) and more menu (the more dropdown that shows in Vector)
  • It should be possible for menu items to have icons associated with them
  • Links that depend on page existence must be preloaded to avoid numerous database queries. For the footer this is currently done using Skin::preloadExistence but should be extended to also be considered in the generation of the sidebar (See T299099 for more context).

Nice to have

  • It should be possible to modify any menu using a mediawiki page. Currently, only the sidebar is modifiable on wiki via MediaWiki:Sidebar, but for skins that have custom menus e.g. CologneBlue's home menu only hook options exist.

Event Timeline

Jdlrobson renamed this task from Simplify how we modify menus in MediaWiki to Menus 2.0: Simplify how we modify menus in MediaWiki.Jan 21 2021, 7:05 PM
Jdlrobson added a project: Epic.

Suggest returning data for menus (and categories, indicators, etc.) instead of html to allow the most flexibility in templating.

Specifically, html-items is currently returned:

{
    "data-logos": {
        ...
    },
    ...
    "data-portlets": {
        ...
        "data-personal": {
            "id": "p-personal",
            "class": "mw-portlet mw-portlet-personal",
            "html-tooltip": "",
            "html-items": "<... List of menu links already formatted in html ...>",
            "html-after-portal": "",
            "label": "Personal tools"
        },
        ...
    }
    ...
}

However, an array of html attributes (array-links) should be returned:

{
    "data-logos": {
        ...
    },
    ...
    "data-portlets": {
        ...
        "data-personal": {
            "id": "p-personal",
            "class": "mw-portlet mw-portlet-personal",
            "html-tooltip": "",
            "html-after-portal": "",
            "label": "Personal tools",
            "array-links": [
                {
                    "userpage": {
                        "single-id": "pt-userpage",
                        "href": "\/w\/User:Username",
                        "class": false,
                        "text": "User Name",
                        "dir": "auto",
                        "exists": true
                    }
                },
                ...,
                ...,
                ...,
                ...,
                ...
            ]
        },
        ...
    }
    ...
}

This would allow skin developers the most flexibility for css and styling with the Mustache template. This approach should also be expanded to html-tooltip and html-after-portal as well as any other html returned from SkinMustache::getTemplateData.

Jdlrobson triaged this task as Medium priority.Feb 14 2022, 8:49 PM
Jdlrobson updated the task description. (Show Details)

Suggest returning data for menus (and categories, indicators, etc.) instead of html to allow the most flexibility in templating.
[...]
This would allow skin developers the most flexibility for css and styling with the Mustache template. This approach should also be expanded to html-tooltip and html-after-portal as well as any other html returned from SkinMustache::getTemplateData.

I agree with this; this would make generating menus much easier.

Would it be possible to add some kind of short description associated with the menu item?
It will be useful for providing additional context as secondary text or tooltip.

Secondary textTooltip
image.png (496×471 px, 61 KB)
PXL_20220523_184348211.jpg (1×928 px, 780 KB)

^ (Sorry for potato screenshot, I can't screenshot title tooltip properly)

Additionally, certain core menu items have keyboard shortcut associated with them
Should this project allow adding. removing, or editing keyboard shortcuts?

Hey all! Just a heads up we'll working on T311647 over the next 3 quarters, which documents our goals for completion of this work. We're hoping to see a lot of improvements in menu support - particularly around making sure keyboard shortcuts just work and moving away from blobs of HTML (all backwards compatible of course!)

IF anyone is interested in helping contribute code, please subscribe to the phabricator task and feel free to poke any subtasks there with offers of help :-).