Dota 2 Wiki:Technical requests

From Dota 2 Wiki
Jump to: navigation, search

This page should be used to request modifications to the technical systems behind Dota 2 Wiki.


  • MediaWiki 1.21 is now unsupported. MediaWiki 1.23 is the stable release; it also happens to be a LTS release. I hope Curse admins have 1.22 or 1.23 in the pipeline. --Kroocsiogsi (talk) 01:47, 22 June 2014 (UTC)


The following requests are medium-priority:

  • Update Semantic MediaWiki to 2.0. I think this will take a long time. You might want to wait until after you upgrade MediaWiki. For my information, have we already migrated to SQLStore3, or will we wait until installing SMW 2.0? If we haven't, there are, in theory, performance gains. --Kroocsiogsi (talk) 23:53, 28 June 2014 (UTC)
Update: It appears that SMW 1.9.2 will be installed. I hope admins know what they’re doing, as SMW 1.9.2 wasn’t designed to be forward-compatible with MW 1.23. It looks like it works, but SMW 2.0 (formerly known as SMW 1.9.3) improved compatibility. Godspeed, gentlemen. --Kroocsiogsi (talk) 07:30, 9 September 2014 (UTC)
We are looking into totally revamping SMW this year. The actual details have not yet been finalized. — Game widow (talk) 16:10, 14 June 2015 (UTC)

The following requests are low-priority:


  • Remove the namespaces "Guides" and "Guides talk". They are unused. --Kroocsiogsi (talk) 00:46, 25 June 2014 (UTC)
Done — Game widow (talk) 16:06, 14 June 2015 (UTC)

Fulfilled requests[edit]

  • ConfirmEdit - captcha to keep the bots away. I guess setting it up to use re-captcha (see this) would be sufficient. RJackson 20:55, 8 September 2011 (CDT)
    • No longer necessary thanks to Abuse Filters. -RJ 23:25, 26 November 2011 (UTC)
Just an FYI, all MediaWiki friendly captchas have been broken by most bots for quite awhile now. They tend to only be an annoyance to legitimate users these days, so we normally don't use them any longer. -- Wynthyst User Wynthyst sig icon.png talk 07:35, 5 January 2012 (UTC)
  • ImageMap for clickable regions in images
  • Enable $wgAllowDisplayTitle in LocalSettings.php (I think) - that way translated pages can have their titles be the localised string for whatever they're documenting, instead of "Wafflesauce/es".
  • TitleKey so searching for "mantle of intelligence" will take you to the page "Mantle of Intelligence". --Kroocsiogsi 06:57, 28 November 2011 (UTC)
Conversation at #mediawiki:
[22:37] <Kroocsiogsi> I'm confused about the search box, and how it works with capitalization. If I search for "mantle of intelligence", I do NOT end up at the page "Mantle of Intelligence". If I search for "battle of britain house", I DO end up at "Battle of Britain House". Why?
[22:38] <Kroocsiogsi> Is there a MediaWiki setting or extension that causes that to happen?
[22:38] <varnent> Wikipedia uses an extension that corrects this
[22:39] <varnent>
Request submitted. -- Wynthyst User Wynthyst sig icon.png talk 07:51, 5 January 2012 (UTC)
Installed. -- Wynthyst User Wynthyst sig icon.png talk 18:05, 25 January 2012 (UTC)
  • W4G_Rating_Bar so that we can eventually add a section for guides. -Lancey 17:33, 17 December 2011 (UTC)
Request submitted per my talk page. -- Wynthyst User Wynthyst sig icon.png talk 07:32, 5 January 2012 (UTC)
Installed -- Wynthyst User Wynthyst sig icon.png talk 18:04, 25 January 2012 (UTC)
  • SoundManager2Button for use on Hero response pages and possibly item infoboxes. I am the maintainer of this extension. --Kroocsiogsi 00:10, 5 January 2012 (UTC)
