Guild Wars Wiki talk:Requests for technical administration

Archive

---

• Resolved issues
• Feb 2007 - Nov 2007
• Jul 2007 - Jun 2008
• Jul 2008 - Dec 2008
• Jan 2009 - Jun 2009
• Jul 2009 - Nov 2009
• Year 2010

Extension:Collection

I wanted to suggest the Extension Collection to be installed onto both wikis. Primarily GW, because it would be really nice to be able to export pages into a PDF for offline reading (like for a Kindle or any other eReader.This extension was made by PediaPress, and through them you can even convert an entire wiki into a physical book. But PDF is enough. If combo'd with 2 other extensions you can even export to DocBook XML and ODF (opendocument), allowing for conversion to other formats from those to like EPUD or Mobi which makes it even better for eReaders and the like. A perfect example could be the Lore section of the wiki, and add in all the sub-pages to to make a good amount of reading offline for those that wish to learn about the lore. The only forseeable negative I can think of is maybe a space/bandwidth/processing issue on the server when generating the PDF, ODF, and XML (PDF creation is handled off server by PediaPress.com). I haven't really looked into if there is a purge option or a "don't save PDF for longer than 24 hours"-like option. It is also very easy to install by the looks of it.

Extension:Collection -- Working Example ### Optional: Extension:OpenDocument_Export - Extension:XML_Bridge

I dislike these extensions. They make it all too possible to publish. Call me crazy, but I've seen game guides on sale on ebay that are created using these extensions and that is a violation of copyright. These extensions would make it virtually impossible to control. -- Wyn talk 07:16, 8 March 2011 (UTC)

It's not that much harder to publish stuff right now. It would take me maybe 1 hour to write a script using the open wiki API to pull everything I need from the wiki and generate a PDF locally. http://wiki.guildwars.com/api.php is the location to the API that is open on all Wikis by default, and I am not even sure if you can turn off the API access. Second, if you go to http://pediapress.com/collection/ and use the "Send to PediaPress" Bookmark on the page, and go to any page on this wiki or the GW2 wiki, you can generate a book ANYWAY. So it is already possible to do it, and those that would do it, already know about it. [Daegalus - talk] 12:04, 13 March 2011 (UTC)

So there is no need for these extensions then either. -- Wyn talk 14:01, 13 March 2011 (UTC)

Yes and no, while I can do that, the extension allows you to generate PDFs or other digital formats for ebook readers, smartphones, etc and allow you better chances to read it. Plus you don't have to pay for it. Second, while I can use the API, the extension preserves the formatting, images, and other information better. The API can achieve the same results but its more finicky and the API is in beta, its not 100% up to par to what this extension could generate since it has backend access to generate the pages. The way you are saying it is why have search extensions in the wiki when you can use Google to search this wiki? Because its faster, better, and more to the point. [Daegalus - talk] 08:42, 14 March 2011 (UTC)

Open requests

Just to quickly summarize things that are open: Upgrade to 1.16(.2), installation of MWSearch, installation of SpecialInterwiki (2 sections up, could use a real requestpage written up), installation of AbuseFilter (mentioned on Poke's talk page, could use a real requestpage), assorted settings and extensions carried over to GW2W... Leaving off the Collection extension in the section above (since it hasn't been agreed on one way or the other yet) and actual bugs/slowness (issues for the bug page), have I missed anything here? - Tanetris 19:07, 25 February 2011 (UTC)

I fully agree with this, though I would like to add that there is also a new version of ParserFunctions that also requires the addition of StringFunctions to make sure that all parser functions are covered in 1.16. -- Wyn talk 07:21, 8 March 2011 (UTC)

No Wyn, ParserFunctions does not require StringFunctions. poke | talk 09:14, 8 March 2011 (UTC)

Is #replace used anywhere on GWW? -- Wyn talk 18:25, 8 March 2011 (UTC)

As we do not have StringFunctions installed, it isn't used, no. poke | talk 18:27, 8 March 2011 (UTC)

Ok... so I'm dumb. I just know that we have had to have both because the string functions included in the new parser functions hasn't been all inclusive. My bad.. I trust you to know what's best for GWW. -- Wyn talk 18:31, 8 March 2011 (UTC)

Ok.. what about reCaptcha? since that is also one that was approved by Anet but never installed. -- Wyn talk 18:33, 8 March 2011 (UTC)

The sooner reCaptcha is implemented, the sooner Jon can take a break from the ubiquitous spam bots. They've been growing this past while. G R E E N E R 02:39, 10 March 2011 (UTC)

Yes, reCaptcha is still highly needed. --Dominator Matrix 04:11, 10 March 2011 (UTC)

Keep in mind that reCaptcha was broken by bots in January, so the spambots you are seeing are not going to be deterred much. If anything, they simply stop uploading images unless you are going to require recaptcha when anyone creates a page. -- Wyn talk 14:03, 13 March 2011 (UTC)

Could we use reCaptcha for the uploading of images, creation of new pages, and possibly a couple others for non-autoconfirmed users? And no, I hadn't heard the code had been broken, but to what degree? Was it found to be possible to break, or found to be broken with relative ease? G R E E N E R 17:57, 13 March 2011 (UTC)

(Reset indent) Coming into this discussion a bit later, but wondering what happened to the idea of enabling the StringFunctions? There can be times when being able to manipulate a string within a template can prove useful, however perhaps there's some reason why these were not enabled? --Wolfie (talk|contribs) 00:07, 1 June 2011 (UTC)

Search engine

Hi there, about MWSearch: the technical team would prefer not to instal that extension, in order to avoid increasing the servers' load (or, reducing the servers' performance). They are however investigating the possibility to use an alternative such as Google Custom Search Engine. Would this extension be acceptable to the wiki community? Regarding the reCaptcha extension, there should not be a problem. --Stephane Lo Presti talk 16:40, 29 March 2011 (UTC)

