Talk:MoreMenu

If a bug deserves prompt attention, please {{ping}} the active maintainer, User:MusikAnimal

Archives

---

Not getting "More" menu

Hello, I am not able to see the "More" menu on the Read / Edit menu options bar. But, I am seeing the "Pages" menu now.

I added MoreMenu in Preferences, Gadgets.

I also followed the first two instructions at MoreMenu

• Installing globally (recommended)
• English Wikipedia extension

Do you know why I might not be seeing the "More" menu?

Thanks in advance.CaroleHenson (talk) 17:23, 12 October 2023 (UTC)

@CaroleHenson The links that were formerly under "More" are probably under "Page" or "User" now (i.e. "Move page"). If there are links you think are missing, let me know, otherwise I think this is expected behaviour. — MusikAnimal ^talk 17:28, 16 October 2023 (UTC)

MusikAnimal, Hi! Thanks for your reply. I am not able to find it anywhere. I have looked at all possible menu places - uppermost left menu (main menu) - uppermost right menu (user talk, etc. options), Pages, Tools, and Twinkle. I looked at everything that could conceivable lead to an edit tool, and haven't found anything.CaroleHenson (talk) 00:25, 17 October 2023 (UTC)

I forgot to clarify. I am looking for AutoEd, and their literature says it's at "More" menu, which got me going down this avenue.CaroleHenson (talk) 00:27, 17 October 2023 (UTC)

@CaroleHenson Oh, if you see "Tools" then you're probably using Vector 2022. There is no "More" menu in this skin. Is it not listed in that menu? — MusikAnimal ^talk 02:30, 17 October 2023 (UTC)

MusikAnimal, I changed my preference to "Timeless" and I see the AutoEd menu. Thanks so much!CaroleHenson (talk) 05:36, 20 October 2023 (UTC)

Add class instead of raw style

Just noticed Filtering options contains a style property for "Custom CSS to apply to the link." (how is this a filter, btw?). This immediately sets off my yuck-reflex for passing raw CSS around and setting inline styles. How about encouraging good practice by providing class for adding a custom class instead? (well, "in addition to" rather than "instead of", probably, since there are times the separation of concerns isn't practical, but…) Xover (talk) 08:52, 15 March 2024 (UTC)

Each item already has an ID, so you can just add CSS via mw.util.addCSS() or mw.loader.addStyleTag(). Nardog (talk) 01:38, 17 March 2024 (UTC)

Sure, but since you can only have one of each ID that makes for pretty yucky selectors, and targeting IDs makes the cascade unnecessarily difficult. Xover (talk) 12:18, 17 March 2024 (UTC)

Would an auto-generated CSS class be better? I'm happy to deprecated the style option, per your reasoning. It's not a "filter" but an option and I needed to document it somewhere. Feel free to reword things on that page. — MusikAnimal ^talk 20:37, 19 March 2024 (UTC)

I assume Xover is asking for an option to add non-autogenerated class(es) in addItem(), like classes in mw.notify() or OOUI constructors. Nardog (talk) 00:16, 20 March 2024 (UTC)

Right. Or rather, I'm saying that allowing raw CSS in |style= is a bad practice and it would be better to encourage good practice by providing |class= instead to fill that need. I don't have an immediate use case for it, but depending on how some other stuff shakes out I have one user script which would need to style its links and I expect I'd want this option then. Xover (talk) 07:32, 23 March 2024 (UTC)

Dropdowns framework?

I'm about to (ab)use MoreMenu for its side-effect of providing a convenient way to add menus to Vector 2022 (instead of reverse-engineering the markup and associated scaffolding and boilerplate to fix the user scripts and Gadgets written for Vector Classic). But that's kinda a lot of overhead for just that functionality, and not all users of the other Gadgets necessarily want all of MoreMenu (I'll probably make it default anyway, but it'll still be opt out-able).

So it occurs to me… could the "adding a menu dropdown to the supported skins" bits of MoreMenu be abstracted out to a "addMenu API" that other Gadgets could use?

Every time the menu markup in the skin changes (Vector Classic did this twice, at least, and Vector 2022 reinvents it yet again; not to mention supporting the other skins is a pain in the rear) there's scattershot of gadgets across projects that break, and since they use different approaches they have to be grokked and fixed individually (and since I'm not an IA on Commons I'm reduced to making protected edit requests there for the gadgets we cross-load like bigChunkedUpload). Having this stuff break one place, and being fixable in one place, would be a wast improvement to the status quo.

It'd be nice if the WMF decided to upstream the MoreMenu/Advanced API, but, you know, [insert rant about institutional priorities here]. While waiting for that I'd love to be able to just mw.loader.using("ext.gadget.menu-framework") and get .addSubMenu() and friends to play with. Xover (talk) 09:12, 15 March 2024 (UTC)

Incidentally, that would also make for slightly simpler client code as you don't have to hang on the moremenu.ready hook. For one of the gadgets I have in mind I want to fire off an Action API request whose returned pages will be added to a menu. Which currently means I'll have to figure out how to synchronise one event and one callback, possibly chained due to continue, without access to async/await (ES7/ES8) and, hopefully, without deferring starting the Action API request until after the moremenu.ready hook fires. All workaroundable, but it's complication I would much rather not have to deal with in each gadget with this need. Xover (talk) 11:18, 15 March 2024 (UTC)

You're not the first to ask for this! Indeed upstreaming to MW will likely not happen anytime soon, and perhaps never for some of the skins that aren't supposed to have "dropdowns".

I'd like to work on making a library, but I won't have time for it in the near-term. I guess for now, proceed with using MoreMenu's API if you wish, and later I can ensure the standalone library works in the same way for backwards compatibility. — MusikAnimal ^talk 20:41, 19 March 2024 (UTC)

I'm pretty sure I saw @Jdlrobson and co. iterating in a Phab somewhere about standardising and abstracting the menu framework for all the skins, presumably due to the new PinnedHeader stuff in Vector 2022, which I took to mean we'll eventually get a mw.util.addDropdown() to go along with mw.util.addPortlet() and mw.util.addPortletLink(). But, you know, like most of the good stuff like that, stalled for the usual reasons.

In any case, thanks for looking into this. I'll see how far I get on the callback+hook+continue synchronisation mess before give up, grow a beard and disappear up in the mountains to get away from technology. :) Xover (talk) 07:50, 23 March 2024 (UTC)

Oh, heh heh, it was probably T303859 and the linked discussion I was thinking of. Nevermind. :-) Xover (talk) 07:54, 23 March 2024 (UTC)

