Page MenuHomePhabricator

Hackweek: full sidebar in Minerva
Closed, ResolvedPublic



We will be using this exercise as setting the groundwork for research on making changes in a fork of the vector skin (or the vector skin itself)

Questions to be answered

  • How would you go about building a full sidebar in Minerva?
  • How would we display wiki-specific sidebars?
  • What are the pros and cons of this approach?
  • What blockers may arise that we haven't yet thought of?


image.png (762×1 px, 510 KB)
image.png (1×1 px, 701 KB)


  • the menu has the same contents as the vector menu, it's just styled differently
  • I don't think the behavior is particularly important right now, but the menu state (open/closed) would be sticky, so if you open it up it would stay open, even on reload, or navigating to a different page
  • the width of the main header has also been increased. Again, maybe not important for this investigation.

Acceptance criteria

  • Research, prototype, document any and all thoughts, work and observations around the questions written above

Event Timeline

  1. Use the mediawiki-sidebar msg/object to generate the skin's navigation, as would be consistent with other MediaWiki skins, resolving T65459: Allow configuration of the Minerva menu. For the desktop layout, display it formatted as a css sidebar. Visually, this would happen by making the overall skin layout slightly wider, and plonking it in with some sensible styles.
  2. mediawiki-sidebar is the MediaWiki core-defined wiki-specific sidebar. It displays wiki-specific sidebars in all skins that use it as a sidebar, as each wiki customises its own sidebar via [[MediaWiki:Sidebar]]. Thus by resolving T65459 we also resolve this.
  3. Pros: this would be consistent in terms of both user expectation and backend handling with most other skins, including all other skins currently deployed in Wikimedia production. Cons: onwiki users sometimes do dumb things with their sidebar, and thus this would be impacted consistently with every other skin. Note, however, that wider mobile-targeted application should continue to push for users to do more sensible things in the first place and work on cleaning up what is already there, so this should be a self-solving issue, in time.
  4. Blockers may include fixes being needed for styling/behaviour of the mobile navigation in particular, both for the wider range of options that will need to be supported, and likely also for the different DOM if using generic sidebar generation for the output, as is generally advised and would be consistent with the other skins currently deployed.

(This might be slightly off as to just what the sidebar object is internally; I generally just do a $this->getSidebar(), and MonoBook apparently gets it with $this->data['sidebar'], which is probably the same thing but a tad messier. Personally I don't really recommend touching the QuickTemplate (?) data pile directly for much of anything if you have an abstraction option.)