I for one do not want a google search engine. Sorry. -- Wyn talk 17:17, 29 March 2011 (UTC)

If that means replacing the standard mediawiki search engine. I dont like the idea. If we can use both. I have no problem with it. --Sharkinu 17:52, 29 March 2011 (UTC)

The extension does nothing else than searching for search term site:wiki.guildwars.com; this works directly on google too. In addition it adds a second search box. Personally I don't like this suggestion. If one wants to search with google then they are free to do that, externally. Otherwise the wiki search engine has more benefits (namespace selection etc.), and when we can't improve that one (with a Lucene engine, which we don't get), then I would rather stay as we are now. poke | talk 18:26, 29 March 2011 (UTC)

I agree with Wyn and Poke: keep the current tool unless we can improve what we have now.  — Tennessee Ernie Ford (TEF) 18:59, 29 March 2011 (UTC)

Seconding the above. What we have works; I'm hesitant to add or change anything to the search function, from a personal perspective. -- Traveler (talk) 19:34, 29 March 2011 (UTC)

AbuseFilter Update

I would like to put in a change for an update to the abusefilter settings. Right now, it self-throttles at around 5% of edits hitting the filter. During a sustained vandal bot attack, filters can easily go past that threshold. I would like to propose increasing the threshold, if not removing it altogether. --JonTheMon 16:29, 3 September 2011 (UTC)

Before removing it, what benefits does self-throttling offer the wiki? Is it mainly decreasing server load? G R E E N E R 17:19, 3 September 2011 (UTC)

No. Mostly it's in case a filter runs amok and prevents too many edits. --JonTheMon 18:02, 3 September 2011 (UTC)

I don't know if it's possible (as there are probably server constraints), but what would be a good value in your opinion? --Stephane Lo Presti talk 16:48, 6 September 2011 (UTC)

Well, it would require a configuration change, but it shouldn't be too complex. To completely disable it, I would set DisableThreshold to somewhere north of 1. A more conservative (higher threshold, not disabled) would be 0.4 or 40%. --JonTheMon 16:51, 6 September 2011 (UTC)

I'm inclined to agree with disabling it entirely. We have plenty of good, active sysops to keep an eye on new filters/filter changes to make sure they don't block more than they're meant to block and to refine them as necessary, making any threshhold superfluous at best, and a vulnerability at worst. - Tanetris 23:17, 6 September 2011 (UTC)

Any more opinions before I make a formal request? --JonTheMon 18:47, 8 September 2011 (UTC)

When I mentioned the suggested AbuseFilter update, our technical team replied that they don't think it's a good idea because a misconfigured filter rule could block all edits on the wikis. That being said, we can still move on with this update if you think this is acceptable. At this point, I'd like to be sure that everyone is onboard with this update. Let me know if you have any more questions. --Stephane Lo Presti talk 22:33, 19 September 2011 (UTC)

Speaking as a non-admin, I trust the current admin team to be able to use AbuseFilter appropriately. I prefer taking the small risk that a sysop might make a mistake rather than risking what might happen if they don't have the tools to prevent/react to bot storms.

Comparing the worst cases, an AbuseFilter issue might prevent people from editing the wiki for 24 hours, but a insufficient tools issue might result in the wiki having corrupted articles until the oddixiL tech team can take time to respond. Other wikis use the plugin successfully even though their admins are less stellar than ours. – Tennessee Ernie Ford (TEF) 23:58, 19 September 2011 (UTC)

Yes, if it is misconfigured and ignored, bad stuff can happen. But if the community trusts that the admin team will be on top of it enough, it should be fine. At the least I'd like a raise in the limit, but as per the request, if we ever have to invoke a broad filter for wide-scale, persistent vandalism, even that won't be enough. --JonTheMon 18:13, 20 September 2011 (UTC)

I agree that it's much better to have it than not, I'll just make sure to stay away from the filters :P ~FarloTalk 03:27, 22 September 2011 (UTC)

Sorry for not copying here what I said on the IRC channel: I've asked our team to go ahead with this. Hopefully it'll happen before next week (there's a very small update where we're updating 2 extensions to their latest versions). --Stephane Lo Presti talk 16:03, 22 September 2011 (UTC)

I added a second configuration change to the request to reduce the automatic block from 'indefinite' to '3 days'. It is a short, standardized block length, anything beyond that can be handled by admins, and allows us to actually utilize the tool. --JonTheMon 19:03, 29 September 2011 (UTC)

Should we ask for an updated ParserFunctions?

→ moved from Guild Wars Wiki talk:Community portal

This Wiki is using Version 1.1.1 of the Parser Functions extension, which does not provide any functionality for string manipulation. The next version (1.2.0) integrates some functions from the StringFunctions extension, which would be very useful to have in a couple of templates.

Why would we need string functions?

Stripping the suffix from an article name

Nahpui Quarter (explorable area) -> Nahpui Quarter.

This is useful in a couple of cases:

• Drop the suffix from nicholas's location on the front page. This week "Nahpui Quarter (explorable area)" is somewhat of a strain for the layout.
• Drop the redundant suffix on Vanquisher and other articles with template-generated links.
• automatize Template:Location disambiguation. Currently, the basename has to be passed manually; as a result, use of the template is ill-maintained, often broken or replaced with Template:otheruses. If we could derive the basename from %PAGENAME%, it'd be possible to push forward a smarter version which will usually require no more than a simple {{Location disambiguation}} at the top of the page.

Strip Wiki-Markup from template parameters

[[Ruby]] -> Ruby

• To auto-categorize to Category:Contains Ruby, the [[ ]] need to be stripped.
• Some existing templates are notoriously messy with some parameters. String-Functions would allow us to sanitize the parameters for a more consistent display and categorization, without changing each and every single template invocation.
• Dito for template calls like raresalvage = [[Ruby]]<br>[[Sapphire]]. Auto-categorization into Contains Ruby and Contains Sapphire requires either reworking all template invocations to raresalvage1 = Ruby | raresalvage2 = Sapphire, or access to string functions to search for substring matches.

Work around some wiki-"features"

Minister Cho&#39;s Estate -> Minister Cho's Estate

• Mediawiki changes certain characters into html entities in some cases, which can cause templates to subtly fail for poor old Cho's article. Access to String-replacements would help us fix that.

Lots of other uses on GWW

• no, really, we'll find more uses for these in time. I've likely forgotten one or two cases where I thought "Damn, if only I had string functions!".

Lots of uses on GW2-Wiki

• Since the GW2-Wiki is using the same software version as this one, any upgrade would likely be done on both wikis to keep them in sync. As the GW2-Wiki continues to grow, I'm sure more uses for smart templates with string manipulation will be found.

What impact would the update have on the wiki?

I've checked out the source code from ParserFunctions 1.1.1 (svn revision 30587) and 1.2.0 (svn revision 50997) and read all differences, the changes are:

• Translation updates
• addition of more testcases (only relevant for extension development)
• minor fixes for newer php version (date related)
• one performance optimization
• addition of the string functions

In other words, as far as I can tell, this upgrade won't change existing behavior, it just adds new functionality. Since the new functionality is a 1:1 mapping to php's string functions, it's very unlikely to introduce new bugs or security holes, either. From a performance standpoint, the extension imposes a limit on the string-length that can be manipulated (default: 1000 characters), and manipulating short strings is cheap as dirt.

So.. should we ask for ParserFunctions 1.2.0 or not?

The big question is: is it worth asking for ANet's time to update the extension or not? I'd certainly like to have it, but no upgrade is risk-free, and we wouldn't want to steal ANet's time away from more important things. Tub 18:32, 6 September 2011 (UTC)

I leave the technical analysis to others. But, what im reading is that it makes the wiki better. Now we know Anet should concentrate on GW2, but I imagine this update works for the GW2 wiki too, so having that in mind, if it is an improvement, ask for it.Rumian 20:11, 6 September 2011 (UTC)

I'm in the same boat as Rumian, I'm not that sure what exactly that post was talking about >.<, but if it provides benefits for both wikis with relatively little risk, I think it'd be fine to ask. Ultimately, I'm sure ANet will make a decision as to whether their team can handle the implementations and testing and whatnot, so there's no harm in proposing it at least. ~FarloTalk 04:45, 7 September 2011 (UTC)

Uhm, thank you for all that analysis on the usage of an updated ParserFunctions extension. I guess this is a good chance to say that an update is actually already planned and will definitely come within the next few weeks; sorry if that makes your analysis-work a bit redundant now :/ poke | talk 14:37, 10 September 2011 (UTC)

Could you list these things somewhere when you get told about them? pling 14:47, 10 September 2011 (UTC)

Yes, please. It would be nice to know what is happening behind the scenes to benefit the wiki, especially in the absence of a discussion similar to that initiated by Tub. – Tennessee Ernie Ford (TEF) 23:50, 12 September 2011 (UTC)

I've noticed that this wiki and gw2w are now using ParserFunctions 1.3.0, but string functionality is disabled. Any possibility of enabling the string functionality by adding

$wgPFEnableStringFunctions = true;

to LocalSettings.php right after the include? (see the documentation for details) Tub 08:50, 7 November 2011 (UTC)

Hi everyone. First of all, sorry for not having communicated with all of you about the recent updates, which happened mostly Monday last week. I've been too busy (Paris Games Week) to communicate about these changes and focused on actually making them happen. I'll talk to the tech team to see whether they can enable the string functionality. --Stephane Lo Presti talk 16:13, 7 November 2011 (UTC)

I noticed that the string functionality has been enabled, thanks a lot!

I've already managed to do some useful stuff in my sandbox that might benefit the wiki. But before moving any of these changes to Main: I need to ask: will the string functionality remain enabled, or it it currently experimental and may be removed again at a later date? Tub 14:39, 6 January 2012 (UTC)

It should be final, so feel free to make use of it. poke | talk 23:50, 6 January 2012 (UTC)

Suppress Redirect button (images)

→ moved from Guild Wars Wiki talk:Community portal

Someone move this to the right place - I've been here 4 years and have no idea where this goes
Some of the most frequent deletion tags are on redirects resulting from page moves - wikis such as PvX have a suppress redirect button when you try to move images and pages - this means a redirect is not created at the source of the move (and the page is deleted). Any chances of getting that on here? (I suggest this because I recall Konig moving 200 fansite images and creating 200 speedy deletions) File:User Chieftain Alex Chieftain Signature.pngChieftain Alex 18:07, 21 November 2011 (UTC)

I would have no disagreement with such, obviously, since I have been adding hundreds *cough* to the speedy deletion list out of my... image cleaning. Konig/talk 22:38, 25 November 2011 (UTC)

I'm generally against that option for the sole reason that redirects are there for a reason. For a normal move, having the redirect page is the correct action, to show where the page went to. In many cases that redirect even stays, only some redirect pages get proposed for deletion immediately after the move. It's a different case for those frequent deletions. Those are purely maintenance and not the normal situation, and as such shouldn't be used as an example to reason such a feature. In addition many of those deletions I took care of recently were not so easily resolved. While they theoretically qualified for speedy deletion, only very little of those could really deleted without further actions. I had to double check every single redirect to make sure that no page still uses that link. And I had to fix quite a few pages. If there wasn't a redirect in the first place, those pages would just break directly, and nobody would have any hint how to fix it; so having a redirect for them is fine too. poke | talk 19:52, 26 November 2011 (UTC)

was suprised when I found this when looking for something else. "low priority" somewhat turned to "don't want". File:User Chieftain Alex Chieftain Signature.jpg Chieftain Alex 17:17, 14 January 2012 (UTC)

[alt+shift]+[c] shortcut — request to add its functionality to other spaces

I request that we enable the [alt+shift]+[c] shortcut to work in the Guild, Project, and Feedback spaces as it does in Main, Template, and File spaces.

There are some wiki keyboard shortcuts that work across the wiki: [alt+shift]+[t] takes you to a talk tab, [alt+shift]+[h] is the history tab, and [alt+shift]+[e] is the edit tab. Some universal shortcuts also work everywhere (e.g. to get to watchlist, recent changes, preferences, my user page, my user talk, etc.).

However, [alt+shift]+[c] only works in Main, Template, and File spaces; it does not work in Guild, Project, or Feedback spaces. It should take you to the primary tab for the article (respectively, the tabs entitled Guild, Project, or Feedback). I suspect this is a syntax/stylesheet type of fix that does not require backend support. Thanks.

I had previously added this request at GWW:BUG, but it was never addressed. – Tennessee Ernie Ford (TEF) 11:16, 4 December 2011 (UTC)

The project namespace is set to Alt+A by default (no idea why, it is the only one with A instead of C), changed that. Also added shortcuts for Guild, ArenaNet and Feedback. poke | talk 14:54, 4 December 2011 (UTC)

Awesome! Thank you for fixing (and 2xThx for the quick turn-around). – Tennessee Ernie Ford (TEF) 17:10, 4 December 2011 (UTC)

Follow-up

So the shortcuts work well now. However, the mouse-over comments for these shortcuts display alt-[letter] instead of shift-alt-[letter] (or alt-shift-[letter]). e.g. if you move the cursor over "Main Page" on the left navigation bar, it displays, "Visit the main page [alt-z]," which doesn't work (at least not in Firefox; in IE9, either type of shortcut highlights the link — you have to press <return> to follow it). (I haven't tested other browsers.)

