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

Length of usernames

Is it technically possible to limit the creation of user accounts to a certain number of characters? If it is, we should implement something to stop account-creation-trolling like we've seen in the last couple of days. I don't think it would have a detrimental effect; even accounts made in good faith should not be overly long. -- pling 14:21, 11 June 2010 (UTC)

It should be. I think it would be useful to do so. But what would happen to existing names that are too long? -- FreedomBound 14:33, 11 June 2010 (UTC)

Would it actually prevent anything, or would they just create like 3-4 accounts in quick succession to make the same message? Are you aware you can create accounts while logged in? The tabs could all be open and submitted in order. It wouldn't take significantly more effort to troll in this manner, but would require more effort to fix. Something like the option to put a temp restriction on creating accounts (like 10 minutes) site wide would be more effective and unlikely to be that destructive. That being said, I struggle to see a legitimate reason for someone having a ~50 character user name, so I am not overly opposed to it. Did you have a particular limit in mind? Another option would be to make the account creation log not part of RC by default, then no one would even see the trolling. Admins could all switch it on. Misery 14:47, 11 June 2010 (UTC)

The longest username I can think of off the top of my head on any wiki is "Arnout aka The Emperors Angel" which is 29 characters. So, 35-40 wouldn't be unreasonable. However, keeping the logs off of default RC wouldn't be bad either. --JonTheMon 14:54, 11 June 2010 (UTC)

It's not just the account creation log that's a problem when long usernames exist, it's the edits they make and the reversions they require. I'm not sure about taking the user creation log off RC since it can be useful to detect new vandals/socks (most of the recent ones I think were detected on RC before they had a chance to edit) - I'll leave that for others to decide. However, I still think a limit on username length should be implemented in addition to that (if applicable).

I'd rather not put off new users registering accounts by adding a time limit between account creations (i.e. having some requests rejected just because someone else registered minutes ago), and I don't think the circumstances we're trying to avoid necessitate that. Blah, misread. Still, I'd rather not have account-creation-temp protection.

40 characters might be ok. -- pling 15:40, 11 June 2010 (UTC)

(ec) I'd say a limit of 40 characters should more than cover any legitimate names (for example, the in-game name character limit is half that) while curbing vandals' ability to spam RC and page histories with multi-line names. Obviously it won't keep vandals from vandalizing or socking or spamming, but it helps limit their lasting impact (on page histories). A question: Will complications with GWW and GW2W's shared user database arise from this, or should it be fine as long as the limit is applied to both wikis, or what? - Tanetris 15:51, 11 June 2010 (UTC)

40 is more than enough, I'd consider something a little shorter like 35 or even 30 since 40 characters still look a bit intrusive. Also shorter sigs ftw! :-) We can also reduce the limit to the same as ingame if we find that 99% of the accounts are under 20 characters. --Lania 18:35, 11 June 2010 (UTC)

40 seems like a bit too high of a limit. I'd feel a bit more comfortable with a 25-30 character limit. The username is a username, not all of your biography plus one. I know mine pushes 23, but I don't think its intrusive....I hope. -- Wandering Traveler 21:27, 11 June 2010 (UTC)

Please note, that that limit there is in bytes, not characters. Also note that 20, and even 30, characters is very short. Just think of people, who are registering using their full name. It's not rare that those names get quite long.

Anyway, setting a username length limit shouldn't be done to prevent vandalism (although we still should reduce that limit a bit to make revision lists prettier), and I don't think those vandals will actually care how long their new nick is, as soon as they notice, that the full line no longer works. Instead we should set up blacklists to prevent common vandalism name similarities. poke | talk 21:41, 11 June 2010 (UTC)

I don't know, the overly long names do help to spot them in a crowd. — Why 21:43, 11 June 2010 (UTC)

lol, true. poke | talk 21:43, 11 June 2010 (UTC)

Is it possible to setup IP blacklists? like against known open proxies? --Lania 22:10, 11 June 2010 (UTC)

I think so. But the blacklists will take time to fill out properly, and it still wouldn't fix this immediate problem on its own - the main issue for me is the length of the usernames in logs and histories, so that should be our priority. Even a temporary limit to character/byte length, just to deal with the current troll, would be useful to lessen his impact - we could then go on to discuss/carry out the implementation of a blacklist (whether by word or IP), and see if we need to modify the username limit. I'm still in favour of 40 characters. -- pling 22:20, 11 June 2010 (UTC)

