If you don't want to use the sidebar that monobook/vector/etc use, or want to add extra (user-customisable) navigation elements, there really isn't any backend support for this. There should be.
Jack Phoenix said something that went over my head. Perhaps he can clarify.
Version: 1.23.0
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Jdlrobson | T29292 Skinning system improvement (tracking) | |||
| Stalled | None | T62656 No sane way to make arbitrary nested menus when creating a skin |
There's a patch over at https://gerrit.wikimedia.org/r/#/c/108045/ which is apparently related.
I'd be interested in what a 1.35 version of this would look like and the problems it would solve.
Stalling until there's further information on this one.
Well, the problem is there isn't any consistent version of this. We don't know what it would look like because it doesn't exist... any skin that wants to do it basically just rolls its own logic, and this logic has historically been pretty flakey. The linked patch was to merge one of the most common implementations at the time into core, but to my knowledge that implementation no longer works at all, didn't fully support standard sidebars to begin with, etc.
The idea is to output navblocks (like the sidebar) with subnavblocks (portlet) in some standardised fashion across all levels. Currently, sidebars are rendered by every skin rolling its own handling for the overall sidebar container, and then only the portlet navblocks have any cross-skin consistency. And if this were standardised effectively, we might be able to do subnavblocks of those using the same layout... (useful for dropdown menus where such nesting can actually make sense, category trees, that kind of thing)
We don't know what it would look like because it doesn't exist... any skin that wants to do it basically just rolls its own logic, and this logic has historically been pretty flakey.
Why is a skin rolling its own code a problem?
It sounds to me like we should identify a common useful pattern first, before even considering standardizing it in core. I would suggest auditing existing skins doing this to see what they do to make this actionable.
I think if we are planning to do something akin to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/108045/19/includes/NestedMenuParser.php there are other things we should add (supporting icons for example). There are also some good ideas in Minerva by using classes for modelling Menus that IMO should be upstreamed to core first.
Utterly pointless code duplication everywhere, that's why. Of course skins can do that and in fact, it's literally what many of them are doing right now, but ideally core would have some reusable methods for things like these.
It sounds to me like we should identify a common useful pattern first, before even considering standardizing it in core.
Depends on how you define this, I guess, but from a(n end-)user/developer POV, "I want to make a nested menu" seems like a relatively basic task, and anyone with any WordPress experience would probably agree. Some of the WordPress ports, like Bouquet, DeskMessMirrored and Gamepress (all of which I maintain), implement support for such menus, but alas, the code is pretty much copy-paste between all three of those, and that's not really ideal.
I think if we are planning to do something akin to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/108045/19/includes/NestedMenuParser.php there are other things we should add (supporting icons for example).
Indeed, that'd be neat! Refreshed and some of the Bootstrap-based skins support some kinds of icons in their menus; for Refreshed the icon support is limited to content actions/toolbox, the actual sidebar (MediaWiki:Sidebar and friends) don't support icons.
There are also some good ideas in Minerva by using classes for modelling Menus that IMO should be upstreamed to core first.
Minerva's MenuBuilder was certainly a fascinating, novel approach to building menus the last time I checked it. :) This may have been fixed already, but at the time a major gripe of mine was that when using addComponent it's not possible to specify an ID, only a class or classes for the new menu element.
(all of which I maintain), implement support for such menus, but alas, the code is pretty much copy-paste between all three of those, and that's not really ideal.
Which functions in those skins should I be looking at? I assume these are the reusable methods you are looking for?
I've started specing out T272624 for a spec for menu 2.0 and would like to fold those ideas into there.