These shortcuts display using the "shift" syntax in other wikis (using the standard mediaWiki install), so I'm not sure why GWW does something different. – Tennessee Ernie Ford (TEF) 19:29, 19 March 2012 (UTC)

Check user log duration

Right now, Check user only retains logs for 3 months. A request has been put forth to increase that time period. On the positive side, doing so would help with what the tool was meant for: identifying repeat vandals and users bypassing blocks. On the negative side, privacy issues could be raised and past a certain point the information may not be as useful.

Three months is just a little too short for check user, so, for an initial proposal, I say raise the limit on check user to 1 year. --JonTheMon 22:47, 5 December 2011 (UTC)

I also support 1 year. - Tanetris 01:34, 6 December 2011 (UTC)

At least a year. -Auron 02:44, 6 December 2011 (UTC)

For what it's worth, as a self-labeled privacy paranoiac, I don't have concerns about admins having access 12 months of this type data. Y'all can re-evaluate in Dec 2012 whether you only need e.g. 6 months or if you might need more than a year's worth. – Tennessee Ernie Ford (TEF) 03:11, 6 December 2011 (UTC)

A year sounds good. pling 14:53, 7 December 2011 (UTC)

Implementing the 2 outstanding requests (SpecialInterwiki, CheckUser)

There are currently only 2 outstanding community requests: SpecialInterwiki and CheckUser update. We're going to implement these 2 requests on Tuesday 7th February around 11am PST (1pm CST, 7pm GMT). This should be quick and easy, without any interruption of services. If there's any problem, please report it here or live on the IRC channel. Thanks. --Stephane Lo Presti talk 20:06, 3 February 2012 (UTC)

