Page MenuHomePhabricator

[Page Tools] [SPIKE] Move page tools to menu in page toolbar
Closed, ResolvedPublic5 Estimated Story Points

Description

NOTE: No blockers for this work

Background

We would like to investigate the approach we would like to take and identify potential risks for the removal of the page tools from the main menu and their addition of page tools to the "more" menu.

Requirements

  • All page tools must appear under the more/explore more menu
  • Page tools must be able to later move to a pinnable state (see prototype, to be tracked in a separate ticket)
  • The list of page tools must be configurable by the community similar to list of links on the main menu
  • The definition for the default list of page tools is as follows:

    link definition:

TOOLBOX (minus special pages)

  • What links here
  • Related changes
  • Special pages
  • Permanent link
  • Page information
  • Cite this page
  • Wikidata item

+

  • Edit interlanguage links
  • Downaload as PDF
  • Printable version

Prototype: https://vector-2022.web.app/Moth

Acceptance criteria

  • Identify which of the above definitions of page tools carries the least risk
  • Identify what approach must be taken for moving the page tools to the more menu
  • Identify what approach must be taken to make the page tools menu configurable by communities
  • Identify any blockers and dependencies with the above steps

Event Timeline

From the list in the description I wouldn't consider the Special pages element would be fine in the more menu. I don't know which should be the best location for that link if the idea is to remove the current box completely, but it shouldn't be by default in the list of article tools. It's not even related to the current article...

LGoto set the point value for this task to 5.
How targeted menu links are built

Looking into how the proposed link definitions are created, there are a number of ways these menu items are inserted into the sidebar in Vector:

  • Toolbox links
$sidebar['TOOLBOX'] = $this->makeToolbox(
	$this->buildNavUrls(),
	$this->buildFeedUrls()
);
Identify which of the above definitions of article tools carries the least risk

I understand "least risk" to mean the easiest, simplest ones to move which are the links generated by code we maintain - i.e. those that are built by Skin::makeToolbox(). These are available to whatever template we specify so What links here, Related changes, Special pages, Permanent link, Page information and Printable version, as well as Edit interlanguage links should be relatively straightforward to output to a different template.

Identify what approach must be taken for moving the article tools to the more menu

In terms of approach, for the links that are built within the Skin classes, it looks like SkinTemplate::getPortletsTemplateData() is where we invoke Skin::buildSidebar() and create the data-portlets-sidebar key of the $data array. For other skins that utilize this sidebar area, presumably we need to keep all this current functionality. For modern Vector, if we simply want to move those menu items to a new location, we could intercept the sidebar data array in SkinVector22::getTemplateData(), manipulate it (do we move everything over? maybe only specified/known menu items should move over?), and re-package the relevant data to a new template partial for the "more" menu.

By the time SkinVector22::getTemplateData() is called, presumably all the backend hooks (a note about the frontend hook in the blockers section below) that can intercede have been run so whatever 3rd parties have injected into the sidebar or the toolbox should be available to SkinVector22.

For Edit interlanguage links in particular, there is a note in the code that the js is a temporary solution until the new ULS is built in Vue. Until then, we can just append the link to the new menu id.

Identify what approach must be taken to make the article tools menu configurable by communities

I'm making the assumption that this means something like https://www.mediawiki.org/wiki/MediaWiki:Sidebar wherein admins can utilize a wiki page to change the article tools menu. I don't know what it takes to build one of these interfaces but presumably it can be done for this use case.

From what I've been able to deduce (h/t to @nray), the sidebar contents are comprised by an i18n message and can be overridden. I do not know if this is the only way to create an editable interface for any given menu. More details TK.

Identify any blockers and dependencies with the above steps

Because the relevant Skin methods and hooks for the targeted links explicitly name "sidebar", it could be confusing/misleading to continue to use these hooks to populate the new "more" menu dropdown. They will continue to be used by legacy Vector and other skins which will want to keep these menu items in their sidebar regions in which case the nomenclature isn't an issue.

