Tech
Tech-related questions about third-party wikis should be asked at mw:Project:Support desk. |
A place to talk about tech related to a Wikimedia wiki.
Have a technical wiki question? Ask here. This can include, for example:
- requests for new tools, scripts, and bots;
- help with CSS or JavaScript;
- API help;
- and data collection help (including database queries).
If you are not using the "New topic tool", such as the "Ask a question" button above, please sign manually using four tildes (~~~~), or by clicking on the signature icon 
; this will automatically generate your name and the current timestamp when you publish your changes.
Strange technical behaviour at Talk:Community Wishlist on mobile
[edit]When visiting Talk:Community Wishlist on Mobile, even when logged in the little person icon doesn't display in the top right corner and there is no page history or watchlist icon (I have noticed this for months). There is an "expand all" button in the three dots that fails. I am not sure if a transclusion is causing it or it is a MediaWiki bug. Incidentally, a working "expand all" button would be handy on c:COM:HD. Commander Keane (talk) 22:12, 18 March 2025 (UTC)
- @Commander Keane: At a first impression, sounds potentially similar to what was reported as phab:T383272 - does what's described in that task's description match what you're seeing? (In addition, purely out of curiosity, does refreshing the page on mobile help at all?) All the best, —a smart kitten[meow] 00:05, 19 March 2025 (UTC)
- Yes refreshing did fix it. I have seen the phab:T383272 behaviour on other pages and now I understand it is caused by special page transclusion. I guess Talk:Community Wishlist is the page I visit the most that has a special page included! Thanks for finding the phab task.
- I found phab:T358733 that has a gif of the expand all toggler bug. The task is open and medium.
- I am not sure why the toggler doesn't appear at Commons in the three dots (could be my local prefs?), but it doesn't work anyway so not a current issue.
- I will wait for bug fixes :-). Commander Keane (talk) 00:44, 19 March 2025 (UTC)
CS1 error messages on SWWP
[edit]Dear Team,
Currently we are facing too many CS1 error messages. See the list below;
- https://sw.wikipedia.org/wiki/Jamii:CS1_errors:_unsupported_parameter
- https://sw.wikipedia.org/wiki/Jamii:CS1_errors:_dates
- https://sw.wikipedia.org/wiki/Jamii:CS1_errors:_redundant_parameter
What bothers me is that, it's the same references used on the English Wikipedia, does not cast any error messages but once dropped into SWWP, all hell broke loose. Please assist. How to fix this?
Wasn't there before. User:Muddyb (Talk) 18:01, 25 March 2025 (UTC)
SMW Wikibase compatibility to the latest SMW and Wikibase
[edit]I am currently in the process of setting up a local Windows environment using MediaWiki version 1.42.3, along with Semantic MediaWiki (SMW) version 5.0.0 and Wikibase version REL1_42. My objective is to implement two crucial functions via plugins:
-Enable MediaWiki pages to query both Wikibase data and SMW data through parser functions or Sparql, and then display this data correctly.
-Allow MediaWiki to display and create Wikibase data via the Page Special: New Property and Property: P1 page, including Items and properties. Also, enable SMW to query Wikibase data. However, I have run into a significant compatibility issue when it comes to displaying Wikibase property data. I'm aware that there are relevant plugins like the Semantic Wikibase plugin that could potentially solve this problem. Unfortunately, its latest version is 0.1.0, and it appears to have not been updated for a long time. As a result, it is not compatible with the current SMW version I'm using.
I'm reaching out to inquire if there are any alternative methods or updated plugins available to achieve the functions mentioned above. Given the incompatibility situation I'm facing, it's crucial to find a solution that can work well with my current MediaWiki, SMW, and Wikibase versions.
ZJY20242023 (talk) 19:30, 25 March 2025 (UTC)
- Hi. This page is for Wikimedia wikis only. Please see mw:Project:Support desk instead and read the "Post a new question" section at the top there. Thanks. Quiddity (WMF) (talk) 18:03, 27 March 2025 (UTC)
Magic word to suppress the upward links at the upper left of a page?
[edit]Hi,
Near the upper left corner of Oberon/Introduction you probably see a navigation link "< Oberon" provided by MediaWiki. Also, navigation buttons "Support", "Oberon front page" and "Historical perspective" are provided by my code. With these buttons, the navigation link from MediaWiki is redundant and I wonder about suppressing it.
The NOTOC magic word suppresses the table of contents. Therefore I imagine a magic word to suppress the automatic navigation link. Hypothetically it might be named NONAV.
I know that for my own viewing, the MediaWiki link can be suppressed with a line in the User:me/common.css page. That won't help casual readers who should see a page without redundant information.
Thanks for considering this suggestion, ... PeterEasthope (talk) 14:35, 27 March 2025 (UTC)
- FYI, it looks like a feature request for such a magic word is currently being tracked in Phabricator as phab:T41395, in case you're interested in following/subscribing to that task :) Best, —a smart kitten[meow] 15:17, 27 March 2025 (UTC)
Please add "last edit" date + time to generated/downloaded PDF.
[edit]Hello!
Wonderful job with Wikipedia/Wikimedia envolution. The "Download PDF" button is the BEST function! I connect to Internet at a shared location, so I have to download and read stuff later. Sometimes I forget to copy the "Last edit" notice from the bottom of the original article to paste into my printed PDF. (I prefer to have this info and to record the year in my book manager.)
So I hope some volunteers would consider modifiying the "Download PDF" function to include the "Last edit" time. Currently it is NOT included, you only see it at the bottom of the original page.
Thank you very much for your time and consideraton. Have a terrific day! 67.63.58.242 17:38, 28 March 2025 (UTC)
Some problems in mobile view with infoboxes on simple.wikipedia
[edit]On mobile view on Simple English Wikipedia, certain contents on infoboxes don't appear centered as they are supposed to. I believe this problem started several weeks ago. For example: https://simple.wikipedia.org/wiki/Sabrina_Carpenter shows the photo and the line "musical career" centered on desktop view, but left aligned on mobile view. Also https://simple.wikipedia.org/wiki/London shows the line "capital city" centered on desktop view but left aligned on mobile view. The problem doesn't exist on English Wikipedia although Template:Infobox appears the same, so I don't know what's causing this. Could someone please help? TagUser (talk) 22:00, 30 March 2025 (UTC)
Temporary Accounts: how to update your code
[edit]Because Temporary Accounts will be rolled out this year, the Trust and Safety Product team is sending this communication to help to ensure that tools, gadgets, bots, user scripts, AbuseFilters, and any other community-maintained code continue to work smoothly.
What are Temporary Accounts?
Temporary accounts are a new type of account for unregistered editors. When a logged-out user attempts to make an edit, they will have a temporary account assigned to them, and will be logged-in to this account. Tools that focus on workflows for logged-out users might need updates to function correctly. Tools that make use of IP addresses from logged-out editors will not work, and functionality needs to be rewritten to use temporary accounts. Temporary accounts are already live on some pilot wikis, with the full rollout on all wikis this year.
How you can help:
- Check if code (whether on Toolforge or on wiki, that is: tools, gadgets, bots, or user scripts) you created or frequently use works on the wikis where temporary accounts are already active. Here is the list of content wikis, and here is the list of beta cluster and test wikis with temporary accounts.
- If you notice a tool that might be impacted, we encourage you to try updating it based on our developer documentation guide. We would also kindly ask you to file a Phabricator task with the tag #temporary-accounts. This will allow us to monitor the impact of our changes on the community-owned code.
- Do add the tools you see as impacted on this page. We want to monitor them to make sure that everything is working as expected.
- Take a look at Abuse Filters used on your wiki. Any filter using IPs via user_name will no longer be able to do so. Those filters need to be updated to use the user_unnamed_ip variable instead. A comment from our engineers: "The main use case should be if you try something like ip_in_range(s). Things that map to usernames should be broadly ok, as they’ll continue to map to temporary account names." If you have more questions about AbuseFilter, you may add a comment on the Phabricator ticket T369611.
- If you find any issues or have comments or questions, let us know on the project talk page or file a Phabricator task with the tag
#temporary-accounts. You can also join the dedicated English Discord thread (make sure to join the server first) for support and to share feedback to the team.
By helping test and report, you will ensure important tools work smoothly with this update. Thanks for your support!
Udehb-WMF (talk) 14:32, 2 April 2025 (UTC)
- So does this mean?
- If multiple IP addresses from an IPv6 /64 range make bad edits, I won't be able to ask for the range to be blocked
- If an IP address vandalizes continuously (whether over a period of minutes, or a period of days), I won't be able to give them warnings and then report them at all, because I will have no way to know they're the same IP address
- Even admins won't be able to do these things
- 1 is bad, 2 is worse, and 3 is even worse. TagUser (talk) 17:30, 2 April 2025 (UTC)
- Hey @TagUser, thanks for the comment. I believe you are making some incorrect assumptions. There is a Diff post walking through the basics of the project, basic functionality, etc. I highly recommend reading it.
- In the meantime, I'd like to clarify that you will be able to ask for the temp accounts to be blocked, and if you meet some criteria (which we are tweaking now, based on conversations with stewards and some 20 largest Wikipedia communities) you will also be able to preview these accounts' IP addresses.
- In any case, admins will be able to see both and block just the temp account, or the range, or both. (I'm not sure if you are familiar with autoblock - it does apply to temp accounts.) SGrabarczuk (WMF) (talk) 17:54, 2 April 2025 (UTC)
- Ok, so now I understand this makes it easier to track ordinary disruptive editors and harder to track malicious experienced editors. That's probably a good thing overall. TagUser (talk) 19:48, 2 April 2025 (UTC)
Adding alternate taglines to a wiki
[edit]How technically feasible is allowing per-page taglines? On enwiki we have the metadata gadget, which uses JavaScript calls to an article's talk page to change the tagline to A featured article from Wikipedia, the free encyclopedia or similar when the article is a piece of featured content. I'm wondering if there's any ability to do similar using MediaWiki tools within the article rather than a JavaScript gadget. Given that all featured content already has a template to signify its status, they could each make calls to some tagline changer a la DISPLAYTITLE. More context can be found at en:w:Wikipedia:Village pump (idea lab) § Metadata gadget as the default experience.
I've found mw:Extension:CustomSubtitle, but I can't tell its development status or whether it's installed on enwiki. Also, I don't know if it'd be "safe" to allow how it currently works, given that it allows freeform text in the new tagline. Maybe a more elegant solution would allow something similar to how tagline currently works, for instance the text of the tagline at a subpage like MediaWiki:Tagline/Featured Article and featured content templates making a call like {{DISPLAYTAGLINE:Featured Article}}? Dan Leonard (talk) 20:45, 10 April 2025 (UTC)