Update: we've updated CheckUser but SpecialInterwiki is causing some problems that our team is investigating. I'll post news here whenever I get them. --Stephane Lo Presti talk 16:04, 8 February 2012 (UTC)

Requiring Captcha when linking to ANet sites

Is there any way to turn off the CAPTCHA requirement when linking to an ANet site? Yeah, it's external, but I think we should make it easy for IPs to use {{forums}} or otherwise link to guildwars.com, guildwars2.com, or arena.net.

Alternatively, can we create appropriate interwiki links for the sites? For example...

forum.guildwars.com

• [[bug1:gamebugs|]] → https://forum.guildwars.com/forum/forums/gamebugs
• [[bug1:Friend-offline-but-away|]] → https://forum.guildwars.com/forum/forums/gamebugs/Friend-offline-but-away
• [[news1:news|]] → https://forum.guildwars.com/forum/forums/news
• [[news1:July-5-2012-Update-Notes|]] → https://forum.guildwars.com/forum/forums/news/July-5-2012-Update-Notes

And maybe something similar for guildwars.com.

Thanks. – Tennessee Ernie Ford (TEF) 02:40, 8 July 2012 (UTC)

Would a forum: interwiki link to https://forum.guildwars.com/forum/forums/ work? e.g. you'd do [[forum:gamebugs/Friend-offline-but-away]] - Tanetris 06:54, 8 July 2012 (UTC)\