We built this already, no?

https://www.mediawiki.org/wiki/ResourceLoader/Core_modules#addPortlet Jdlrobson (talk) 14:02, 23 March 2024 (UTC)

@Jdlrobson: So far as I can tell, mw.util.addPortlet() is a utility function for generating some HTML (which may or may not be tuned to the current skin, the docs don't say) with an optional shortcut for calling jQuery.insertAfter() on it afterwards. The HTML generated seems to be for creating a sub-section within one of the existing sidebars in Vector 2022, or at any rate it does not seem to generate a dropdown menu as a sibling of the "More" menu and MoreMenu's "User" and "Page" menus, nor a submenu within those menus.

What I'm trying in my inept way to describe is something like a mw.util.addMenu() that lets you put a new dropdown menu up by the page tabs, and being able to mw.util.addMenuItem() on it to add links (possibly with click handlers on them). Preferably also the ability to mw.util.addSubmenu(), because sometimes that's the only way to avoid excessively long lists of menu items.

Or put another way, I'm looking at three different gadgets (written by others, now inactive) that did this in Vector Classic (through reverse engineering markup etc., obviously) and that are now broken in Vector 2022. For all three of them I really don't want to invest the effort to reverse engineer the markup structure and hack this together just to have it break again the next time the markup changes (which happened with Vector Classic at least twice that I know of). Xover (talk) 08:45, 24 March 2024 (UTC)

It should be better documented but "Note about appending portlets in different locations" mentions that you can mimic styling. If you pass #p-cactions it creates a dropdown in the Vector skins.

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/Vector/+/6f06af8ebbbf687a30a3e8b92d5817221b0c6677/resources/skins.vector.js/portlets.js#104 Jdlrobson (talk) 14:19, 24 March 2024 (UTC)

@Jdlrobson: Ok, after doing some digging… Man what a mess this is!

I've ported one of the old scripts to it, and I see you've fixed the other for the user that was cross-loding it to enWS, and it works great for what it is. So let me start by expressing gratitude that you all have added it and are tackling this area, because I am now going to gripe, at length, about it below. :)