Request submitted. -- Wynthyst User Wynthyst sig icon.png talk 07:51, 5 January 2012 (UTC)
Installed. -- Wynthyst User Wynthyst sig icon.png talk 18:04, 25 January 2012 (UTC)
  • Variables update from 1.3 to completely rewritten 2.0.1. --Kroocsiogsi 02:00, 17 January 2012 (UTC)
I think this will happen automatically with the 1.18 upgrade, as we look at all the extensions and make sure they are upgraded to the most current version. -- Wynthyst User Wynthyst sig icon.png talk 02:01, 17 January 2012 (UTC)
Installed -- Wynthyst User Wynthyst sig icon.png talk 18:04, 25 January 2012 (UTC)
  • 1.18, for an improved editing toolbar and better gender support, among other improvements. At the very least, the 1.17.1 security release. --Kroocsiogsi 02:07, 5 January 2012 (UTC)
This is not going to happen for quite awhile. Just an FYI. -- Wynthyst User Wynthyst sig icon.png talk 07:30, 5 January 2012 (UTC)
It sounds like the team is going to go straight to 1.18, and are preparing the development server to start the process. They will be starting with the larger wikis and working their way down the list. I have not been given any timeline, but I will try to get a site notice up as soon as I find out. -- Wynthyst User Wynthyst sig icon.png talk 00:48, 14 January 2012 (UTC)
Request submitted (April 20th) -- Wynthyst User Wynthyst sig icon.png talk 21:20, 26 April 2012 (UTC)
Thanks! --Kroocsiogsi 17:29, 27 April 2012 (UTC)
  • One our user want to change his nickname, we need an easy extention for it. Renameuser. Thanks. Faraday 18:59, 27 June 2012 (UTC)
Use the Merge/Delete option already available. -- Wynthyst User Wynthyst sig icon.png talk 12:29, 28 June 2012 (UTC)
  • I request that some group permissions pertaining to AbuseFilter be changed. Specifically, I request that abusefilter-view, abusefilter-log, and abusefilter-log-detail be granted to all users (*). The configuration can be seen at the AbuseFilter extension page. There are many wikis that do this, notably the English Wikipedia, so I don't think it's a security or privacy concern. The reason I request these permissions is that we have had several comments about trigger-happy abuse filters, and I am concerned that we may be handing out some permanent IP blocks (and account creation disabling) to good editors. Being able to see the actual edits that trigger the abuse filters may help us identify improvements to the current filters. User:RJackson previously requested and was granted permission to review the AbuseFilter logs, but I think the job has turned out to be too large for one person, and I don't want to nag. --Kroocsiogsi 19:09, 4 August 2012 (UTC)
Keeping them private, keeps botters from getting around them. Any admin can view the details of the edits being blocked. Since an admin would need to unblock, I don't see the problem here. But if that's what you guys want, where's the discussion about this? -- Wynthyst User Wynthyst sig icon.png talk 21:23, 4 August 2012 (UTC)
Exactly! :-) I have no intention of changing abusefilter-private, which would allow botters to inspect the details of filters that are marked as private. Those are currently restricted to bureaucrats and curse, and I don't see a reason to change that. (For an example of the difference, notice how you can see the details of this public filter, but not this private filter.) You are not quite correct that admins (aka sysops) can see the details of blocked edits; currently only bureaucrats and curse can do that. You are likewise not quite correct that admins are necessary to unblock users; moderators like myself can do that as well. However, even if a certain user did not have blocking rights, the purpose of allowing that user to see the details of blocked edits would be so that he or she could inform moderators about wrongful blocks. This is necessary because the current users who have abusefilter-log-detail (i.e. Curse + RJackson) are not AFAIK even attempting to monitor wrongful blocks. (I don't blame them!) For example, I unblocked Teh0mega even though I wasn't able to see the edit for which he was blocked; I just made an educated guess based on his history that it was wrongful. I didn't start a discussion because I didn't figure anybody would oppose it, but I'll go ahead and start one now. --Kroocsiogsi 23:30, 4 August 2012 (UTC)
Follow up: here's the discussion I started. --Kroocsiogsi 00:05, 5 August 2012 (UTC)
  • While investigating the above issue, I discovered that Bots have all the rights of Mods. Currently Bot rights are granted more loosely than Mod rights, so that's a potential "backdoor" for Bot maintainers. Luckily, I think all our current Bot maintainers are trustworthy people. ;-) However, perhaps Bot rights should look more similar to the list at Wikipedia. I'll invite our one-and-only rights-setter (RJackson) in here to comment. Maybe it's intended. --Kroocsiogsi 23:44, 4 August 2012 (UTC)