Yes, that seems much better than what I proposed.

(People would have to remember that it's "gamebugs" not "bugs" and "news" not "update-notes," but I think anyone who knows enough to use interwiki links will be able to figure that small bit out.)

Thanks. – Tennessee Ernie Ford (TEF) 17:29, 8 July 2012 (UTC)

What about for guildwars.com? e.g. the WiJ announcement? (Soz, forgot to include an example for that, maybe [[gw.com:events/wintersday in july|WiJ official announcement]].) – Tennessee Ernie Ford (TEF) 17:33, 8 July 2012 (UTC)

So I just went to apply these to Special:Interwiki, and uh... Special:Interwiki does not appear to exist on GW1W. So. There's that. - Tanetris 19:57, 8 July 2012 (UTC)

I wonder why they installed the mod for GW2W and not for GWW. Well, how about if we ask SLP to put this in the queue (rather than requesting a one-off for these particular combos)? – Tennessee Ernie Ford (TEF) 00:23, 9 July 2012 (UTC)

(Yeah old one) forum:gamebugs/Friend-offline-but-away / gamebugs/Friend-offline-but-away ! :) -Chieftain Alex 11:05, 14 May 2013 (UTC)

Captcha settings & bot creations

So looking at the user creation log, out of the last 1500 accounts created since New Year, only 20 of them were legitimate. (i.e. potentially 1480 non-users/bots/vandals/sleepers)

It seems to me that the current CAPTCHA settings aren't potent enough. We seem to be using FancyCaptcha, something which is categorized under "not recommended" on mediawiki. I think it would be a good idea to switch to any of the QuestyCaptcha / Asirra / ReCaptcha services as detailed on that page.

If anyone with more experience of this type of extension would like to comment, that would be great. -Chieftain Alex 12:18, 27 February 2013 (UTC)

ReCaptcha is probably most familiar to most people, so is unlikely to unduly burden legitimate users. QuestyCaptcha seems interesting and is potentially more secure, but we'd have to come up with a significant list of questions and balance between making sure a legitimate person could answer them and not being things a bot would parse. Asirra is interesting, but the "reported not to work in all browsers" bit is definitely a concern. I'd lean toward ReCaptcha personally. - Tanetris 15:42, 27 February 2013 (UTC)

(Oh the awful guildwars trivia we could ask about Frenzy Mending...) I agree that ReCaptcha sounds like the most sensible one. -Chieftain Alex 20:19, 27 February 2013 (UTC)

Personally (being an old fart) wearing glasses, I have a hard time reading some of those blurred text. I found this captcha on Panda3D where you had to select all the images of animals. I like it but I have no idea how secure this method would be. --Wendy Black 20:34, 27 February 2013 (UTC)

I suspect that one would have the same problems as Asirra, namely that it won't work on some browsers. Plus its far easier to pick one of the 5/6 mods for the extension that we already have/is integrated into a mediawiki module ;) -Chieftain Alex 21:20, 27 February 2013 (UTC)

(Reset indent) I'll follow up with our team, but if I remember correctly, this one was chosen because it was recommended as giving more solid results that ReCaptcha. Unless it's a hot/urgent request (in that case, let me know), I'll put it on our list of things to check, but it'll have to wait until our update plan is complete. --Stephane Lo Presti talk 01:21, 5 March 2013 (UTC)

