▶️
Mind if I join you?
It has been suggested that this page or section be merged with another one.
Reason given: Should probably be merged with Project:Admin noticeboard.
Discussion to support or oppose the merge should be on this article's talk page, usually under the heading "Merge".
This page should be used to request modifications to the technical systems behind Dota 2 Wiki.
MediaWiki[]
- 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)
Extensions[]
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)
- 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)
The following requests are low-priority:
- Uninstall mw:Extension:InputBox. AFAICT it is unused on this wiki. --Kroocsiogsi (talk) 23:53, 28 June 2014 (UTC)
- InputBox is a default extension across all Gamepedia. We cannot uninstall it on just one wiki — Game widow (talk) 16:15, 14 June 2015 (UTC)
- Uninstall mw:Extension:W4G Rating Bar. AFAICT it is unused on this wiki. --Kroocsiogsi (talk) 23:53, 28 June 2014 (UTC)
- Uninstall mw:Extension:ClientSide and mw:Extension:CommunityVoice. AFAICT they are unused on this wiki. --Kroocsiogsi (talk) 23:53, 28 June 2014 (UTC)
- Uninstall mw:Extension:FlashMP3. AFAICT it is unused on this wiki. --Kroocsiogsi (talk) 23:53, 28 June 2014 (UTC)
- Uninstall mw:Extension:MediawikiPlayer (not to be confused with the "blessed" pair of media handlers, mw:Extension:mwEmbedSupport + mw:Extension:TimedMediaHandler). AFAICT it is unused on this wiki. --Kroocsiogsi (talk) 23:53, 28 June 2014 (UTC)
- The 5 above extensions have been removed — Game widow (talk) 16:15, 14 June 2015 (UTC)
- I saw MediaWiki Widgets on help.gamepedia.com. Does Curse want to push MediaWiki Widgets? If so, I think it would be pretty easy to also ditch mw:Extension:EmbedVideo as well. --Kroocsiogsi (talk) 23:53, 28 June 2014 (UTC)
- We neither push nor condemn Widgets. — Game widow (talk) 16:15, 14 June 2015 (UTC)
- Update mw:Extension:MsUpload. I don't particularly like it, but as long as people are using it we should have a version that works with IE. --Kroocsiogsi (talk) 23:53, 28 June 2014 (UTC)
- MsUpload was updated about a month or two ago. — Game widow (talk) 16:10, 14 June 2015 (UTC)
- Ensure that $wgPFEnableStringFunctions is enabled, then uninstall mw:Extension:StringFunctions. It is obsoleted by mw:Extension:ParserFunctions (already installed) and magic words. AFAICT it is no longer necessary on this wiki. Gamepedia appears to be one of the last big farms that still has StringFunctions installed. Since uninstalling StringFunctions seems like it's the sort of thing that might cause widespread bustage due to unforeseen circumstances, it should probably be tested first. --Kroocsiogsi (talk) 23:53, 28 June 2014 (UTC)
- StringFunctions 2.0.3 is enabled on this wiki — Game widow (talk) 16:10, 14 June 2015 (UTC)
- Think about replacing Sphinx + mw:Extension:SphinxSearch + mw:Extension:TitleKey with Elasticsearch + mw:Extension:Elastica + mw:Extension:CirrusSearch. This is not pressing, but Wikimedia has thrown their support behind CirrusSearch. --Kroocsiogsi (talk) 23:53, 28 June 2014 (UTC)
- We ditched Sphinx in favour of Elastica 1.3.0.0 some time ago — Game widow (talk) 16:10, 14 June 2015 (UTC)
- Think about installing mw:Extension:Thanks, perhaps on all Gamepedia wikis. I think it might be a "cheap" way to create a positive atmosphere and encourage editors. I've been happy with its effects on Wikipedia. --Kroocsiogsi (talk) 06:48, 9 July 2014 (UTC)
- Passed along for consideration — Game widow (talk) 16:17, 14 June 2015 (UTC)
Configuration[]
- 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[]
- 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)
- 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 www.dota2wiki.com for "mantle of intelligence", I do NOT end up at the page "Mantle of Intelligence". If I search en.wikipedia.org 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> http://www.mediawiki.org/wiki/Extension:TitleKey
- 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 talk 07:32, 5 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)
- Variables update from 1.3 to completely rewritten 2.0.1. --Kroocsiogsi 02:00, 17 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 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 talk 00:48, 14 January 2012 (UTC)
- Update SoundManager2Button to version 0.3.2. I am the maintainer of this extension. --Kroocsiogsi 03:16, 20 April 2012 (UTC)
- Request submitted (April 20th) -- Wynthyst 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)
- I request that some group permissions pertaining to AbuseFilter be changed. Specifically, I request that
abusefilter-view
,abusefilter-log
, andabusefilter-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:Robjackson 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 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 haveabusefilter-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)
- Exactly! :-) I have no intention of changing
- 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 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 talk 09:06, 10 August 2012 (UTC)
- Just as soon as you fix the typos (
abuse-filter
toabusefilter
) we can close this out. --Kroocsiogsi 07:16, 15 December 2012 (UTC)
- Just as soon as you fix the typos (
- Looking over your permissions structure, here are my recommendations for changes User:Wynthyst/User group permissions. Please keep the discussion here. -- Wynthyst talk 09:06, 10 August 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 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 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 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)
- I have submitted the request. It has been placed on the dev queue to be implemented after the holiday break. -- Wynthyst talk 21:48, 16 December 2013 (UTC)
|