I was not aware of this; it certainly does need to change. Bots should have the same permissions as regular contributors, but without rate / api limits. Some bots do not need moderator rights for their assigned tasks, and for the sake of security they shouldn't inherently have those rights; if a bot needs access to those rights, I can change their rights on-the-fly as necessary. -RJ 00:02, 5 August 2012 (UTC)
My Response to BOTH issues
I apologize for my misunderstanding. We have a "standard" set of permission configurations that we use on the rest of our wikis, and when I initially responded, it was with those in mind. I forget that you guys do things "your own way" rather than the Curse way in almost every single configuration. :P I will go through all your user permissions and get them squared away. I will post a list in my userspace of my conclusions, and request your input before making the changes live. I'm not sure I fully understand the difference between "Adminstrator" and "Moderator". If you could clarify that for me a bit it would be helpful. Most wikis run a 2 tier administrative structure, not 3. I do agree that Bots should NOT have block rights, though I'd like to leave them with Delete rights if that is ok with you. -- Wynthyst User Wynthyst sig icon.png talk 08:00, 10 August 2012 (UTC)
Looking over your permissions structure, here are my recommendations for changes User:Wynthyst/User group permissions. Please keep the discussion here. -- Wynthyst User Wynthyst sig icon.png talk 09:06, 10 August 2012 (UTC)
Just as soon as you fix the typos (abuse-filter to abusefilter) we can close this out. --Kroocsiogsi 07:16, 15 December 2012 (UTC)
  • mw:Extension:SoundManager2Button should be updated from version 0.3.1 to version 0.3.4. We used to have 0.3.4 installed, but it was downgraded during a server move. If I remember correctly, the changes in 0.3.3 were actually made at Curse's request, so it's a little odd that nobody noticed. --Kroocsiogsi (talk) 08:33, 17 November 2013 (UTC)
  • Is it possible to install a branch of WikiEditor that includes this fix? WikiEditor is bundled, so a new version of MediaWiki might contain that fix already; I'm not sure. --Kroocsiogsi (talk) 08:41, 17 November 2013 (UTC)
We are upgrading to MW v 1.21 on Tuesday, let's see if that resolves the problem. -- Wynthyst User Wynthyst sig icon.png talk 09:10, 17 November 2013 (UTC)
That's convenient. --Kroocsiogsi (talk) 09:13, 17 November 2013 (UTC)
  • DynamicSettings, which is part of Curse Extensions, contains in siteglobals.js:
   if ($('#localNotice').length > 0) {
   var localNoticeMD5 = md5($('#localNotice p').html());

When a #localNotice is present without a #p, $('#localNotice p') will return null, and md5 will throw an exception. This has knock-on effects due to resourceloader. Please fix the logic. Thanks. --Kroocsiogsi (talk) 07:43, 22 November 2013 (UTC)

The upgrade to 1.21 was delayed a week, but both of these issues should be resolved once it's completed. -- Wynthyst User Wynthyst sig icon.png talk 04:07, 26 November 2013 (UTC)
  • Please update SoundManager2Button to version 0.3.5, the first new version in about a year. It's hot off the presses, fixing a large bug that surfaced due to a change in how extension scripts are loaded asynchronously, as well as other fixes. Here's the latest snapshot. Thanks. --Kroocsiogsi (talk) 12:10, 15 December 2013 (UTC)
I have submitted the request. It has been placed on the dev queue to be implemented after the holiday break. -- Wynthyst User Wynthyst sig icon.png talk 21:48, 16 December 2013 (UTC)
Sounds good, judging from what feedback I've received. No more janky loads. Thanks! --Kroocsiogsi (talk) 23:45, 14 January 2014 (UTC)