I've no problem with this. I agree with poket that we shouldn't do it just to play into the hands of trolls. but the trolls do it because it is annying, so will be so even if not done with malicious intent. 32 bytes should be enough for everybody. Backsword 22:36, 11 June 2010 (UTC)

I guess 32 bytes is okay. poke | talk 23:35, 11 June 2010 (UTC)

.. awesome :D. Have we established whether existing usernames will be affected by the limit, by the way? -- pling 14:30, 12 June 2010 (UTC)

Having checked that, it appears that existing usernames (above that limit) will no longer be usable. poke | talk 17:49, 12 June 2010 (UTC)

Conclusion

• $wgMaxNameChars = 32
• $wgAccountCreationThrottle = 2

These are the setting, we will change. Any objections, or comments? poke | talk 18:42, 12 June 2010 (UTC)

I agree, with the added note to make sure to add the same changes to GW2W at the same time as GWW, given the shared database. - Tanetris 18:47, 12 June 2010 (UTC)

I'd agree even with a limit of one. - J.P.Talk 18:53, 12 June 2010 (UTC)

I don't know any reason why someone would need to make 2 accounts on the same day. ~Shard 20:07, 12 June 2010 (UTC)

Making shoepuppets for signatures; registering an account then registering again because you don't like the name.

I agree with the first thing; not sure about the second, but not completely opposed. If we do go ahead with the second, it should be no less than 2. -- pling 20:34, 12 June 2010 (UTC)

Sounds good to me. — Why 13:21, 13 June 2010 (UTC)

Sounds great! :)--Lania 16:09, 13 June 2010 (UTC)

The throttle is pointless as when you ban an account, account creation is disabled for the duration of the autoblock, 24 hours. It could only really hurt legitimate contributors who for some reason screw up making their accounts or want to make a couple of accounts at once for redirects, or make the hypothetical situation about opening multiple tabs and submitting them all at once to create multiple accounts marginally more difficult. Misery 12:32, 14 June 2010 (UTC)

Can the throttle use decimals or values less than 1? I think this calls for science. elix Omni 12:35, 14 June 2010 (UTC)

On that note, Misery, I want to point out that vandals can also tab and submit multiple user names before a single autoblock is in place. — Gares 13:00, 14 June 2010 (UTC)

Yes, hence making that one specific case of vandalism that has never occurred marginally more difficult. It's even a kind of vandalism that you don't have to do anything about at all. You could go and remove all the log entries, or you could just ignore it. If someone really wanted to do that they would just have to have a different proxy every 2 tabs, which is totally doable. In any case, if people really want a throttle, something like 4 is more reasonable. It's not like the clean up job is any harder for 4 entries instead of 2 and it gives a little more leeway for legitimate mistakes. Misery 13:09, 14 June 2010 (UTC)

If someone had nothing better to do, then yeah, you're right. That would also be pretty pathetic too. I really have no objections to either 2 or 4. Just as long as there is a reasonable limit. — Gares 13:20, 14 June 2010 (UTC)

Actually, that specific case of vandalism has occurred - it started some time after you pointed it out in your first comment. But at least you're not giving them more ideas. -- pling 13:27, 14 June 2010 (UTC)

You are welcome Pling. I actually have more reasons for pushing the removal of the user creation log by default, but I wouldn't want to give anyone any more ideas. Misery 19:57, 14 June 2010 (UTC)

Removing the log from RC has actually less benefit. In the first place, we want to avoid vandalism. If a user with a name similar to the recent ones is registering, it is very likely, that the user will try to vandalize the wiki. And then it's better to block him before he even has the chance to do it. It might be disruptive in some cases, but at least it is less disruptive, than lots of vandalism and reversion entries in both RC and the page's history. poke | talk 22:22, 14 June 2010 (UTC)

MediaWiki has a "list" of blacklists which would not "take time to fill out" ... I think Lania had a good point. Dime Cadmium! 22:32, 14 June 2010 (UTC)

I disagree. We have no policy against (open) proxies, and such vandalism cases are rare anyway. I would rather see a solution against the actual vandalism, without blocking possible visitors. Also setting up such blacklists from open proxies really isn't that easy. poke | talk 22:36, 14 June 2010 (UTC)