mw.util.addPortlet() was never announced in Tech News that I can find, and you need to read through the whole history of about 15 Phab tasks to find out that this is deployed and working, and, crucially, why it works the way it does.

The docs at mw:ResourceLoader/Core_modules#addPortlet only kinda sorta makes sense after reading up on the history (and preferably reading the implementation in mediawiki.util/util.js). It's even got an incorrect docstring for the before argument ("selector of the element preceding the new portlet" should presumably be "selector of the element the new portlet should precede"). I've tried adding some docs about the dropdown use case at #Dropdowns (Vector-only), but I'm sufficiently confused that I'm not at all confident I got it right.

Even after reading through all that it is still not clear why mw.util.addPortlet('foo', 'bar', '#p-cactions') puts a dropdown in #right-navigation on the tab bar, while the actual #p-cactions lives down in the right sidebar (modulo pinned/unpinned). Reading between the lines I'm assuming Vector 2022 is special-casing that and moving it around, but I'd presumably need to reverse-engineer what skins.vector.js/portlets.js:addPortletHandler() is doing to find out for sure.

And speaking of "stuff xover is too dumb to figure out"… This stuff is really really challenging my ability to build a conceptual model of how it works. #p-cactions is in the "Tools" menu, which can be pinned as a right sidebar. But to get a dropdown "in #right-navigation" (which is my mental model of what I'm doing) I need to ask for a portlet "before #p-cactions" which Vector 2022 will then put in the tab bar as a dropdown. With mw.util.addPortletLink() you ask for the link to be placed inside a given portlet, but with mw.util.addPortlet() you ask to be placed "before" the seemingly-totally-unrelated next area after the one you want to be in. And how that behaves depends on the two areas having the same immediate parent, because the code literally make you siblings in the DOM.

All of which is a really long-winded way to say that I think this stuff needs better and more specific API, that abstracts the HTML structure and styling away, and that provides deterministic (and documented) behaviour across skins. I'm not sure whether that is in scope for the "menus overhaul" I see alluded to in some of those Phab discussions, but if not it should be (and I can provide mock documentation for the API I'd want if it'd be useful). Xover (talk) 16:11, 29 March 2024 (UTC)

When releasing it we were primarily targeting MoreMenu and Twinkle to confirm the API we'd built solved those problems so we didn't advertise it in case we wanted to remove it (e.g. we weren't 100% sure this was the right thing to build).

If we are seeing usage and evidence that's it helpful I agree we should try and simplify and better document some of this magic. The thing that is complicated here is only Vector 2022, Vector, Timeless and Minerva have concepts of dropdowns and Monobook, CologneBlue and Modern don't and it would be confusing to have a method mw.util.addDropdown which didn't create a dropdown in all skins.

It's a marathon not a race so I created phab:T361661 to follow up here and improve this further - feel free to add any more thoughts there! Jdlrobson (talk) 02:54, 3 April 2024 (UTC)

Keyboard shortcuts go missing

It looks like when MoreMenu is active the keyboard shortcuts for move, delete, and protect (the ones defined in MediaWiki:accesskey-ca-move, MediaWiki:accesskey-ca-delete, and MediaWiki:accesskey-ca-protect) go missing. Possibly because MoreMenu doesn't use the #ca-move, #ca-delete, and #ca-protect IDs for those menu items (I'm not sure how MW assigns those accesskeys). See Help:Keyboard shortcuts and mw:Manual:Access keys. I also couldn't find any way to assign accesskeys for MoreMenu's default menu entries. Xover (talk) 11:54, 30 March 2024 (UTC)

Your tool docs are featured as an example in the new Tool Docs Guide!

Hello MoreMenu maintainers, contributors, and fans! I wanted to let you know that I highlighted the MoreMenu documentation as a shining example in the new Tool Docs guide that I just published. Thank you for creating lovely tool documentation that can serve as an example to help others create and improve tool docs :-) This guide was created as part of the Doc Your Tool project for the upcoming 2024 Hackathon. If you're interested, please join that project to work on or talk about tool documentation during the hackathon! TBurmeister (WMF) (talk) 16:54, 16 April 2024 (UTC)

Awesome! I'm thrilled to hear the docs are deemed well-written enough to serve as an example. Thanks for featuring MoreMenu :) — MusikAnimal ^talk 17:48, 16 April 2024 (UTC)