Wikibooks:Reading room/Technical Assistance
| Discussions | Assistance | Requests | Announcements |
|---|---|---|---|
| General | Proposals | Projects | Featured books | General | Technical | Administrative | Deletion | Undeletion | Import | Upload | Permissions | Bulletin Board |
Welcome to the Technical Assistance reading room. Get assistance on questions related to MediaWiki markup, CSS, JavaScript, and such as they relate to Wikibooks. This is not a general-purpose technical support room.
To submit a bug notice or feature request for the MediaWiki software, visit Phabricator.
To get more information about the MediaWiki software, or to download your own copy, visit MediaWiki
There are also two IRC channels for technical help: #mediawikiconnect for issues about the software, and #mediawiki-coreconnect for WMF server or configuration issues.
- This follows-up from the April 2025 thread.
Hi,
As part of the Unified mobile routing rollout on Wikibooks yesterday, I'm auditing wikis for potential technical issues. The eachAsync is ready log message on page views drew my attention. This is part of a setTimeout-loop, waiting for an importScript, as ad-hoc dependency manager between it and the two callers (MediaWiki:Common.js/Toolbox.js and MediaWiki:Gadget-Special characters.js).
Both scripts adopted $.eachAsync in 2014 to speed things up (diff 1, diff 2). The code currently inside these async loops is small and fast by modern standards, so this actually makes things slower rather than faster, due to the overhead of so many timer allocations, function calls, and dedidated event loop tasks.
For Toolbox.js, I've turned the code back into a simple for-loop (edit).
Regarding Gadget-Special_characters.js, this gadget broke 9 years ago. The buttons don't do anything when clicked, because it relied on inline <a onclick=".." attributes, which MediaWiki has not used since this software change in 2016. Special:GadgetUsage says it has 0 active users at the moment, which is not surprising, then. I've upgraded MediaWiki:Edittools and MediaWiki:Gadget-Special characters.js (edit) to follow the latest documentation at mw:Extension:CharInsert#Scripting. The look the same as before, except they work now. So perhaps those of you who turned this off, may want to give this gadget another go.
With all that, I've archived jQueryAsync.js (edit). Note that if something similar is needed in the future, there are other approaches I would recommend instead:
mw.hook().fire()at the end of the destination script, instead of in Common.js. This way you don't need a setTimeout loop.mw.loader.getScript()with the full action=raw URL. This gives you a native callback for when the script has finished loading.- Define a hidden/default gadget in MediaWiki:Gadgets-definition. There you can bundle multiple pages together in a reliable way (e.g. jQueryAsync.js, and then Toolbar.js), and can be dependended on by other gadgets, such as Gadget-Special characters.js, in either the gadget definition or via
mw.loader.using(['ext.gadget.mygadget']).then(…);. Gadgets also enjoy greater performance in the browser by being strongly compressed and cached offline instead of requiring a server call for each file.
These are small and non-essential changes. Feel free to revert or ping me here if you need anything. Krinkle (discuss • contribs) 20:23, 24 September 2025 (UTC)
- Thank you! —Kittycataclysm (discuss • contribs) 14:44, 25 September 2025 (UTC)
- Krinkle, please see phab:T405862; I've filed a bug report that block log entries on mobile are difficult to read in this project. Codename Noreste (discuss • contribs) 21:19, 28 September 2025 (UTC)
- @Krinkle: Sorry about that bodge (I was the one who set up the jQueryAsync thing). Thanks for fixing the gadget! JJPMaster (she/they) 23:52, 22 October 2025 (UTC)
Requesting temporary unprotection to add a closing DIV tag. ShakespeareFan00 (discuss • contribs) 11:17, 26 October 2025 (UTC)
- I already added that closing tag for you.. Codename Noreste (discuss • contribs) 14:54, 26 October 2025 (UTC)
Categorytree display limit
[edit source]Hello! <categorytree> seems to have a built-in maximum display of 200 items. Does anyone know why this might be or where I could go to talk more about this? Maybe somewhere at MediaWiki, Meta, or Phabricator? Thanks! —Kittycataclysm (discuss • contribs) 19:12, 31 October 2025 (UTC)
- Looking at mw:Extension:CategoryTree, it appears that the default limit is 200, which is intentional. Codename Noreste (discuss • contribs) 19:33, 31 October 2025 (UTC)
- It looks like that's been the default limit since the first commit to the CategoryTree repo in 2006. In theory, potentially the enwikibooks community could request for that limit to be increased if it wanted; though I imagine that there might need to be some sort of performance assessment done before such a change is made, to ensure that it wouldn't result in a large negative performance impact to the wiki. (Then again, I couldn't immediately find a time where a change to this limit has previously been requested, so who knows what might happen! 🤷♀️)
In terms of somewhere to talk about it, potentially mw:Extension talk:CategoryTree? Though I don't know how many active watchers that page might have. Best, a smart kitten (discuss • contribs) 11:14, 1 November 2025 (UTC)- @A smart kitten thank you so much—this is super helpful! I was wondering if it might be possible to make it so that it displays a certain maximum number of items but has clickable arrows so the viewer could navigate through and see the rest of the items in the category. I'm not sure how that would be done on the back end or what limitations it might have; but, I know that being able to access all items in the category would be immensely useful for the Wikibooks Cookbook. Maybe it could be configured in the parameters when invoked? —Kittycataclysm (discuss • contribs) 02:59, 2 November 2025 (UTC)
- @Kittycataclysm I can't say that I'm that familiar with the CategoryTree extension personally, so I probably wouldn't be able to answer that question myself; but I found phab:T124596, in case what's written there matches what you're describing? If not, it sounds like a good feature request to file :)
(FYI, I don't know if CategoryTree is being actively developed at the moment, so it might take some time for anyone to look into and/or code that feature; though - if T124596 doesn't match what you're thinking of - I'd still encourage you to file a request if it's something you'd like to see.) - Alternatively (or in addition), if there is something enwikibooks-specific that would benefit from a larger CategoryTree 'max children' limit (e.g., if it'd be helpful for the Cookbook), if you wanted to, you could start a discussion to see if there's community consensus for requesting an increase to that limit. If you do that, I'd personally recommend including specific example/s of what the issues caused by the current limit are, and how they would be resolved by a proposed increased limit (both for the benefit of folks on enwikibooks, and for people on Phabricator considering the request). If there was consensus to request this sort of change, the worst I can think of that might happen is that it'd be declined (or just be stalled for ever and ever 😅). Best, a smart kitten (discuss • contribs) 14:38, 2 November 2025 (UTC)
- @A smart kitten Thank you again! I have filed a feature request at T409002. I am currently the primary maintainer of the Cookbook, and Wikibooks is fairly low-activity, so I think trying to get a community consensus wouldn't really be useful or reflective of necessity. I think the utility is still fairly evident, so hopefully it will be considered. Cheers —Kittycataclysm (discuss • contribs) 15:41, 2 November 2025 (UTC)
- @Kittycataclysm I can't say that I'm that familiar with the CategoryTree extension personally, so I probably wouldn't be able to answer that question myself; but I found phab:T124596, in case what's written there matches what you're describing? If not, it sounds like a good feature request to file :)
- @A smart kitten thank you so much—this is super helpful! I was wondering if it might be possible to make it so that it displays a certain maximum number of items but has clickable arrows so the viewer could navigate through and see the rest of the items in the category. I'm not sure how that would be done on the back end or what limitations it might have; but, I know that being able to access all items in the category would be immensely useful for the Wikibooks Cookbook. Maybe it could be configured in the parameters when invoked? —Kittycataclysm (discuss • contribs) 02:59, 2 November 2025 (UTC)
- It looks like that's been the default limit since the first commit to the CategoryTree repo in 2006. In theory, potentially the enwikibooks community could request for that limit to be increased if it wanted; though I imagine that there might need to be some sort of performance assessment done before such a change is made, to ensure that it wouldn't result in a large negative performance impact to the wiki. (Then again, I couldn't immediately find a time where a change to this limit has previously been requested, so who knows what might happen! 🤷♀️)
Statistics permalink does not save Data Type (monthly vs daily)
[edit source]I notice that the web app for statistics defaults to daily sums, even in the permalink. For example, the permalink for the usage Statistics for the Wikiboook on OpenSSH shows daily sums even when the permalink button was clicked while viewing monthly sums. I would expect that the GET request created would show monthly sums when that happens. The current override to the daily sums is problematic because when monthly sums are selected, the dates are also overwritten and must be selected anew.
Could the web app please be tweaked so that the 'permalink' button creates a URL which will retrieve monthly sums, when applicable? Larsnooden (discuss • contribs) 09:51, 1 November 2025 (UTC)
- Checking with @Leaderboard @JJPMaster @Codename Noreste —Kittycataclysm (discuss • contribs) 03:17, 2 November 2025 (UTC)
- We need to ask the maintainers of the web app instead - maybe @MusikAnimal can help here? Leaderboard (discuss • contribs) 04:52, 2 November 2025 (UTC)
The current override to the daily sums is problematic because when monthly sums are selected, the dates are also overwritten and must be selected anew.
This is something that can be fixed. I will try to look into it when time allows. I am not able to reproduce the issue you mention involving the permalink button, however. MusikAnimal (discuss • contribs) 05:44, 2 November 2025 (UTC)- Thanks for looking into the overwritten dates. As for reproducing the problem, it happens every time in Brave v1.84.132 from Oct 29, 2025, but it's not a new problem. Larsnooden (discuss • contribs) 09:29, 2 November 2025 (UTC)