(Edit conflict) [1] I'm not sure if this is vandalism, but it seems informative. --Riddle 22:38, 14 June 2010 (UTC)

(Reset indent) (Edit conflict) You also have no policy against username lengths, nor do length limits prevent (all of) the vandalism - a large portion of the vandalism is the page edits, IMO. In addition to the fact that - how many users on here use open proxies? Few, I'm sure. Moreover, how many HAVE to use open proxies? None. And, it's not incredibly difficult, either. @Riddle, that would WORK, but 1. it would slow down the process of editing (im not sure if they check every edit, or only first edit, or etc and 2. as said, some people might not like the scans. Dime Cadmium! 22:43, 14 June 2010 (UTC)

I was talking about the notes provided. [2] --Riddle 22:45, 14 June 2010 (UTC)

(Edit conflict) Just a quick note about open proxies. About 2/3 of IP vandals that I bother checking are open proxies. So open proxy vandals are pretty common. --Lania 22:46, 14 June 2010 (UTC)

I see, Riddle. It's... at least partially true. I don't know how many users/admin's would do so, but some might. Lania, agreed, and I'm fairly certain this particular vandal is using open proxies. Dime Cadmium! 22:47, 14 June 2010 (UTC)

[3] This looks like a IP blacklist addon for media wiki. Not sure if this will work for us though. --Lania 22:50, 14 June 2010 (UTC)

Search

Did we ever install LuceneSearch/the stuff that enables it? The search features on both wikis aren't great, so I doubt we did; it's a lot lot lot worse than Wikipedia's. -- pling 16:53, 19 June 2010 (UTC)

Guild_Wars_Wiki:Requests_for_technical_administration/LuceneSearch For reference Shadow Runner 17:23, 19 June 2010 (UTC)

It is worth noting LuceneSearch is now marked as obsolete in favor of MWSearch according to MediaWiki. - Tanetris 17:47, 19 June 2010 (UTC)

And that needs "Extension:Lucene-search"... they really should use a different name. Anyway, I think we should install these. -- pling 20:32, 19 June 2010 (UTC)

Bump. This is quite an important extension that helps readers as well as editors. There are currently also... "issues" on GW2W regarding the functionality of the search features. If someone could make the proper request page for this, that would be great. -- pling 14:54, 9 July 2010 (UTC)

Guild Wars Wiki:Requests for technical administration/MWSearch. poke | talk 17:04, 14 July 2010 (UTC)

Excellent. Is everyone fine with adding that to the list of requests? -- pling 18:36, 14 July 2010 (UTC)

reCaptcha

I would like to suggest you also make addurls=true. While it will be a bit obnoxious for people adding legitimate external links, it will eliminate the IP advertising spam, more immediately than the blacklist. Just a thought. -- Wyn talk 12:43, 14 July 2010 (UTC)

I don't really see where that was discussed that it is immediately requested by the community. In fact, I highly disagree with those settings, as they overwrite already made settings by the ConfirmEdit extension. I have no major issue with adding a stronger captcha, but instead we should adjust our previous made settings first. I'm not sure if those settings are correct (as I get a captcha when trying to register as well), but we should decide on those separately.

In addition, I am also thinking about finally adding something against harmful known open proxies. poke | talk 13:07, 14 July 2010 (UTC)

ConfirmEdit can be disabled to make way for the stronger security of ReCAPTCHA. I do not see why a more extensive captcha would be a negative, other than a little more work installing a new extension.

Oh, and Wyn, I'm on the fence regarding urls. It would be an added preventative measure for sure, but a more prominent hassle for users than just user creation. I don't mind the hassle myself, so I would support either way. — Gares 13:15, 14 July 2010 (UTC)

The reCaptcha is a separate plugin that is from what I understand not available to be "added" to ConfirmEdit. You can replace the default captcha (which is not bot proof as we have seen for the past many hours), with the FancyCaptcha, which requires creation of the captcha images in Python (seems a bit of a pain to get installed and set up). I agree that this request was not discussed by the community, but I am in favor of it. -- Wyn talk 13:16, 14 July 2010 (UTC)

"reCAPTCHA relies upon, and is bundled with, the ConfirmEdit extension." poke | talk 13:23, 14 July 2010 (UTC)

Ok, so I don't totally understand it all. I'll freely admit that. I just believe that the reCaptcha (however it is installed and implemented) is the best choice of bot prevention of the options out there. I for one do not want to see another round of rc spam like we have had for the past day. -- Wyn talk 13:27, 14 July 2010 (UTC)

(Edit conflict) ReCaptcha sounds like a great idea, not sure about the url setting. Anyway to make it so only registered users can add urls, rather than requiring existing editors (that have registered and thus already passed the initial test) to solve a captcha each time an external link is added? -- FreedomBound 13:28, 14 July 2010 (UTC)

No Freedom, anyone wishing to add an external link would have to complete a reCaptcha before the page could be saved. As I said, it's a little obnoxious for people adding legitimate external links, but it would eliminate any IP bot ad spamming. -- Wyn talk 13:32, 14 July 2010 (UTC)

Based on the supposed confirm edit settings, IPs already have to captcha to post a URL. --JonTheMon 13:35, 14 July 2010 (UTC)

No one is expected to know everything in the world of programming, even know everything in a particular concentration, Wyn. I don't know every function or library in C++ by heart after 10 years of coding with it. Poke just found that note at the bottom of the Extension:ReCAPTCHA article. — Gares 13:38, 14 July 2010 (UTC)

This is my configuration proposal. Not completely sure if the original settings were actually kept or if this request actually was enforced. However part of that change is to put unconfirmed users down to the same level as unregistered users, as we did with other things before. I'm not too sure if adding a captcha for external urls is the best idea (given how many useful links we actually get), but we may or may not argue about that; I don't feel too strongly about it. poke | talk 14:28, 14 July 2010 (UTC)

What's the req for confirmed again? --JonTheMon 14:31, 14 July 2010 (UTC)

I can live with that poke. It's been so long since I did anything here without logging in, I have no idea really what IP users can and can't do anymore. :D My suggestion was just an attempt to curb the IP ad spamming (which is not a huge problem). -- Wyn talk 14:37, 14 July 2010 (UTC)

Jon: 10 edits or registered for 24 hours. poke | talk 14:42, 14 July 2010 (UTC)

The biggest issues I can see for having the captcha for unconfirmed users is when they have another online profile or are making a guild page. But since the confirmed level is pretty low and a captcha isn't gonna stop those people, I think the current settings are fine. --JonTheMon 15:12, 14 July 2010 (UTC)

Can we push the button on this one? -Auron 08:50, 20 July 2010 (UTC)

The button's been pushed on our end. Just need to poke ANet. --JonTheMon 12:05, 20 July 2010 (UTC)

MediaWiki 1.16

1.16 was released on July 28th. Should we add a request to install it? (It contains Vector!) -- pling 22:51, 12 September 2010 (UTC)

Go for it! ...As long as it doesn't break anything :) - J.P.Talk 22:56, 12 September 2010 (UTC)

Yeah! I'm just hoping it doesn't mess up my shiny new sig with the preferences changes. –~=Ϛρѧякγ (τѧιк) ←♥– 22:59, 12 September 2010 (UTC)

Out of curiosity, does vector override monobook, or is it a choice? ~ PheNaxKian talk 18:10, 13 September 2010 (UTC)

It's a choice, but personally with 1.16 I would like to decide on a single skin (i.e. getting rid of every other). poke | talk 18:52, 13 September 2010 (UTC)

Let's not go down the Wikia route... at the very least, Monobook and Vector should be available options. -- pling 18:55, 13 September 2010 (UTC)

As long as we don't decide to mess with the skins, we are not able to go at least in a similar direction as Wikia.. poke | talk 19:08, 13 September 2010 (UTC)

You can take away Monobook when you pry it from my cold, dead hands. - Tanetris 19:20, 13 September 2010 (UTC)

lol. <3 poke | talk 19:23, 13 September 2010 (UTC)

It's ok for me to only have Monobook and Mehtor. Others have visual issues anyway, am i correct? - J.P.Talk 20:05, 13 September 2010 (UTC)

What Tane said..... -- Wyn talk 21:18, 13 September 2010 (UTC)

Dangling in the wind

Emily's gone, with mention that the wikis would now be in the hands of the Extended Experience team, but no one there's visibly stepped up. We've had the MWSearch and Recaptcha requests lingering in limbo since July with no official word on them. More recently, Poke mentioned wanting some new interwiki prefixes, with no clue who to ask, and then there's the wiki off-and-on sluggishness the past few days (which thankfully seems to have stopped, at least for now).

My point: We need a point of contact for this sort of thing, one that's visible to and reachable by at least the admins if not everyone. If there's already an Anet person watching, great, but we need to know you're there and know what's going on and know how to reach you. If not, what are we doing about this, people? - Tanetris 02:17, 6 December 2010 (UTC)

Interesting you say this when yesterday I sent an email to the webmaster arena.net address requesting to whom we could address wiki technical issues - especially wrt the servers being slow with tedious regularity. It may have been better coming from someone who's name they might recognise and trust and so perhaps be more likely to reply to - but I'll let you know if anything shows up from the request. -- aspectacle 07:10, 6 December 2010 (UTC)

I actually wanted to get to know who is responsible for the wiki now for a while, but didn't really have the time to ask yet. I'll do that tonight, and we will see. poke | talk 08:20, 6 December 2010 (UTC)

GW2W has had off-and-on sluggishness since August, never mind 'the past few days'. Oh, and you left out the MW 1.16 (Vector!) update. -- pling 13:38, 6 December 2010 (UTC)

Yes that would be nice. i expected someone to get in contract with us after Emily left, but apparently not. Backsword 12:39, 8 December 2010 (UTC)

Hi, everyone. The team member who will be working with you on requests for technical administration is on paternity leave for the month. Any requests for wiki plugins can't be addressed until he returns. I've forwarded this thread to the EE team, and they're aware of the discussion concerning point-of-contact for plugin requests. Thank you for your understanding, and we appreciate your patience through this period. --Regina Buenaobra 22:11, 8 December 2010 (UTC)

Interwiki link to Guild Wiki

→ moved from Guild Wars Wiki:Admin noticeboard

Guild Wiki has moved to its new location; the old location is now know as Guild Wars @Wikia. Can we update the interwiki map accordingly? e.g. so that [[GuildWiki:Focus]] could point to Focus? Thanks. (Obviously, please move this comment if this the wrong location for it.)  — Tennessee Ernie Ford (TEF) 21:12, 14 December 2010 (UTC)

I'll note it may be useful to just install http://www.mediawiki.org/wiki/Extension:SpecialInterwiki so admins can add/change/delete (particularly delete looking at how many useless ones there are there) interwiki links without having to bug Anet about it each time, and to have a more easily findable list of interwiki links for everyone. - Tanetris 20:09, 15 December 2010 (UTC)

Yes, that sounds sensible. In fact, I'm surprised that ANet would want to manage interwiki links when the unpaid staff here can handle it; I assumed that the sysops already had that power.

For those not following other threads: Regina mentioned recently that, since Emily's departure, the new staff person responsible for handling these requests has not started work...so we probably won't see any action on this until January.  — Tennessee Ernie Ford (TEF) 20:52, 15 December 2010 (UTC)

Who can we ask (@ANet) to get a status update on either self-management of interwiki links or when they can update the current list? I realize the probably answer is: wait another 3-4 weeks (but I would like to make sure this isn't lost in the holidays/transition). Thanks.  — Tennessee Ernie Ford (TEF) 19:29, 12 January 2011 (UTC)

We don't know who the new Anet-wiki liason is and a message on Regina's talk page won't be noticed any time soon, so I guess we wait for someone to come to us first. The alternative is finding an off-wiki route of communication - email, Twitter, Guru, or something. -- pling 19:40, 12 January 2011 (UTC)

She seems to respond to forum questions, but I don't have a login on any of them.  — Tennessee Ernie Ford (TEF) 20:08, 12 January 2011 (UTC)

Regina is on MSN every day. elix Omni 20:40, 12 January 2011 (UTC)

Right, I'm not ever on MSN, otherwise I would ask her directly (instead of asking here). So, could one of the sysops who is on MSN ask her for a status update? (Again, I'm not expecting her to put a rush on anything, but I would like ANet to set our expectations.)  — Tennessee Ernie Ford (TEF) 20:48, 12 January 2011 (UTC)

Is this going to be done? o.O Cause I'd still like to link to my userpage on that site using interwiki. Kaisha 16:46, 10 May 2011 (UTC)

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) Chieftain 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". 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)