For the "more" menu specifically, we may want to create a new hook for this dropdown or group of menu items for 3rd parties to inject links. If we were to do this however, it would be on the 3rd parties to have to keep track of which hooks they use and which menus they want to change. And we would have to decide whether to include the menu items injected by sidebar hooks or limit them to a new hook for this specific menu.

If however this group of menu items are functionally similar enough to live together wherever they are placed, then moving all of them over wholesale (including all 3rd party injected items) seems like an easier lift than having to write logic to separate/sift out what should move over and what should stay in the pin-able sidebar menu.

To address the specific frontend hook mw.util.addPortletLink() -- there are a number of instances in MediaWiki codesearch where extensions are using this hook to inject an item into the toolbox (p-tb) specifically. To move any of these over to the new "more" menu likely requires custom javascript to identify and intercept them. Not necessarily a blocker per se but we would have to address this use case separately from the backend hooks.

There also appears to be a number of menu extensions - https://www.mediawiki.org/wiki/Category:Menu_extensions. I'm not sure how many of them affect the sidebar menu but for those that do, there's a question of how this proposed change will affect the features they purport to enable.


One thing to keep in mind as a backdrop to all this is that we have noted in our Q1/Q2 OKRs to improve the menu architecture. In theory this work will make it much easier and less obtuse to extend menus by 3rd parties and communities. If we were to take on this effort of moving the article tools menu before this menu re-architecture work is complete, it's likely that we will need to refactor whatever short-term solution we put in place shortly thereafter.

cjming moved this task from Doing to Code Review on the Web-Team-Backlog (Kanbanana-FY-2021-22) board.
cjming subscribed.

Moving to backlog for now, since our focuses are elsewhere. @cjming I'll pick up reviewing this later when it's a priority again.

Just in case, I'll leave it here :) It seems to me that you can use a standard sidebar with additional special words that will transfer blocks from one side to the other.

--LEFT--
* navigation
** mainpage|mainpage-description
** content-url|content
** featured-url|featured
** randompage-url|randompage
** currentevents-url|currentevents
** sitesupport-url|sitesupport

* SEARCH

* participation
** bug_in_article-url|bug_in_article
** introduction-url|introduction
** portal-url|portal
** forum-url|forum
** recentchanges-url|recentchanges
** newpages-url|newpages
** helppage|help

--RIGHT--
* TOOLBOX
* coll-print_export
* Projects
Jdlrobson renamed this task from [SPIKE] Move article tools to "more" menu to [Article Tools] [SPIKE] Move article tools to "more" menu.Sep 15 2022, 4:12 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson lowered the priority of this task from High to Low.Sep 19 2022, 5:30 PM

(these have previously been estimated)

I've split out T318434 on the recommendation that toolbox might be the least risky. Thanks for that assessment! After we've done that we can worry about other menus.

Regarding gadgets:

to address the specific frontend hook mw.util.addPortletLink() -- there are a number of instances in MediaWiki codesearch where extensions are using this hook to inject an item into the toolbox (p-tb) specifically. To move any of these over to the new "more" menu likely requires custom javascript to identify and intercept them. Not necessarily a blocker per se but we would have to address this use case separately from the backend hooks.

This should just work, provided we retain the p-tb element ID in the new sidebar.

Regarding MediaWiki:Sidebar I'm not seeing any blockers here to actually building out this menu. I've made a note to investigate that later: https://phabricator.wikimedia.org/T318435

Thanks for the detailed analysis @cjming I'll let someone else in the team sign this off in case they have any follow up questions.

alexhollender_WMF renamed this task from [Article Tools] [SPIKE] Move article tools to "more" menu to [Article Tools] [SPIKE] Move article tools to menu in article toolbar.Sep 28 2022, 4:52 PM
Mabualruz updated the task description. (Show Details)
alexhollender_WMF renamed this task from [Article Tools] [SPIKE] Move article tools to menu in article toolbar to [Page Tools] [SPIKE] Move page tools to menu in page toolbar.Oct 25 2022, 7:20 PM