So you don't think that a 74:1 ratio of vandal bots to legitimate users created is a problem? :/ I would strongly suggest that we change the captcha system. -Chieftain Alex 10:33, 6 March 2013 (UTC)

It's not what I said or even implied. What I said is: it's on the list of things to do, but on this list there are things that are more urgent (updating the MediaWiki software to name the big one). Our tech team has a limited amount of time and this is why we have to use a priority list. Not because we classify topics based on whether or not it's an issue, but to be able to actually fix these issues at some point. If the community tells us "this is actually more important or urgent [or insert other explanation] than updating the MediaWiki software", we'll be listening. Thanks. --Stephane Lo Presti talk 17:31, 6 March 2013 (UTC)

Right I'd misinterpreted. Its not as important as your incoming big update, but it would be a good thing to implement sometime after. -Chieftain Alex 17:47, 6 March 2013 (UTC)

(Reset indent) A quick update from me, live from our big upgrade work to move to MediaWiki version 1.20: we've looked a bit at the issue of the Captcha system and we think that this is something that we'll need to look at after the upgrade. We discovered that this is something that requires a bit of research and testing, because our initial research doesn't show that there are "better" alternative Captcha system. One of the idea that came up during our discussion is to require users to confirm their email address before they can edit. Is this something that the wiki community would be ok to do?

We have two further questions for you about this issue: 1) Do you have an idea of why people create bot accounts here? E.g., to put links to their site; 2) Is this also happening on the GW2 wiki (since accounts are shared)? Thanks. --The preceding unsigned comment was added by Stephane Lo Presti (talk) at 17:14, 4 April 2013 (UTC).

I think for GWW we would be fine if we require emails now. For GW2W I wouldn’t want to go that direction yet as we might lose valuable contributors that way. As for the “why”, it’s probably random spam. Luckily most (if not all) edits are caught by our filter, so we never get to see that content, but the registration is still annoying. This does not seem to happen on GW2W yet. One reason might be because they are just registering the bots here because the accounts are shared, or simply because the bots don’t have that address in their system yet. It’s the big mystery as for why spam bots do what they do… poke | talk 17:14, 15 April 2013 (UTC)

It might be unrelated is unrelated, but I seem to be noticing less accounts created after the update on the 9th - did you change something, or does 1.20 have a stronger set of clues? ^^ -Chieftain Alex 18:20, 10 May 2013 (UTC)

No we didn't change anything. Apparently the GW2W had a lot of what looks like spam accounts created, so it may just be luck. We'll tackle the issue of spam/captcha at some point in the future, to try to find a solution to this problem (even if it means changing the captcha system entirely). Thanks. --Stephane Lo Presti talk 18:38, 10 May 2013 (UTC)

Doh, after fixing the IP bug there have been 9 accounts created in 32 minutes.. clearly they've been trying to do the captcha all day. oh well. -Chieftain Alex 18:50, 10 May 2013 (UTC)

This is really getting out of hand… I’d even consider completely disabling account creation until a better solution is found. poke | talk 15:47, 11 May 2013 (UTC)

If account creation disabled option is taken, would legitimate users still be able to participate via request/invite from an existing account? --Falconeye (talk) 21:51, 11 May 2013 (UTC)

If account creation was disabled, existing users would still be able to edit. Since we don't actually have a problem with vandal IPs, we could still allow anonymous editing too - this way it wouldn't harm existing users, logged in or not. Potentially sysops and bureaucrats with abusefilter rights could enable account creation for specific account creation requests (e.g. they turn off the filter, allow the account to be created, and switch it back in afterwards). (I think this sounds like a good idea) -Chieftain Alex 22:43, 12 May 2013 (UTC)

Disabling looks to be best option at the moment (just my .02 cents .33 cents)MystiLefemEle (talk) 09:37, 13 May 2013 (UTC)

Lock until captcha is improved seems a good option - I was kinda hoping the mediawiki upgrade would come with a captcha upgrade, but alas. -Auron 10:15, 13 May 2013 (UTC)

What's the issue? AbuseFilter is preventing the spambot accounts from editing, so the only things affected are Recent Changes and the list of user accounts. Why not automatically delete accounts with zero contributions and then purge RC of the entries. Once setup, legit contributors would be able to create new accounts without admins having to be involved. 75.37.23.8 13:38, 13 May 2013 (UTC)

automatically delete accounts with zero contributions - wiki side users can't do this, you'd have to delete the entries out of the user table on the ArenaNet side or something like that, requiring any effort on arenanet's part should be avoided if possible.

the issue is mainly spamming recent changes with 80+ account creations every day, rc doesn't really need that with our low levels of activity :/ -Chieftain Alex 14:10, 13 May 2013 (UTC)

We don't know why Captcha is not helping here but since AbuseFilter is preventing the content of the wiki to be vandalized, it seems that the only impact on the wiki community is to those few (?) who watch the account creation log. Please correct me if I'm wrong. Also I'd like to better understand how people use that information, e.g., once you see a non-spambot account created, what do you do with the information? Given that in the future we may split the user databases for GW and GW2, we may take this opportunity to do some cleaning (if it's even possible). I think that we need to discuss this a bit more before deciding that disabling account creation is our best option: for example, would it be possible to devise an AbuseFilter rule that would prevent spambot acount creation based on the current pattern (e.g., name, IP, etc.). --Stephane Lo Presti talk 17:06, 13 May 2013 (UTC)

