Template talk:User-multi

Template-protected edit request on 28 August 2024 xtools.wmcloud.org new URLs

https://xtools.wmflabs.org/ec/?username=Example&project=en.wikipedia.org now redirects to https://xtools.wmcloud.org/ec/en.wikipedia.org/Example . All 3 project = snippets.toolLang .. '.' .. snippets.projectLong .. '.org' queries should be adjusted from makeUrlLink to makeWikilink. The backports one of my improvements in {{UserM}} to {{User2}}. The new URL is both shorter and saves readers' browsers' some time redirecting. 142.113.140.146 (talk) 03:07, 28 August 2024 (UTC)

 Done Sohom (talk) 17:20, 31 August 2024 (UTC)

Show IP links

The script that displays Show IP buttons now supports those kinds of buttons in page content. I've made a change to support that in the module that powers {{checkuser}}. I'm looking to have similar done here in this module (to support {{vandal}}). What it basically does is change user links for TAs to contribs links. I tracked where the change might be needed down to Module:UserLinks#L-62. Wanted to get this in front of other people because this module gives the sense of being used in many places and to see if forking that implementation is really the best way (e.g. instead of doing it in this module just depend on Module:No pings instead). Izno (talk) 23:45, 11 December 2025 (UTC)

NB I solely pushed the change, it was lifted wholesale from phab:T412011#11443284. Izno (talk) 23:46, 11 December 2025 (UTC)

IPContributions

With the advent of temporary accounts, my initial instinct is to just add a new option (e.g., "ipc") so that nothing historic (stuff using "c") is broken, as something like {{Vandal|127.0.0.1}} still relevant for pre-TA ip contribs, for example. But more and more, I'm thinking anything post-TA-implementation that's mentioning actual IPs / IP ranges is probably going to want a link to Special:IPContributions rather than Special:Contributions. I think I've already caught myself a few times already going "huh? what contributions?" before realizing I wasn't where I thought I'd be. I was thinking the other option would be something like overwriting the existing behavior of "c" to account for IPs, but that seems like it's more intrusive and break-y. Any thoughts? --slakr^\ talk / 02:15, 20 March 2026 (UTC)

@Slakr I added "ipc" to the /sandbox, but I don't think we want to change the behavior of "c" because we don't want to break historic uses of the template (especially since Special:IPContributions times out after 90 days). For a template like {{Vandal}} where there's unlikely to be value in old uses the IP detection could be placed in the template itself to switch between "c" and "ipc", but for something like {{sock list}} we'd probably not want to use "ipc". --Ahecht (TALK
PAGE) 16:46, 27 August 2026 (UTC)

@Slakr  Done in main template. You can now use ipc. --Ahecht (TALK
PAGE) 15:15, 31 August 2026 (UTC)

User info card

Per mw:Help:Extension:CheckUser#User_Info_card_in_page_content, we now have the ability to add the same User Info Card that use used in places like the Special:Watchlist and Special:Contributions. I added two options to Module:UserLinks/sandbox: a uic code that will add the user info card as one of the links (e.g. {{User-multi|user=Ahecht|uic}} → Ahecht ()), and a |uic= parameter that will add the user info card before the username (e.g. {{User-multi|user=Ahecht|uic=true|t|c|e}} → Ahecht (talk · contribs · email)). The only catch is that if the uic code is used and a reader has user info cards turned off in their preferences, they will see a blank space in the list of links, but the |uic= parameter will fail more gracefully. If there are no objections, I'll copy it over to the main template. --Ahecht (TALK
PAGE) 15:27, 25 August 2026 (UTC)

There is a hack that could solve the blank space problem, namely putting the &nbsp;<b>·</b> inside of <span class="ext-checkuser-userinfocard-button">...</span> so it gets hidden along with the uic when the preference is turned off, but I'm not sure it's worth it. --Ahecht (TALK
PAGE) 17:20, 27 August 2026 (UTC)

 Done in main template and documented. I didn't implement the hack to hide the extra bullet. --Ahecht (TALK
PAGE) 15:15, 31 August 2026 (UTC)

@Ahecht: when adding the UIC to Module:Checkuser, I wrote a simple method which validates the input before calling {{#uic}}, and gracefully returns the empty string if it fails (rather than populating an error category). Objections to using that method here? Best, HouseBlaster (talk • he/they) 16:15, 8 September 2026 (UTC)

@HouseBlaster Good point, I forgot about the tracking category. I added a check to the template here and at {{Userlinks}}. Adding it to the module is a little less straightforward since the function that builds the final link doesn't have access to the username, and I'd want to preserve the error category for when someone deliberately adds the uic to the list of links (e.g. {{User-multi|user=Ahecht|uic}}). --Ahecht (TALK
PAGE) 16:59, 8 September 2026 (UTC)

Makes sense! Best, HouseBlaster (talk • he/they) 17:01, 8 September 2026 (UTC)

@HouseBlaster I noticed that pages were still getting added to that category after I implemented the fix above. The problem is that pages get added to the category for any invalid username, not just for valid IP addressess. Behind the scenes, it runs the username through the getCanonical() function of UserNameUtils.php and generates the category if that returns false. This means that something like 192.168.1.1/24 wouldn't be caught by {{#invoke:IPAddress|isIpOrRange|192.168.1.1/24}} because it's not a valid CIDR range, but would trigger that category since any username with a "/" is flagged as invalid by the UserNameUtils.php.

Long story short, I created Module:User name utils to replicate that code, so you can use require('Module:User name utils')._getCanonical(name) instead of require('Module:IPAddress')._isIp(name). --Ahecht (TALK
PAGE) 21:36, 9 September 2026 (UTC)

Amazing! Thank you so much. Looking at the docs, it looks like I want to use require('Module:User name utils')._isValid(name), rather than _getCanonical, for the verification check. Is that correct, or am I missing something? Best, HouseBlaster (talk • he/they) 22:05, 9 September 2026 (UTC)

@HouseBlaster The uic parser function uses getCanonical, so you'd want to use that as well. isValid will fail usernames that don't start with an uppercase letter, and won't fail usernames with "#"s in them. --Ahecht (TALK
PAGE) 03:10, 10 September 2026 (UTC)

Makes sense, Ahecht—I've updated Module:Checkuser. Thank you! Best, HouseBlaster (talk • he/they) 15:59, 10 September 2026 (UTC)