The main problem is how it affects recent changes, making it nearly unusable.

One step into solving it: We are using the ConfirmEdit extension to require a CAPTCHA on account creation. From the way the CAPTCHA looks, we are apparently using the FancyCaptcha option, which is in the “Not recommended” list because they are not effective. So the first try to reduce the amount of account creations would be to switch to a better CAPTCHA method. I would either like to use ReCAPTCHA (I think we created ReCAPTCHA usage before, didn’t we, Stephane?) or Asirra, which currently seems to be the best option (also yay kittens and puppies!). It would be great, if we could test this soon. poke | talk 10:31, 14 May 2013 (UTC)

I think we did change from ReCAPTCHA to Fancy CAPTCHA because our investigation showed that the first one was not that solid and the second one came recommended by a few people. We can totally switch back to ReCAPTCHA to see if this makes a difference and I'll see if we can do this quickly. We saw the name of Asirra during our investigation but decided not to rush such a decision but rather dedicate some time to think about how to solve the issue. I did notice that Recent Changes is too polluted with these account creations, thanks for the clarification. --Stephane Lo Presti talk 16:34, 14 May 2013 (UTC)

(Reset indent) I don't remember the password to Rodan, but I do not have it email set. What happens to those of us that cannot get into our accounts without email? 24.51.181.85 01:08, 15 May 2013 (UTC)

Nothing. This would simply prevent *new* accounts from being created, not old accounts from being logged into. -Auron 03:08, 15 May 2013 (UTC)

It could prevent people from creating a new account, after loosing their password to old one. 24.51.181.85 22:00, 15 May 2013 (UTC)

So.... Don't forget your password then? Or if you might, make sure to set up a valid email? There are ways to avoid being locked out of your account, we can't hold everyone's hands and walk them through it if they aren't willing to use common sense precautions. --Rainith (talk) 16:13, 16 May 2013 (UTC)

Many prefer not to have their email linked to this, if it's (for example) a work email that they only have and prefer to have. Many have to think up lots of passwords for things, any can be forgotten. There are ways to avoid, but commenting a rude answer after questionable answers is not helpful. I feel this wiki should be combative, but helpful. Maybe take a page from the pvx wiki. Use the same things as the forums, site, and other wiki uses. Only those banned from the forums, should be banned from the wiki, etc. They could only use the email to contact. Saves from non-employees to abuse the system. However, we need to focus on the issues and I am only naming an example and ways that are better than locking out players as well as the bots. To me, that is a poor answer. 24.51.181.85 16:02, 27 May 2013 (UTC)

Its not as if you can't create a free googlemail account with a random as hell username with the sole purpose of account retrieval. You don't even need to provide real data to set it up. -138.38.60.23 16:59, 27 May 2013 (UTC)

True, I have. However, others do not like google one bit or other freebies. It's a thought to consider for people, don't pinpoint it on me. My thing is, don't be narrow minded when considering options for a wiki. 24.51.181.85 17:18, 27 May 2013 (UTC)

Apart from the initial confirmation email you will not receive any further emails if you don’t enable notifications in your preferences. Unfortunately adding an email address is the only way to guarantee that you keep access to your account. We technically can’t change passwords for other others (to get them their access back) and we also can’t really verify that the random anonymous user claiming to own account X actually owned that account before. So we simply don’t and can’t protect your account access for you. If you want to make sure that you keep access to your account even if you forgot the password (which you shouldn’t to begin with), then please add a valid email address you can use to reset your password. That is really your only option.

Regarding the disabled registration this means that you currently cannot make a new account when you lost access to your old one, but this should not prevent you that heavily from editing. And the registration stop is temporary anyway until we found a better way to solve our problem. poke | talk 00:47, 1 June 2013 (UTC)

Captcha Follow-up

Could you try changing the filter captcha for us Stephane, and see if it makes a difference? -Chieftain Alex 13:11, 27 May 2013 (UTC)

Can you please elaborate on this? Not sure I understand the request. Thanks. --Stephane Lo Presti talk 21:57, 28 May 2013 (UTC)

"We can totally switch back to ReCAPTCHA to see if this makes a difference and I'll see if we can do this quickly." - Sorry to be unclear, could you do this as you wrote above? -Chieftain Alex 22:35, 28 May 2013 (UTC)

hah I totally see why you were confused by my nonsensical question now ;) -Chieftain Alex 22:36, 28 May 2013 (UTC)

We're currently discussing the bigger problem and I'll give an update as soon as we finished discussing this. Let me know if you have any question. --Stephane Lo Presti talk 22:37, 28 May 2013 (UTC)

Wait there is a bigger problem? Well just to put my 2 cents in here. The reason CAPTCHA fails is the bot they use is encoded to work on such a device. You build a shield they make a better sword. I know that isn't much help, but I don't understand the bot trying to make an account on something that can be edited without an account in the first place. This is why I run Linux on my PC, bots and virus run rampant and they don't effect me. Call me paranoid, but I think some of our nations should get together and bust these bot makers once and for all. Good luck, I would be happy to help, but I know more about genetics than I do computer chips. Simon of Aragon - talk 22:34, 31 May 2013 (UTC)

Sorry for the time it took us, we've changed the Captcha system to ReCaptcha. You'll need to reenable account creation to see if this is an effective measure (althoug the GW2 wiki should also help us track this). Please update us as soon as you see signs that it's working or not. Thanks. --Stephane Lo Presti talk 17:30, 14 June 2013 (UTC)

Ok the abusefilter stopping account creation has been turned off to test this ;) also lol -Chieftain Alex 19:14, 14 June 2013 (UTC)

If it doesn't work, I'd suggest checking out Manual:Combating_spam, Manual:Preventing_access, and ConfirmAccount on media wiki. ConfirmEdit seems to work with ConfirmAccount. Rodan (talk) 21:12, 14 June 2013 (UTC)

Right. We're going to get about 50 registered spam accounts every day if we rely on the ReCaptcha - which is less than the 136 that plain Captcha was letting through, but how many are we happy with? (I think 56 is still too many)

@Rodan, I think that restricting access is more for wikis with the problem of vandals editing pages maliciously, which isn't really a problem here, its just the accountcreation thats annoying. ConfirmAccount looks effective, but would require phenomenally active bureaucrats, and in all likelihood they'd still have loads of spam requests every day :/ -Chieftain Alex 10:28, 15 June 2013 (UTC)

Promote more B-crats, is not the answer... I'd rather see it be set aside a team that can do this, a special group only for account creation, involving as well the active b-crats and sysops. Let ArenaNet assign this task to the loyal players that offer their time to do this. Secondly, make email a requirement as well as the captcha. If bots can get through the email creation and recaptcha and still mange an account that someone would have to approve/deny - something is wrong. Perhaps instead of letters on the Recaptcha, do the animal images? Rodan (talk) 22:06, 15 June 2013 (UTC)

Please note that account confirmation via email will not change the fact that we still get all these registrations; their accounts are just a bit less usable than now (as they won’t move to the autoconfirmed group automatically). As the accounts don’t do anything at all, it would not really make a difference. poke | talk 11:11, 18 June 2013 (UTC)

Here's a thought: We could leave the disable account creation filter up and have people who legitimately want to make an account contact an admin to set an exception for them. - Tanetris (talk) 14:44, 18 June 2013 (UTC)

I believe that we shall try the account confirmation, before enabling the filter again. Also, to see ArenaNet's or Stephan's thoughts on these ideas and what might work. Right now things aren't hurting, but annoying. What's to say my ideas could be better or worse? Same with any of your ideas, people? I'm not great at Ingrish, but we all have a voice. Let's not discourage it? Rodan (talk) 18:14, 18 June 2013 (UTC)

Hi Rodan, while I appreciate everyone's voice on the wiki, I think that matters of "system configuration" are best put in the hands of editors who have some experience with configuring MediaWiki software and extensions. I'm NOT saying that some ideas or suggestions are good or bad, just that I've worked in the past with a lot of people who have informed opinions and may be able to give you good answers on why something is not a good idea, possible or effective. Thanks for your understanding. --Stephane Lo Presti talk 18:22, 18 June 2013 (UTC)

(Reset indent) I tried to setup a message that would appear when the filter tripped - with a link to the AN, but for some reason the abusefilter message that would appear beneath the login error removes wiki-links and wikitext - which isn't ideal. Also I can't see any easily editable system messages on Special:AllMessages that could be used to link to the AN with a related piece of text. -Chieftain Alex 11:55, 19 June 2013 (UTC)

MediaWiki:Gotaccount look alright? (shows right at the top of the account creation page) - Tanetris (talk) 16:21, 19 June 2013 (UTC)

Great job, perhaps we could be a bit more explicit about what to contact the admins about though. -Chieftain Alex 17:06, 19 June 2013 (UTC)

I just remembered that while the wikis are still linked we can get people to make accounts over on GW2W and return here to edit. (hurrah all the account creation on the active wiki!) -Chieftain Alex 17:08, 16 July 2013 (UTC)

Tbh I'd rather keep account creation for this wiki on this wiki, even if it is a bit more of a hassle, for two reasons. 1: It's not necessarily a permanent solution, as I know Stephane's talked about the team wanting to split the userbase, and 2: It's really just bad practice to direct people to a different domain to put in their details. - Tanetris (talk) 15:17, 17 July 2013 (UTC)

Agreed. And I think the split was going to happen somewhat soon-ish anyway? poke | talk 11:05, 22 July 2013 (UTC)

Restrict editing of Guild and Guild talk namespaces

Hi,

I was alerted about this request and our engineer is going to make the appropriate changes to the LocalSettings.php (they're actually different from the ones listed on the request page). This is going to happen in about 2 hours (Monday November 4, between 10 and 11 AM Pacific Time). Do let us know if there are issues after this change.

Thanks --Stephane Lo Presti talk 16:56, 4 November 2019 (UTC)

If he wants reassurance as to where to insert the lines you could send us a copy of the relevant php section on discord. -Chieftain Alex 19:26, 4 November 2019 (UTC)