GuildWiki has been locked down: anonymous editing and account creation are disabled. Current registered users are unaffected. Leave any comments on the Community Portal.


Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.


 1   2   3   4   5   6   7   8   9  10 11 12 13 14 15 16 17 18 19 20 21 22
This talk page should be used for discussions regarding GuildWiki in general. For anything directly relevant to the Main Page or the edit copy, please use Talk:Main Page/editcopy. If you have any questions that aren't relevant to a specific talk page, head over to GuildWiki:Request assistance and add it.


been using the official in the meantime, man the way they organize quests it makes it really difficult to see what you need to do to acquire the quests (IMO). It was driving me crazy, but not as crazy as the wikia skin. 16:26, 1 December 2010 (UTC)

Seeking Fansite status

I spoke briefly with ArenaNet's Community Relations Manager Regina Buenaobra yesterday about getting GuildWiki back on the official fansites listing now that we're off Wikia. She was very positive about it and directed me to the Fan Site Program page. Interestingly enough, losing our fansite status on Wikia was a blessing in disguise, because they're encountering a lot of difficulty with PvX's situation- the wikia site is still listed as an official fansite, but we don't have that issue. In particular, I'd like to draw everyone's attention to the eligibility expectations- I want to be sure we meet all the expectations before asking for a preliminary review. To that end, I'd appreciate input on the best ways to meet those goals. Felix Omni Signature.png 20:06, 1 December 2010 (UTC)

I think we do. We might have lost our fan site status, but that doesn't mean we allow porn or gold seller ads. We might not be as up to date as GWW, but we try our best. Go for it! Arnout aka The Emperors Angel 20:19, 1 December 2010 (UTC)
Should we add more RSS feeds? I think they have community news, and we could also do an updates feed in addition to the commented one we do. (Of course noen of these are archived on-wiki.) I'm also more than willing to paste ANet logos all over the place if needed. --◄mendel► 05:32, 2 December 2010 (UTC)
Just curious, what made us ineligible in the first place when Wikia took over? I can't remember that far back. -- Isk8.png Isk8 (T/C) 20:54, 2 December 2010 (UTC)
They accused "us" of money selling ads. Arnout aka The Emperors Angel 21:52, 2 December 2010 (UTC)
I think accused is the wrong word there. It was simply that we no longer had any control over the ads that appeared, and because Wikia couldn't reliably block the gold-selling ads, Anet could no longer allow us to have fansite status. —Dr Ishmael Diablo the chicken.gif 22:27, 2 December 2010 (UTC)
It's why I used "us". I knew it was wikia, so I tried to explain. But I don't blaim em for removing the fan site status. Arnout aka The Emperors Angel 15:59, 3 December 2010 (UTC)
Synopsis of requirements:
  1. High Quality and design Yes.png
  2. Legal req'ts, copyrights, etc; attribute properly Yes.pngMaybe.png
  3. Reflects positively upon the company and the game Yes.png
  4. No porn/porn links, hackz/piratz, gold trading, cheats. Yes.png
  5. Active moderation of forums/chats. Staff behaves appropriately. Yes.png
  6. To abide by the game's User Agreement and Rules of Conduct. Yes.png
I think we're in good shape, except for possibly how we use screenshots (our policy isn't as strict as GWW's, but I'm sure it's at least as good as Guru's).  — Tennessee Ernie Ford (TEF) 22:47, 2 December 2010 (UTC)
We could add a tiny ArenaNet or Guild Wars logo to the footer. Felix Omni Signature.png 22:51, 2 December 2010 (UTC)
That seems sensible, Felix. Is there any reason not to ™ ANet on every page's footer?  — Tennessee Ernie Ford (TEF) 23:00, 2 December 2010 (UTC)
I applaud your efforts at regaining fansite status. If Curse can be of any assistance, please feel free to ask. -- Wynthyst User Wynthyst sig icon.png talk 22:07, 3 December 2010 (UTC)
Can we have $100,000? Felix Omni Signature.png 22:09, 3 December 2010 (UTC)
Doubt it, but it's worth a shot :P --El Nazgir 22:20, 3 December 2010 (UTC)
And just how would that help you regain your fansite status??? -- Wynthyst User Wynthyst sig icon.png talk 23:00, 3 December 2010 (UTC)
Bribe budget. Felix Omni Signature.png 00:32, 4 December 2010 (UTC)

moved a recent post down for chronological reasons, --◄mendel► 18:40, 21 February 2011 (UTC)


This is awesome. Whoever made this possible is awesome. That's all. Thank you. Ethigenetic 20:42, 1 December 2010 (UTC)

We could only do it because the whole community was behind it. Now get the word out! --◄mendel► 06:27, 2 December 2010 (UTC)
I am sorry that it took Wikia behaving badly to get us to move. This new site already feels more like home than the old site did! Well done, Doc Ish, Felix, Mendel, RT, and everyone else who did the lion's share of the work to make this happen (coding, saving images, negotiating with Curse, scouting out new locations, keeping Wikia at bay while the work continued, etc and etc and etc).  — Tennessee Ernie Ford (TEF) 23:03, 2 December 2010 (UTC)

Meanwhile on Wikia

Browser screenshot - Which wiki was that again? o.O --◄mendel► 06:27, 2 December 2010 (UTC)

World of Warscape: Runiclysm Wiki. Can't you tell? It says so right on the top; if there's one thing the Wikia skin is knwon for, it's being clear about where you are.
Can't say how happy I am to be off Wikia. While I don't know that this'll affect my usual inactive activity level, one less tie to Wikia is worth celebrating! -- Jïörüjï Ðērākō.> 19:44, 2 December 2010 (UTC)
I say, embrace the change and make it work for us. Paid sponsorships of GW@wikia from the anti-wikia alliance?  — Tennessee Ernie Ford (TEF) 20:06, 2 December 2010 (UTC)
Hah! nice, I never see these backgrounds. Venom20 20:41, 2 December 2010 (UTC)
That is pure epic! -- Isk8.png Isk8 (T/C) 20:51, 2 December 2010 (UTC)
That's hilarious XD --Kirbman sig.png Kirbman 17:04, 9 December 2010 (UTC)

Even more ads in new places! --◄mendel► 20:29, 20 December 2010 (UTC)

Interwiki links

You can link to Guild Wars Wiki with e.g. gww:Jolvor Stoneforge; you can do the same with pvx: to link to PvXwiki, but to go to guildwars@wikia right now you need w:c:guildwars:. I suggest using wgw: for this (Wikia GuildWars), comments? Are there other sites you wish to link to easily, e.g. guru: or youtube: or whatever? (google: already works.) --◄mendel► 10:19, 3 December 2010 (UTC)

Would anyone who speaks Spanish be interested in inquiring at es: whether they want to set up mutual language links with us (we link to them, they to us)?

Also, somebody who speaks French (El Nazgir?) might inquire at fr: whether they'd change their en: interwiki to if we added links to them to all our pages?

What do you think about making "GWW" a language so that we can link to the official wiki from the sidebar? (Have a look at the Main Page sidebar to see what it looks like.) --◄mendel► 11:01, 3 December 2010 (UTC)

If you want persistent links to GWW, just install the page-top tab in common.js. Making that a language link doesn't make any sense. —Dr Ishmael Diablo the chicken.gif 13:24, 3 December 2010 (UTC)
The page-top tabs are not a logical place for this as they act on the present page. It would be possible to add an automatic link to the sidebar, even without javascript. The language links are a collection of links that lead to related pages off-site, that's why I think that gww: links would be ok there. The question is, do we want to? They're not linking to us. --◄mendel► 13:34, 3 December 2010 (UTC)
If they're not linking to us, then no, we don't need to edit all ~20k articles to add a link to them. —Dr Ishmael Diablo the chicken.gif 13:41, 3 December 2010 (UTC)
A good portion of the information on GWW is redundant with the information we have here- I see no reason to link to them on every article when it wouldn't be a useful addition. We could make a template to link to GWW for specific pages that they might cover in a better or different way- say, ArenaNet staff pages or armor galleries. Felix Omni Signature.png 14:59, 3 December 2010 (UTC)
While they may have official renders for armor/etc., I have heard many people say they prefer our in-game armor galleries. We are definitely deficient on staff pages, though. —Dr Ishmael Diablo the chicken.gif 15:14, 3 December 2010 (UTC)
I like ours better too, but there's no reason not to provide extra resources whenever we can. Felix Omni Signature.png 15:23, 3 December 2010 (UTC)
While I would love to help, and I disliked not being able to help with the move, but my French is terrible, especially written. I could try, but I'm afraid google translate would do better in an incredibly much shorter timeframe. I might be able to get some smaller mistakes out of google translate's version though.--El Nazgir 16:13, 3 December 2010 (UTC)

External links

You guys might want to look at,,, and linksearches and figure out what to do with all those. - 16:39, 8 December 2010 (UTC)

We've been discussing plans to run a bot to update those. Thanks for bringing this up here so we don't forget about it. —Dr Ishmael Diablo the chicken.gif 16:59, 8 December 2010 (UTC)
Have we decided on an interwiki prefix for gw@w yet? Some of these links will be to diffs and such and should point to now. Actually, I think we can just replace with most of the time. --◄mendel► 18:35, 8 December 2010 (UTC)
It would be better to changd all and to use the future-proof {{fullurl}} magic word. —Dr Ishmael Diablo the chicken.gif 19:09, 8 December 2010 (UTC)
Yes. --◄mendel► 21:03, 8 December 2010 (UTC)
I finally finished correcting all links to There are ~40 left, but they are either from .css/.js pages or are intentional links to the Wikia site. I'll try to remember to do the others soon. —Dr Ishmael Diablo the chicken.gif 17:16, 15 February 2011 (UTC)

We're moved! (Now what?)

So, Guild Wiki has finally obtained the independent, don't-tread-on-me hosting site it has desired since moving to Wikia. Huzzah! Long live Guild Wiki. But: now what?

It seems to me that there are any number of possible directions we can take:

  • Carry on. (Seemed to work for us so far, although there's no future for GWiki 2 on Curse.)
  • Step up our game (Compete more directly with GWW, even though we have trouble keeping up with the modest updates this year. Also: no GWiki 2.)
  • Complement GWW, instead of competing. (We already do better/different job in terms of walkthroughs, advice, innovation. Of course, done well, this would probably be bigger than the move.)
  • Squabble amongst ourselves about interesting and important, but non-critical issues. (Seems to occupy a big portion of recent edits.)

Are people ready to consider what's next? Or is everyone too exhausted from moving (and keeping GW@wikia safe from WikiaStaff) to worry about this now?  — Tennessee Ernie Ford (TEF) 23:07, 8 December 2010 (UTC)

I plan to continue implementing SMW across more classes of articles. I've simply been occupied with trying to get the last little things implemented that we need for the wiki to work how we want, as well as the normal real-life stuff that happens this time of year (read: stupidly-planned project deadlines that I had no say in setting but am now solely responsible for meeting). —Dr Ishmael Diablo the chicken.gif 23:19, 8 December 2010 (UTC)

Search box position

Should we move the Search box to be higher up? It feels awkwardly low, especially since its probably the box that gets the most use. Some lower resolutions even have to scroll down to see it. Let me (and the admins) know where you think it should be.

  1. stay where it is
  2. above the support box
  3. above the news box
  4. all the way at the top like it was in Monaco

I'm in support of 2, 3, or 4. --Kirbman sig.png Kirbman 17:14, 9 December 2010 (UTC)

We could remove the news box altogether, it's all on the main page anyway. Felix Omni Signature.png 17:20, 9 December 2010 (UTC)
Search should be high (useful to all). Command center should be at bottom (not useful to casual readers). Support should higher (somewhat useful to some). Toolbox should be higher (mostly useful to most). News should remain (not everyone visits main, especially frequent readers).  — Tennessee Ernie Ford (TEF) 17:55, 9 December 2010 (UTC)
Command center?
Agreed, news should stay. I haven't looked at the main page for information in years.
Imo, move Search to below Nav. Rest is fine to me. --Vipermagi 18:21, 9 December 2010 (UTC)
The "command center" is part of his custom javascript (based on mine).
Agreed, news is important because my default page is RC.
Agreed, search below navigation is a good place for it. —Dr Ishmael Diablo the chicken.gif 04:25, 10 December 2010 (UTC)
gww: has it between navigation and support; if we want to make it easy for readers to switch, we should go with option 2 or 3. --◄mendel► 22:34, 9 December 2010 (UTC)
I'm in support of #2.–User Balistic Pve sig.pngalistic 00:25, 10 December 2010 (UTC)
I'd be in favor of vector as default skin when curse is done it's fixing with the ads + all skins thing, the search is in the upper right hand corner such as UnAnswers uses. Though doesn't mendelbook have it there too? — Scythe 3:08, 10 Dec 2010 (UTC)
It definately needs to move up, since I have to scroll down everytime I want to use it.

I'm using a 10,1inch netbook with the standard resolution on it. Rook 16:51, 12 December 2010 (UTC)

I'm in favor of option 1. You'd need an extremely low resolution to have to scroll down for it... The navigation is more important, and search comes right after that imo.--El Nazgir 17:37, 12 December 2010 (UTC)
Oops, I should've mentioned here that I've already edited Mediawiki:Sidebar to put the search box below the navigation box (option 3 listed above). —Dr Ishmael Diablo the chicken.gif 17:41, 12 December 2010 (UTC)

Anti-Wikia Skin Alliance newsletter

moved to User:Anno1404/Anti-Wikia Skin Alliance newsletter

The AWA have sent us a letter. Since it doesn't "regard GuildWiki in general", I've moved it to User:Anno1404/Anti-Wikia Skin Alliance newsletter, and Gigathrash's comment to the talkpage there. Feel free to drop a short link paragraph here when new newsletters become available, but please do not assume that it will be a GuildWiki community matter. --◄mendel► 18:02, 18 December 2010 (UTC) (edited 22:08, 20 December 2010 (UTC))

We could say that the AWA is now looking for people who can help support admins and editors who have decided to move (but are having trouble making it happen). (Read the newsletter for details, if you are interested.) And hey, I just did! ^-^  — Tennessee Ernie Ford (TEF) 20:44, 20 December 2010 (UTC)

Overloaded (Curse) server

I've gotten overloaded server messages (from curse) 3 times in the last week (including today and yesterday). In one case (yesterday's), it was 15 minutes or more before I could view anything. Is anyone else experiencing anything similar?  — Tennessee Ernie Ford (TEF) 20:52, 22 December 2010 (UTC)

Never had any problems :S --El Nazgir 21:27, 22 December 2010 (UTC)
I had a curse message showing that there was maintenece or something. Went to bed short afterwards, so I don't know how long that lasted. Arnout aka The Emperors Angel 21:59, 22 December 2010 (UTC)
I had the same thing happen yesterday afternoon. After about 5 min, I just went off to do something else and came back later in the evening and it had passed. Nylana Greymoon 22:55, 22 December 2010 (UTC)
Happened to me a few times but always only lasted a minute or so. (So I herd we dont liek indents or wut) EM Signature.jpg ***EAGLEMUT*** TALK 23:34, 22 December 2010 (UTC)
Curse is working on it. Actually, that's part of the reason, because when the server configuration is upgraded, the caches are restarted, leading to a high load on the backend servers until things normalize again. --◄mendel► 23:35, 22 December 2010 (UTC)
Bryan was installing new servers and increasing the RAM in the existing ones yesterday, so that would explain any issues you encountered yesterday. He hasn't mentioned that the upgrade is complete yet, so if he was still working on it today, that would also explain today's issues. When the upgrade is complete, though, we shouldn't have any more performance issues. —Dr Ishmael Diablo the chicken.gif 00:08, 23 December 2010 (UTC)
That's good news. It would be great if Bryan et al could find a way to let us know before/during/after about any work that might affect performance. I have a lot of patience for planned maintenance; I don't have that much patience for spontaneous outages — and I cannot tell which is which without the kindness of administrative strangers. Thanks for the update, Ish.  — Tennessee Ernie Ford (TEF) 01:34, 23 December 2010 (UTC)
Bryan told us about it on IRC yesterday, right before the major outage started. If he had mentioned it sooner, I would've put something in the sitenotice, but since the site was already going under, I didn't have a chance.
We'll definitely mention this to him and ask that he give us more lead time in the future. —Dr Ishmael Diablo the chicken.gif 05:06, 23 December 2010 (UTC)
That would be good. I realize it might be difficult sometimes to alert all the curse clients at once, so mebbe they have some sort of sitewide notification service?  — Tennessee Ernie Ford (TEF) 05:24, 23 December 2010 (UTC)
I don't think this was Curse-wide, I'm pretty sure it was just us and PvX and maybe a couple other wikis. —Dr Ishmael Diablo the chicken.gif 14:11, 23 December 2010 (UTC)
Got hit again. Not sure how long it lasted because I don't bother checking anymore. I now assume that the outage will be indefinite and that I will have no way of knowing when or why it will be back up.
This is among the reasons it's important for Curse staff to put a timely notification system in place, targeted to whatever sites are affected by whatever planned operations on their schedule. There's simply no reason in the 2010s to leave the impression that a site is poorly maintained when the opposite is true. With a decent system, it won't add significant time to their change management process.
Wikia suffers from this same misunderstanding of customer/client/contributor communication: just because a company doesn't have an obligation to notify folks about system health doesn't mean it's smart to leave it to our imagination.  — Tennessee Ernie Ford (TEF) 01:25, 24 December 2010 (UTC)

(Reset indent) Today, I have seen some more Curse outage notices and, when I try to "Mark All Pages Visited" on my watch list, I get, "Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information." (this last is listed as a GWiki error; only the GWiki icon loads).  — Tennessee Ernie Ford (TEF) 19:56, 25 December 2010 (UTC)

I got that error when I tried to preview a change on Air Dragon (the change being the addition of a move tag). Only time I've encountered it. -- Konig/talk 20:05, 25 December 2010 (UTC)
I'm now getting "Servers temporarily at capacity" several times per day. Sometimes reloading resolves the issue; mostly not.  — Tennessee Ernie Ford (TEF) 16:52, 26 December 2010 (UTC)
I got the capacity error yesterday; it was the first Curse error I've seen. Felix Omni Signature.png 18:06, 26 December 2010 (UTC)
Same Felix, although when loading this page I got an overload error too, but when I clicked the "refresh page" button, it went fine.--El Nazgir 19:22, 26 December 2010 (UTC)
Have yet to run into errors except the one I mentioned here. EDIT: Viper here. Sig dun works? I guess that makes two errors. Checked prefs; nothing strange going on there. --<signature> 19:31, 26 December 2010 (UTC)
I'm glad other people aren't seeing errors as often as I am. However, I'm ready to give up posting/reviewing here for 1-2 weeks until I'm able to do so more reliably. I'm not seeing issues with other sites, with pings, or with other evidence that that there's an ISP issue or one internal to my home. I'm getting errors just trying to preview this.  — Tennessee Ernie Ford (TEF) 20:25, 26 December 2010 (UTC)
Just got a curse "server-full" error, while I was talking to Yamagawa on IRC about the show preview error (the same one TEF and Konig encountered) --Ezekial Riddle 01:17, 27 December 2010 (UTC)
I'm currently seeing about every 1 in 2 previews or edits fail on the 'Set $wgShowExceptionsDetails' error. Most annoying. Yamagawa 01:20, 27 December 2010 (UTC)
I am having errors in editing my user space page like the one Yama mentioned and the server overload one as well... Ariyen 02:54, 27 December 2010 (UTC)

502 Bad Gateway

I've gotten this error a LOT lately, at least 10 times over the past day or so. It happens when I try to save a page or revert an image, including rollbacks. It doesn't occur during regular browsing however.--Łô√ë Gigathrash sig G.jpgîğá†ħŕášħ 10:04, 3 January 2011 (UTC)

Ditto. Felix Omni Signature.png 12:24, 3 January 2011 (UTC)
Same. Also, editing this took a hell of a long time to load.--TalkpageEl_Nazgir 14:59, 3 January 2011 (UTC)
Same. It also seems like most of the time the edit does get saved, but not always. Rose Of Kali Rose Of Kali SIG.png 22:09, 3 January 2011 (UTC)
4 out of 5 more-than-read actions result in the 502 or connection reset error (i.e. I haven't seen an issue navigating to an article, only previewing, saving, or viewing diffs). (also: cannot tell if page has been successfully saved)  — Tennessee Ernie Ford (TEF) 04:03, 4 January 2011 (UTC)
Hmm, I don't think I've encountered it while previewing or viewing diffs, only when trying to save changes, i.e. changing something on the server that affects what other users see. If I get the error, I hit Back and open the page in a new tab to see if my edit got saved, and re-save if needed. Good thing FFox preserves all I typed in the edit box when going back. Rose Of Kali Rose Of Kali SIG.png 06:22, 4 January 2011 (UTC)
Same as Rose... Also: hurrah for Opera :P (but let's not derail this into a browser contest...)--TalkpageEl_Nazgir 09:04, 4 January 2011 (UTC)
Correction: Am now seeing it simply when navigating to articles (direct URLs, followed links, and searches).  — Tennessee Ernie Ford (TEF) 09:48, 4 January 2011 (UTC)
I even got it when mailing users here. Arnout aka The Emperors Angel 09:49, 5 January 2011 (UTC)
It seems to me its spiking again. Over teh past few days, I made more then a few edits, and some where double, because I got a 504, even though the edit was saved. And refreshing RC is getting troublesome too. Arnout aka The Emperors Angel 22:38, 8 February 2011 (UTC)


← Moved from User talk:Dr ishmael#ConfirmEdit

Hey doc, aren't we supposed to have that installed/running? --JonTheMon 15:12, 23 December 2010 (UTC)

No, mendel said it would "tone down the appeal of the wiki" by "discouraging anon edits," so we didn't have it installed. I'll push it to the repository, hopefully Bryan will check in today so we can get it pushed live. —Dr Ishmael Diablo the chicken.gif 15:42, 23 December 2010 (UTC)
Think that's going to stop the spammers/vandals much? Or rather stop anon edits? I know that on minor changes, if I'd run into those, I'd say "sod it" more often than not. --◄mendel► 15:43, 23 December 2010 (UTC)
At the very least, confirm edit can kick into gear for things like urls for anons. --JonTheMon 15:50, 23 December 2010 (UTC)
ConfirmEdit can be configured - we've already had this discussion. —Dr Ishmael Diablo the chicken.gif 15:57, 23 December 2010 (UTC)
I'm actually going to go with the reCAPTCHA extension, which is the same thing (it includes the ConfirmEdit code and simply builds on it) with a much stronger captcha. Bots could easily recognize and respond to plain-text math questions, which is the default in ConfirmEdit. The other options in ConfirmEdit mostly require additional server-side configuration, which we should avoid.
reCAPTCHA uses the same trigger settings as ConfirmEdit, and the defaults in the current version are as follows:
$wgCaptchaTriggers['edit']          = false; // Would check on every edit
$wgCaptchaTriggers['create']        = false; // Check on page creation.
$wgCaptchaTriggers['sendemail']     = false; // Special:Emailuser
$wgCaptchaTriggers['addurl']        = true;  // Check on edits that add URLs
$wgCaptchaTriggers['createaccount'] = true;  // Special:Userlogin&type=signup
$wgCaptchaTriggers['badlogin']      = true;  // Special:Userlogin after failure
I don't see any reason to change these. Also, I changed group permissions for Users and (all) to remove the writeapi permission, since vandal-bots could easily use that vector to bypass all our other protection mechanisms. —Dr Ishmael Diablo the chicken.gif 18:02, 23 December 2010 (UTC)
Which groups should the captcha trigger for? By default I believe it's anons, new users and auto-confirmed. --JonTheMon 18:06, 23 December 2010 (UTC)
I'm setting it for anons only. We trust our registered users (and they're easier to block). —Dr Ishmael Diablo the chicken.gif 18:07, 23 December 2010 (UTC)
I just wonder if it'd help to have captcha true on say page creation and edits... Well, would that help against vandalisms and at least autobots? Ariyen 18:08, 23 December 2010 (UTC)
Take that up with mendel, he doesn't want to scare away potential editors. —Dr Ishmael Diablo the chicken.gif 18:11, 23 December 2010 (UTC)
Speaking as a potential editor of other sites:
  • I am 5% less likely to contribute the occasional edit to a site that requires confirmation (that goes up to 10% if CAPTCHA is the requirement rather than 4+5=...).
  • I am 1% more likely to register as a user for the same site if I find myself contributing more than X edits in Y weeks.
  • I am 70% less likely to contribute to the same site if I perceive it to be unable to handle vandalism.
So, while I agree with Mendel that we should err on the side of openness for anons, I don't think that adding a minor hurdle is going to scare aware well-intentioned folks.  — Tennessee Ernie Ford (TEF) 19:51, 23 December 2010 (UTC)
I registered at PvX to get rid of their obnoxious captcha (gotta type 2 skill 1-word names. Every edit. Ugh). I also contributed a lot, though. If I just wanted to make an edit a week or less, I'd rather just forget about it and not edit at all. --Vipermagi 20:25, 23 December 2010 (UTC)
To both Ernie and Viper: If the instructions for the captcha included a friendly reminder that you could completely disable them by creating an account, for free, with a link to the signup form, what would you do? I've already made that modification to the reCAPTCHA message that will be displayed to our anons. —Dr Ishmael Diablo the chicken.gif 21:12, 23 December 2010 (UTC)
I don't hate Captcha as much as Viper, but it would reduce my participation on a site slightly. I would not be inclined to sign up simply to avoid it. I use different logons for different types of sites, use multiple passwords, need to coordinate some sites across multiple machines, etc. So, for me, signing up is more trouble than it's worth for casual participation. Captcha, horrible as it is, is less trouble.  — Tennessee Ernie Ford (TEF) 21:27, 23 December 2010 (UTC)
As configured, an anon would only get the captcha for putting urls on pages, registering, and having bad logins. How do you two feel about those scenarios? --JonTheMon 21:40, 23 December 2010 (UTC)
The captcha for registering is almost standard practice, if someone has a problem with it they're going to be unhappy with most of the internet. The bad login one is reasonable, though I know if I typed my password in wrong once, I already feel frustrated at having to type it in again, let alone having to type something extra. Good thing I never get my password wrong, as I use Keepass (Thanks Doc!) As for the url one: does it apply to all external links, including gw@wikia, gww, wikipedia, etc.? Other than those, I don't see any reason why anyone would need to post a lot of external links on a lot of pages, so the captcha shouldn't be too annoying, and if someone feels the need to spam a link to their shoddy Gate of Madness "walkthrough" video on Youtube, well, they can deal with it. --Macros 22:46, 23 December 2010 (UTC)
If you use the interwiki prefix inside double-square-bracket notation, then no, those are not considered external links (even though they link to something outside the wiki). In this context, "external" links are those entered as an actual URL, optionally using the single-square-bracket notation.
The badlogin only shows a captcha after 3 failed login attempts, so if you just fat-finger it once or twice before realizing your capslock is on, you won't see it. —Dr Ishmael Diablo the chicken.gif 22:56, 23 December 2010 (UTC)
Oh, well, that's perfectly reasonable, from my point of view. --Macros 23:06, 23 December 2010 (UTC)
(edit conflict) Request more interwiki links if you need them, the admins can add them. Would an anon have to captcha if they edited a page with a URL already on it? -- 23:07, 23 December 2010 (UTC)
No, only if new urls are added. That's why the trigger is called 'addurl'. —Dr Ishmael Diablo the chicken.gif 23:10, 23 December 2010 (UTC)
The bad login captcha on pvx forced me to jump through hoops after I messed up my password once- it made me enter the captcha, then copy+paste a string of characters into a mysterious text box, then retype my user name, then retry the password. I wouldn't mind if we didn't have captcha for bad logins at all, the likelihood of people bothering to bruteforce a free wiki account is pretty low. Felix Omni Signature.png 07:07, 24 December 2010 (UTC)

Currently, pages being bot-spammed are mostly off the main (who sees the editcopy or the "recent discussions"?). So the main consideration here is, does the spam annoy more people reverting it than a captcha would annoy anons editing? How many reverts do we save, as opposed to the number of captchas anons would be exposed to? Can we get some numbers? --◄mendel► 08:44, 24 December 2010 (UTC)

It seems like you're still missing the point that this will only trigger when someone adds an external link to a page. (And once when creating an account, and after 3 failed login attempts). It will not trigger on every single edit. I'm not going to go data-mining to satisfy your paranoia, but I know it's very rare that we have an external link added to an article. —Dr Ishmael Diablo the chicken.gif 14:16, 24 December 2010 (UTC)
We currently have 1 to 1.5 new accounts per day (should be increasing if our traffic is rising), so that's a number to watch, then. I think spambot incidence is higher? - 16:38, 24 December 2010 (UTC)

Captcha on addexternal also kicks in when reverting a vandal who blanked a page with an external link on it. We should try to make sure we have no external links on mainspace pages by setting up enough interwiki aliases and using fullurl: . -- 18:33, 25 December 2010 (UTC)

You should create an account then. —Dr Ishmael Diablo the chicken.gif 15:47, 27 December 2010 (UTC)
What's wrong with the suggestion? --◄mendel► 22:09, 27 December 2010 (UTC)

(Reset indent) Ok, ConfirmEdit, yes/no? If yes, it'd be nice to get it pushed sooner rather than later. --JonTheMon 17:21, 27 December 2010 (UTC)

GW2-related articles

Since I heard that there would be no "Guild2Wiki" (or w/e the name would of been), I'm wondering if there's anything intended to be done with existing and future GW2-related articles (for instance, Zhaitan, Sylvari and pretty much everything here). Just wanting to know because I'm beginning to go through lore articles here like I have on the official wiki for a while, and removing speculation/inaccuracies that are presented as facts (a common reason for not using the GuildWiki for lore purposes), and I wanted to know where to stop with my edits to articles. -- Konig/talk 20:11, 25 December 2010 (UTC)

I think only the stuff that's relevant to the current game should be here, but once it gets out of the scope of GW1, it should link off to GW2W. A small intro type paragraph and a single image is the most GW2 info that should ever be seen on those pages, such as Zhaitan. And only the most important GW2-related pages should exist here if they have little to nothing about them in GW1. Rose Of Kali Rose Of Kali SIG.png 04:50, 27 December 2010 (UTC)
/agree with Rose.--El Nazgir 08:06, 27 December 2010 (UTC)
I don't like breaking up the lore and spreading it across two wikis with reference to some decision that AFAIK has never been formally made (and it would IMO be too early to). --◄mendel► 22:07, 27 December 2010 (UTC)
I also don't like breaking up lore if possible. Though I'm not concerned with expanding lore information here, I just want to get rid of speculation and this became a curious thing I was wondering about. The template seems very unnecessarily page-breaking (especially for those like norn which have it mid-way). I'm not against the idea of going all-out for lore for articles relevant to both gw1 and gw2, but it seems silly to have articles relevant only to gw2 here.
And that template... *wishes to stab it*-- Konig/talk 00:37, 30 December 2010 (UTC)

Templates and unregistered users

What do you think of semi-protecting all templates from unregistered users? One vandalism has the potential to break hundreds or thousands of pages where the template is used until it's reverted, and most if not all templates are maintained by a handful of our regular users, while rarely (if ever) receiving useful edits from IP's. This is stemming from spambot edits like this. And while edits like these usually get caught quickly and taken care of, I don't see a reason not to semi-protect mainspace templates. Rose Of Kali Rose Of Kali SIG.png 16:48, 27 December 2010 (UTC)

That specific template probably should be protected, since it is used on the Main Page. Most high-usage templates are already protected at the admin-only level. There's no pressing need to protect all the thousands of other templates that aren't so highly visible. —Dr Ishmael Diablo the chicken.gif 17:02, 27 December 2010 (UTC)
I think we should leave things unprotected until there's a compelling reason to protect. The particular edit you link would have been prevented by the plan (above) to ask for validation from anon edits that add an external URL. If templates start to be hit so frequently that we can't keep up, then we can temporarily semi-protect (and discuss permanent semi-protect). In the meantime, I think we do damage to the wiki's openness and inclusiveness every time we protect something. Not a lot of damage, of course, but those qualities are two of the things that set us apart from other wikis.
It's worth reviewing all the templates used in main-space and the few that are used on lots of pages; some of them might be appropriate to restrict to admins (as Ish notes) or registered users.
I also think we should re-ask this question every 4-6 months; bots get smarter, sysops get busy, contributors focus on other things.  — Tennessee Ernie Ford (TEF) 17:09, 27 December 2010 (UTC)
I think the templates that are used for like say mainpage/editcopy or main pages should be protected from Ip vandalism... As I fear it could hurt many pages, if a vandal does ruin a template and cause issues/problems. Ariyen 17:22, 27 December 2010 (UTC)
Right, I agree with all of you. I guess I wasn't really meaning all the obscure templates on the entire wiki, but mainly the high traffic ones that are used on the main page and similar high traffic pages. I also think that the highest level armor gallery template should also be protected just due to the sheer number of image galleries involved, which would all be getting recached and re-recached after each change, though that might not be as big an issue as I think (is it?). Keep in mind, I'm not asking admin-only level protection, only IP block. If you prefer to keep this to a case-by-case decision, that'll work as well. Rose Of Kali Rose Of Kali SIG.png 17:34, 27 December 2010 (UTC)
Protecting specific high-visibility templates is exactly what I think we should do - I should've made my position on that more clear above. —Dr Ishmael Diablo the chicken.gif 17:59, 27 December 2010 (UTC)
Now just to figure out what those are, aside from the ones that are already protected. I guess that'll just come along as we notice them. The one I linked is a start. Rose Of Kali Rose Of Kali SIG.png 18:55, 27 December 2010 (UTC)
We want unregistered users to participate as much as possible, and I seem to recall constructive template namespace edits do happen. In this case, the temnplate gets edited because the page got protected - if you want to fight this battle, be prepared to end up protecting most of the wiki, because a vandal always finds a place to vandalize. Wikis used to work by making it more easy to fix vandalism than to commit it - by entering the "protection fight", you are giving teh vandal attention and an objective of interest, and that's precisely what you want to avoid: you want to bore him into editing the same page and the edit always getting reverted without further reaction shortly. Most other approaches are less effective, in my opinion.
High visibility pages can be protected (if desired) with cascading protection (or do we not have that here?) which automatically protects all templates on it, and would presumably un-protect them once the originating protection is removed.
High use templates (those used on hundreds or thousands of pages) have long since protected. --◄mendel► 22:04, 27 December 2010 (UTC)
High use does not necessarily equal high visibility, as in the above example, but both types deserve protection. I think you are overly protective of the few constructive edits that were made by anons to high visibility/use templates (I'm not saying they never happen, but most of those templates are finalized and should rarely need any edits at this time). I don't want to get on the slippery slope and start protecting everything on the wiki, that's not the point. There's "don't feed the troll" and there's also "don't leave the pantry door open." I'm just trying to find a reasonable balance between risk and merit. Rose Of Kali Rose Of Kali SIG.png 22:27, 27 December 2010 (UTC)
The editcopy page is neither high use nor high visibility, yet it got protected.
My point re: high-use templates is that the discussion is pointless, these have always been protected and still are.
My other point is that if you want to protect high-vis pages, do it right instead of piecemeal (i.e. Template:Copyright should not have been protected separately, unless we don't actually have cascading protection, in which case we should get it).
How much is "overly protective", and why am I it? Please answer this on my talkpage. --◄mendel►
Then let's do it "right" if the feature does exist. The point of these discussions is to find the best solution to things. :) Rose Of Kali Rose Of Kali SIG.png 22:45, 27 December 2010 (UTC)
I'd say the edit-copy is pretty high visibility, and I'd agree with protecting it from anons. --El Nazgir 22:50, 27 December 2010 (UTC)
"This page has been accessed 280 times." This statistic is found in the footer of the page; I don't really know how accurate it is, but according to it, there are right now 269 pages more popular than it is. --◄mendel► 06:59, 28 December 2010 (UTC)
Of course we have cascading protection, mendel, it's a core feature of MediaWiki. The problem with enabling it on the Main Page is that you can't pick-and-choose which transcluded pages get cascaded - it's going to protect everything that's transcluded there, which means all of the "forecast" templates, and specifically, the Traveler one, which needs to be updated every week. And over the past 5 weeks, 3 of those updates have come from anons. —Dr Ishmael Diablo the chicken.gif 23:30, 27 December 2010 (UTC)
I agree with Rose's suggestion that we should handle protection on a case-by-case basis. When in doubt, mention the discussion here to invite more opinions. There are potentially other solutions, too, e.g. validation (to prevent bot edits).  — Tennessee Ernie Ford (TEF) 03:37, 28 December 2010 (UTC)
The case-by-case is exactly what's happening: we protect the mainpage, so the vandals go for the editcopy; this effect is intended. Once the editcopy got protected, the vandal went for a template transcluded on it, which also affected the mainpage (which is worse, actually). Protect that one, what's he going to do then? We can't "close the pantry door", as Rose says, because we're a wiki, and everyone can edit. We can direct vandalism; by protecting it, we do direct it; but by doing these protections case-by-case, we're not really making ourselves aware of this going on.
Taking a closer look, many sysops seem to be aware that what is closed must eventually be opened again, time-limiting their protections. This is good. --◄mendel► 07:32, 28 December 2010 (UTC)
I think part of doing a case-by-case basis is identifying what kind of vandal source we're talking about. If we're talking about a person maliciously editing, that's one thing, and it's hard to keep up. If it's a bot, we can implement tools to stop/stall them. As this seems to be bot-like behavior, I think some spam/vandalism extensions would be sufficient. --JonTheMon 15:51, 28 December 2010 (UTC)
If the vandal is going to vandalize anyway, and we're gonna be reverting him anyway, might as well be on something less in the face of the readers, but kind of behind the curtain, if you will. So I still absolutely think that we should protect as much as possible of what shows up on the main page. And while it would be bad to protect the Nicholas' and other forecast templates that need frequent updating, I recall a few cases where users were commenting about some weird item Nick is asking for because the template was tempered with, and stayed cached a while after the vandalism was reverted. I admit that I know next to nothing about this sysoping/protecting/blocking stuff, but the least I can do is bring it up for discussion. If you guys can recognize some kind of pattern in what these vandals are doing and somehow screw it up, that would be great. If not, we're left with dealing with the symptoms rather than the cause. "Bad" external links are definitely worse than just gibberish vandalism, so they deserve the most attention. Is it possible to block external links being added by anons to specific pages, without blocking other anon edits, or blocking/forcing validation of external links being added by anons on the whole wiki? I noticed there's a "blacklist" of external links, but is there anything more that can be done, if semi-protection isn't an option? Rose Of Kali Rose Of Kali SIG.png 16:36, 28 December 2010 (UTC)
While some things may be okay for Ips, etc. to edit. I think other things that have a bigger "effect/affect (not sure which word to use there)" should be left to the registered users to edit. By this, I mean things like the Traveler, etc. I don't think things like the traveler template should be permanently protected to where only the sysops should edit them, but I know they can be protected enough that the users, etc. can edit them. While this may deter the Ip edits a bit, I don't think it'd hurt all that much. Ips can leave comments as to where he is or register to edit where he is and even may upload an Image of his location. This would help deter a little bit of the vandalism. Maybe we should create a list of what should be protected and to what extreme? I would like to see an extension that would detect the site links and not allow any of that, unless it's sites we already have in a list that we'd allow like youtube, facebook, mmorpg, guru, etc. Thoughts? Ariyen 23:43, 28 December 2010 (UTC)
You may be onto something here, Ariyen. Is it possible to disallow IP's to link to external websites except for a certain "white list" like the examples Ariyen gave? All non-white list links would then have to be validated, or the IP would have to register and log in. Rose Of Kali Rose Of Kali SIG.png 01:40, 29 December 2010 (UTC)
mw:Extension:ConfirmEdit and mw:Extension:Spam blacklist, both of which are now installed here. —Dr Ishmael Diablo the chicken.gif 02:28, 29 December 2010 (UTC)
Most other websites we would wish to link to can get "interwiki" links (such as google:) that allow anyone to form links that we can possibly get to keep working even if the site layout changes. These don't count as external links and can be placed by anyone. Indeed we could hack it so that www: would just be http://www.$1 and that would allow any editor who knows about this to linkt to pretty much any website, but nots would be to "stupid" to do that. --◄mendel► 14:32, 30 December 2010 (UTC)

fansite redux

So, is there any news on us getting our fansite status back? --El Nazgir 22:51, 27 December 2010 (UTC)

No, but if everyone is comfortable with the current state of the wiki I will request a preliminary review from the CR team. Felix Omni Signature.png 22:55, 27 December 2010 (UTC)
If there are any anti-spambot measures left to put into place, it might be wise to hold off until that's done. Having things like this in RC would likely not reflect the best on us. Though I'm not entirely certain that it would prevent qualification, either (unless some of these bots were posting RMT links...) — ızǝ 07:17, 28 December 2010 (UTC)
True, but I personally haven't got a clue what we can do against spambots other than reverting them, seeing as their IPs constantly change.--El Nazgir 09:41, 28 December 2010 (UTC)
I'd also like to make sure these Curse errors have settled down gone away. Felix Omni Signature.png 10:17, 28 December 2010 (UTC) (fixed that for you, --◄mendel► 00:14, 29 December 2010 (UTC))
How about something that blocks linking posts from IPs. If we wanted to make it useable for well-intentioned anons then we could just do something like pile them somewhere for review, and create a blacklist filter (is that even possible?) — Scythe 1:07, 29 Dec 2010 (UTC)
mw:Extension:ConfirmEdit and mw:Extension:Spam blacklist, both of which are now installed here. —Dr Ishmael Diablo the chicken.gif 02:28, 29 December 2010 (UTC)
I haven't encountered any errors in a couple of days. I know the ArenaNet staff doesn't work on weekends, so I'll submit a request for review on Monday unless something terrible happens. Felix Omni Signature.png 23:13, 30 December 2010 (UTC)
I'm still encountering errors at about the same frequency as before. Also, Regina mentioned that the person replacing Emily as GWW liaison (and related community relationship duties) was out until early January, so it's possible that we might have to wait a while.  — Tennessee Ernie Ford (TEF) 00:00, 31 December 2010 (UTC)
Regina is the person I talked to regarding fansite status in the first place. She and the other CR managers (Martin and Stephane) are in charge of it, not Emily. Felix Omni Signature.png 02:45, 31 December 2010 (UTC)
Since we still have our fair share of errors, I'm going to hold off on requesting review. Felix Omni Signature.png 12:24, 3 January 2011 (UTC)

anon edit confirm for URLs

Decided to start a new topic from the above two. So here's what I'm thinking: Add a CAPTCHA Edit Confirmation to anon edits that add URLs. Also add interwiki links to common "good" sites, such as google, youtube, etc. (We'd have to expand and implement the interwiki list before going forward.) There's a good possibility that anons will not be familiar with some or all interwiki links, so add a note to the "you're adding a URL" error message with a link to interwiki links list, so that anons can easily discover them and use them in the future without having to enter the CAPTCHA again.

This pretty much completely takes care of IP link spam bots. (Sure, the bots can modify their spam to use (dot) or otherwise avoid the captcha trigger, but then the link becomes unclickable, which is a ton better than clickable spam in my books.) It also affects a small number of "good" anon edits, and only adds a simple step in the case that they're wanting to add some oddball external link, without completely blocking the edit. Am I understanding this correctly?

Yay? Nay? Maybe? Any modifications? Rose Of Kali Rose Of Kali SIG.png 16:26, 30 December 2010 (UTC)

If how you're saying it is correct (although I'm not familiar enough with the terms to fully understand if I'm afraid :S ), I can get behind that.--TalkpageEl_Nazgir 16:49, 30 December 2010 (UTC)
Like I said above: we already have this. And I don't think we should abuse the interwiki feature, either. If anything, we should be encouraging anons to register instead of dumbing-down the wiki for them. —Dr Ishmael Diablo the chicken.gif 16:55, 30 December 2010 (UTC)
Oh, is the CAPTHCA enabled? And I was talking in the spirit of encouraging anon edits without encouraging them to register, because you know why. Though, for me personally, seeing fewer ads is reason enough to log in. :P There's a long list of pros to registering, but we all already know this.
I don't know if I'd call that "abuse" of the interwiki feature, but it might just be that I don't know enough about it. Rose Of Kali Rose Of Kali SIG.png 18:54, 30 December 2010 (UTC)
Curse has ads for logged-out users only? That's neat, I didn't know that. Is it true? --◄mendel► 21:52, 30 December 2010 (UTC)
Currently, we have no ads at all. That may change soon, though. —Dr Ishmael Diablo the chicken.gif 22:04, 30 December 2010 (UTC)
Curse doesn't have ads? O_O Neat! But you're just making fun of me now, so forget the whole thing. Rose Of Kali Rose Of Kali SIG.png 22:57, 30 December 2010 (UTC)

Tabs to Wikia

I think it's great that we can easily link to GWW, but why do we want to link to Wikia? In fact, I would go so far as to say I don't want us to do anything to direct traffic to GW@Wikia. I don't think there's any value for Guild Wiki in doing so. I can see that we discussed the GWW links, but I don't see where we discussed (and agreed) to link to Wikia. Could we have the tab removed pending consensus on whether it should be there or not? Thanks.  — Tennessee Ernie Ford (TEF) 08:50, 13 January 2011 (UTC)

I agree with TEF on this one.--TalkpageEl_Nazgir 11:30, 13 January 2011 (UTC)
Um, you copied that .js code from me. That's not on our Common.js. —Dr Ishmael Diablo the chicken.gif 13:41, 13 January 2011 (UTC)
Sigh. Well a big d'oh from me and a big apology to everyone for my confusion. (And, yeah, obviously, the wikia tab can be very useful to individuals for a variety of reasons). Thanks, Ish, for clearing up my misapprehension.  — Tennessee Ernie Ford (TEF) 17:17, 13 January 2011 (UTC)

Tabs to GWW

As I've mentioned elsewhere, I like that we have a tab pointing to similar/corresponding articles on GWW. I have two questions:

  1. Should we adjust our pointer to go directly to the correct article? Or is it ok if we point to a redirect page?
  2. How do we fix things when we know that we are pointing to a non-existent page? For example, we have Rabbit Valley, but they have GWW:Rabbit hole to refer to Nulfastu's little zone of weirdnesss. (And they do not have a redirect from Rabbit Valley.)

I'm sure there's a simple bit of code that can be placed on the page to fix these things, but I can't find it. Thanks.  — Tennessee Ernie Ford (TEF) 08:54, 13 January 2011 (UTC)

I vaguely recall that some time ago (when GWW was still in its infancy), someone (maybe Entropy?), was trying to create a system where you could click a tab or something on the sidebar that would link to the page of the exact same name on GWW (probably using {{PAGENAME}}). It was in their personal .css, not sitewide. I don't know if it ever worked, but it sounded pretty simple (even by my standards!) But of course, as you mention, the problem would be with pages that don't exist on GWW. Would they object to simply creating redirects corresponding to names we use here? Or the other way around, the link would be to a page here on GuildWiki with the same name as the one on GWW, and that would redirect to GWW... or something like {{DEFAULTSORT}} for redirects... or something. --Macros 09:52, 13 January 2011 (UTC)
When Cleo's job is finished, we can just take another copy of the language links, and any instances where there are special cases for gww and us are those where the naiming differs, pretty much; there's going to be fairly little remainder that won't work.
I don't know where the name correspondence list ist going to be kept; it's been my suggestion to implement it as another type of langugage links, but that didn't seem to be favored at the time. If you're editing on gww: anyway, why not get support for redirects there; since wikis are not paper, it won't hurt to have those redirects on any wiki (there'd be redirects here for the switch back, too), and that'd solve your problems without much ado, all that's needed are two complete lists of mainspace article names each (one with redirects, one without), and the issue could be solved.
Also, I might point out that "we" do not have a tab; it's an undocumented personal JS installable option that few people use; it could be made into a preferences option with some skin work, or installed sitewide; but for that, the feedback was that we wouldn't link to gww: if they didn't link to us. Reconsider? --◄mendel► 11:44, 13 January 2011 (UTC)
I never understood the need to link to GWW in the first place. The large majority of articles are very similar, and since we are both encyclopedic, we are in direct competition with each other. I don't think it needs to be reconsidered, as linking to them doesn't provide any actual benefit. The articles that we have very little information on, they have very little information as well. And the articles that GWW has that we don't are mostly developer blogs and the like that we don't have pages for anyway, and thus we would have to create an empty page to support a tab that leads to a different website.--Łô√ë Gigathrash sig G.jpgîğá†ħŕášħ 14:25, 13 January 2011 (UTC)
We have users who like to consult both wikis. Suggested strategies differ, gww: has more pages and more info, especially on the recent War in Kryta content; if we were a commercial concern, we'd focus on getting that content up to speed before filling little used landmarks in; but since we're just a bunch of hobbyists, that's perfectly ok :). Because we're a community driven project and like to allow minorities to put their stiff on here as long as it doesn't get in the way of everyone else, obliging the minority (is it?) who wants to see these cross-links is what we ought to do, even if you personally don't see a benefit. I doubt that there are GuildWiki readers who are not yet aware that gww: exists, so I don't see the harm done. --◄mendel► 15:51, 13 January 2011 (UTC)
I won't allow any minority stiffs around here. Felix Omni Signature.png 16:07, 13 January 2011 (UTC)
"Undocumented"? This begs to differ. —Dr Ishmael Diablo the chicken.gif 15:01, 13 January 2011 (UTC)
Well, for it to be a community feature, I'd expect a notice how to enable this in a place more prominent than that (e.g. on the Community Portal). And since we're talking about this here, is it to be considered a community feature? Or do we want it to be in the future? --◄mendel► 15:51, 13 January 2011 (UTC)
"I like that we have a tab pointing to similar/corresponding articles on GWW." No, *we* don't. You have it because you copied my monobook.js, just like the Wikia tab above. —Dr Ishmael Diablo the chicken.gif 15:00, 13 January 2011 (UTC)
(1) Well apologies again. So, we don't have the tab.
(2) Undocumented? Who said that? "I'm sure there's a simple bit of code that can be placed on the page to fix these things, but I can't find it. " Thanks for providing the link.
(3) I think we should have such a tab, but that's a different discussion; please don't hijack this one b/c I got confused between what was in common.js and TEF.js. I think it's a good idea, but I don't think it's urgent (I'd personally prefer that we consider what type of wiki we want to be). (@Mendel: we did start a discussion about this; it just never included a so, let's implement it sentence. The opinions were basically the same as listed here.)  — Tennessee Ernie Ford (TEF) 17:32, 13 January 2011 (UTC)
Following up, I don't see that there is currently any way to fix the pointer from GWiki to GWW by adding a simple bit of code. If it points to a redirect page, well, hey, that gets the job done. If it points to a non-existent page, we have the option of creating a re-direct (which I will do for the aforementioned Rabbit Valley). Since I was so obviously wrong about, well, everything, let me know if I misunderstood this bit, too.  — Tennessee Ernie Ford (TEF) 17:36, 13 January 2011 (UTC)

(mission) / (location) / (explorable)

While working on the new location infobox, my attention has been drawn to the way that we disambiguate missions, mission outposts, and explorable areas that share the same name. This isn't my first involvement with this issue, either: 2.5 years ago, I undertook the task of making them compliant with GW:ULC (e.g. converting (Mission) -> (mission)).

A similar proposal to the one I'm going to make has come up before, and while it was mostly shot down back then, I think the time is right for us to reconsider it.

The changes I'm proposing are as follows:

(location) -> (outpost)
According to the location article, we use "location" as a generic term to cover a vast swathe of topics. Identifying an article as (location) really doesn't provide any useful information about what exactly the article is about.
(mission) removed completely
Currently, [<name>] redirects to [<name> (mission)]. The argument for this was that "most people who search for <name> are looking for info on the mission." If so, then why bother with the redirect at all? Just put the mission article at <name> so that it's simple to write links to it.
(explorable) clarified to the full terminology -> (explorable area)
Not as serious as the others, but I think it makes sense to do so.

Some of you have probably noticed that these changes will put our naming schemes in line with GWW's. It seems to me like there's been increasing interest lately in making it easy for readers to switch between different wikis (e.g. interlanguage links to the German GuildWiki). By undertaking these changes, we eliminate the most visible disconnects between GuildWiki and GWW, making it easier for us to recommend the GWW switch tab to a broader range of readers, if they wish to use it.

I will of course volunteer to perform all the link updates through AWB, should we agree to go ahead with any or all of these changes. —Dr Ishmael Diablo the chicken.gif 22:09, 14 January 2011 (UTC)

Short version: I have no consensus-blocking objections (I disagree on only very minor points).
Long version: I think there are other, more serious issues to resolve (e.g. we're missing details about WiK, HotN, accurate maps, ...). However, I think reviewing the standards we use and adjusting is generally worthwhile, especially when we are updating associated templates/info boxes.
  • Yes.png (location) → [specific]
I can't think of any reason that we should use (location)
  • Maybe.png (mission) → remove
What's the harm in keeping a redirect? I sometimes find it faster to fix the URL (e.g. outpost → mission) than to search for a link, so it's also vaguely useful.
  • Maybe.png (explorable) → (explorable area)
I don't see any benefit for GWiki, but I agree there's some benefit to readers of both; it makes GWiki → GWW links easier.
See also: name similarity matrix. (@doc ish: that last might be vaguely useful for Services)  — Tennessee Ernie Ford (TEF) 01:22, 15 January 2011 (UTC)
I don't have any objections. I'd be glad to be of help, though. :-) 10:16, 15 January 2011 (UTC)
I agree fully with TEF. First is complete agree; second I say keep redirect; third is not necessary but definably helpful. -- Konig/talk 12:20, 15 January 2011 (UTC)
Since we (read: everyone who took the time to comment) are unanimous on (location) -> (outpost), I'm going to try to get started on that tonight. —Dr Ishmael Diablo the chicken.gif 22:30, 18 January 2011 (UTC)
Bah, didn't have time tonight. Won't have time tomorrow. Bah. —Dr Ishmael Diablo the chicken.gif 04:23, 19 January 2011 (UTC)
Okay, I'm going to make the moves while at work today. I can't run AWB from here, so I'll just compile a list of all the pages that link to the moved pages and fix them from home tonight.
In connection with this, we should probably rename Mission location to Mission outpost for the same reason - "location" is not specific enough, it could refer to either the outpost or the zone. —Dr Ishmael Diablo the chicken.gif 16:24, 27 January 2011 (UTC)

Fatal Error

I received this error, " Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 22136 bytes) in /home/guildwiki/public_html/includes/media/Bitmap.php on line 213 " when I tried to view the category of Guild wars screen capture license... I was actually trying to find icons for like the Kurzicks, etc. Ariyen 03:37, 21 January 2011 (UTC)

Canthan New Year

I strongly suggest imediately copying the background (and perhaps more) from de:, might as well make the most out of the fact that we share the same open content license. --◄mendel► 21:38, 3 February 2011 (UTC)


We now have Gadgets enabled on the wiki. These are similar to Widgets, except that instead of providing parser extensions to use in specific locations, gadgets have a global and persistent effect and are enabled on a per-user basis.

Currently, we have 3 gadgets installed:

  • GuildWarsWiki Switch: Adds a page-top tab providing a link to the article of the same name on Guild Wars Wiki.
  • RC Hide User: A small utility that lets you temporarily hide all edits by a specific user on Special:RecentChanges.
  • UTCLiveClock: A clock in the personal toolbar that shows the current time in UTC and acts as a purge link for the current page. Useful for knowing exactly when the next finale event is going to start.

To enable them, go to the "Gadgets" tab in your preferences.

Feel free to suggest ideas for additional gadgets. For starters, you can check out the gadgets currently in use on Wikipedia and Wikimedia Commons.

Admins: The "master" page for gadgets is MediaWiki:Gadgets-definition. Special:Gadgets provides convenient links to all gadget component pages.

Dr Ishmael Diablo the chicken.gif 01:56, 9 February 2011 (UTC)

Cool. Thank you.  — Tennessee Ernie Ford (TEF) 02:34, 9 February 2011 (UTC)
Great! --◄mendel► 11:46, 9 February 2011 (UTC)
Could it be at all possible to move the clock to the left side of the personal links as poke's done? On the right it's kinda...out of the way. :| — Scythe 22:27, 10 Feb 2011 (UTC)
It's possible, but it would require quite a bit of tweaking. Get more people to comment here and ask for it, then I might do it. :P —Dr Ishmael Diablo the chicken.gif 23:21, 10 February 2011 (UTC)
comment asking for it More People
Smooth scythe, real smooth :P --TalkpageEl_Nazgir 00:06, 11 February 2011 (UTC)
That's not nice. Pretending to be the "voice" of more people? I like the Gadgets, but what kind of tweaking would it need? Just curious. Ariyen 00:07, 11 February 2011 (UTC)
Actually, I quite like the larger font and the rightside :)–User Balistic Pve sig.pngalistic 03:27, 11 February 2011 (UTC)

Templates and pages

I don't feel the need of having this <includeonly> (category) </includeonly> on a template. Most templates, that could use that. Don't. I felt the obligation to go with the most templates and have the rest of them be the same/similar. And add the needed categories to those pages. I don't think there'd be more. The only things I feel would be more would be the additional content to go after War In Kryta. I don't see that much being added other wise and so I don't see the "issue" that's been raised on my talk page. I am bringing this here to ask the community. Would you prefer templates to add in all categories? (I would rather see ItemInfo do that - instead of a navigation template - so one could (like me wanting to use the sweets nav) use them on their user page, etc.) or them be added separately so that the pages could have all the correct categories needed. Ariyen 19:24, 13 February 2011 (UTC)

I don't think that there's anything that we need to urgently change about how we use templates and info boxes for categorization. If there's an issue with a specific auto-cat method, let's bring it up for the specific situation. For example, if the info box has been updated to allow categorization after the creation/addition of a temple, it might make sense to move cats into the info box and out of the template.
  • "Should categories be automatically tagged to articles via the use of templates and/or info boxes?" Yes, absolutely.
    • "When should we tag via info boxes? When via templates? " That depends on the situation. The answer is more a matter of art than of science. This should be handled on a case-by-case situation.
  • "Should categories be manually tagged by users?" No, not unless absolutely necessary; it's better to adjust templates and info boxes whenever possible.
    • "Doesn't this make editing of categorization less user friendly?" yes, but that is a small price to pay to protect the wiki's overall categorization. It's easy for someone unfamiliar with the category tree to make well-intentioned mistakes; heck, it's easy for those familiar to make mistakes. Protecting categories is no different from protecting important articles.
 — Tennessee Ernie Ford (TEF) 19:39, 13 February 2011 (UTC)
So if some Navs are wanted to be on user pages. They'd have to put up with the "Auto tagging" of cat. on that user page? Ariyen 19:42, 13 February 2011 (UTC)
No, then I think we should create different navs for user pages. Those navs were created for main space, not for user space. (I suspect that there is a sneaky way to code them so that they get auto-tagged in Main, but not in User, but I have no idea how to do that.)
If that's the only concern, it's far easier to create a second template (even one that transcludes from the current one); it's far harder to change dozens and dozens of articles to make the square template fit into the round hole.  — Tennessee Ernie Ford (TEF) 19:49, 13 February 2011 (UTC)
Creating additional or different navs.. I disagree with, not everyone would know how to do that. I also don't think the navs could be messed up and if a potential hazard - can be blocked to be edited by admins only and suggestions be on talk pages.
Now, if there's a way to create a code to where the cat is only tagged to teh actual pages, then I'd be okay with it and not raise this "concern" and I'd be willing to put categories into the navs and remove them from the pages. Opposite of what I have done. Ariyen 19:56, 13 February 2011 (UTC)

(Reset indent) To clarify, the question is, given the choice (i.e. an appropriate navbox or infobox actually being on an article), should a category be assigned via

  1. the infobox
  2. the navbox
  3. wikicode on the page?

I think it would be good to arrive at an "official" order of preference and clearly state it.

As a secondary question, should infoboxes/navboxes be made to be includable on user pages, i.e. the category be protected by a namespace condition so only mainspace or GuildWiki: pages get categorized?

it's far harder to change dozens and dozens of articles to make the square template fit into the round hole -- easy bot work, methinks, especially if the category already exists.

Tip: cleaning up Special:WantedCategories goes a long way towards finding mistakes. --◄mendel► 20:53, 13 February 2011 (UTC)

I agree, been trying to clean up the wanted categories for pages first... Ariyen 21:00, 13 February 2011 (UTC)
Ok, first, wtf ariyen? Second, what's the big deal if both the nav box and the infobox both set the same cat as long as they don't conflict? Third, nav box categories tend to be less likely to be red-linked since they are usually hard coded. Fourth, all this is due to wanting to use mainspace templates in userspace? That's easily duplicated (can be changed from main to user version easily) or the cats could be namespace aware. Fifth, ariyen, why didn't you come out and ask for a potential solution before coming up with your own, knowing it would affect terrible, terrible damage many, many pages? --JonTheMon 23:09, 13 February 2011 (UTC)
I would like to remind you that personal talkpages are reserved for personal comments. This is about categories, not about Ariyen.
Second, the question is not infobox vs. navbox, but rather wikicode vs. template, with "which template?" being secondary. Third, infobox categories are more likely to be redlinked because editors don't usually think to check the bottom of the page if the infobox looks ok. Forth, duplicated navboxes mean duplicated effort as they won't update with the main templates. Fifth, see first. I doubt it was intentional,though. --◄mendel► 23:35, 13 February 2011 (UTC)
Assumptions. Let me detail again what happened, before people were like "all that was fine" and I clearly saw it wasn't. It could have been Anyone doing this as well, but I will detail from beginning. I was working on the wanted categories in pages and fixed what I could. Then I moved on from there and found a template page that were auto tagging some pages, but not all. I realized the pages that had the include only category did good, but some of these pages also had the caegories on them. I Looked through to find that most of the templates did not have include only and the category, but that most of the pages already had the category. It was a mixture of styling and editing and not a clear way of fixing. So, I took what was done the "Most" way and changed the rest of them to that. I did not think this would be a problem, considering it was the way that the most pages and templates were already done this way. Had I know that people would have rather had the template tag the pages - that'd been nice, but most of these templates like the Summoning template - did not have the include only.
Also, you don't want redundancy, because of the what links here in the category and page. Have it on both the page and template as very few were done this way... Can cause an issue.
I'll give yet another example and I'm quoting this from the stance talk of where I left it. "I understand that, but I wasn't the one who added in category game mechanics, and I don't think it should have ever been there when the template was tagged with the category skill types. You will come across issues like this, if you don't categorize pages yourself and expect a template to do it. You will have people adding in categories when they go to edit, not seeing any... Cause the template will only add them on the page and if people miss that, they will add them as well. It could either be categorized wrong or a redundant category as I have seen with a few. It's yet another reason that I feel went way over people's heads and why it seems some want to trust templates. I don't mind things categorizing, but when you deal with the public - always expect and "have it" to where people won't do such. I've seen this issue not only on wikia, but wikipedia, media wiki, shoutwiki, wizardpro (their wiki really is far one of the worse), and any other type wiki. I know for some - they solved it by inserting the categories individually and keep up with things better... Sure it's easier to let the templates and or boxes do it, but it's a lazy way and if a lot of edits... It can be missed if someone edits adding in a category. Just look at all the things that one can do in a short time editing a lot of pages adding in what's needed. Imagine if that was trippled and add in a page or two that gets missed with either a wrong category added or a duplicate category added."
I'm for info boxes of tagging categories more than I am template. With some of the new things like concepts - I think concepts should be what takes the place of category tagging and note that. So people, including me, wouldn't even bother with category tagging. If we feel something needs a change - we can notify an admin and or make a consensus and an admin can do the changes or get a bot to do the changes. Ariyen 00:14, 14 February 2011 (UTC)
Wow Jon, I've seen some real douchery aimed at Ari, but you just set the bar higher. — Scythe 0:25, 14 Feb 2011 (UTC)
You're right, Ariyen, it could have been anyone, and I (and Ernie, I'm fairly certain) would have responded the same way: don't go messing about with long-established wiki functionality until you understand why it was built that way.
Firstly, most novice editors don't care about categories at all; on the other hand, they do tend to copy things from existing articles when creating new ones. Thus, if they copy an info/navbox, and that template has a transcluded category in it, then the new article will automatically be placed in that category, and the editor doesn't have to worry about it. Requiring all categories to be added manually would introduce many situations where someone else will have to fix the page: a) the editor completely forgets to add the category(ies); b) the editor adds the wrong category; c) the editor typos the category name; etc. Frankly, auto-categorizing pages from info/navboxes saves people like me a lot of work.
Secondly, navboxes were intended for use only on the pages that are listed in the navbox, to allow readers to easily move between related articles. They are somewhat redundant with the category system in that each navbox usually includes all the pages in a certain category (but having the navbox directly on the page saves readers from having to click to get to the category, and navboxes are usually organized with more detail), thus it makes sense to transclude that category from the navbox template, since all the pages that use it will need that category. Navboxes were never intended to be used in userspace. Yes, we could modify the category transclusion to be ignored on non-mainspace pages, or even to be ignored when a certain parameter is passed in, but why should we do this for a single user? The purpose of this wiki is to document Guild Wars; user pages are secondary to that. (GWW's policy goes so far to say that "User pages should avoid interfering with the main namespace" (the bullets under that are merely examples; I would consider the use of auto-categorizing templates to be another example).) We already have a userspace-specific version of the skill box template to avoid the auto-categorization issues; in my opinion, this would be the preferred path to follow for other auto-categorizing templates. —Dr Ishmael Diablo the chicken.gif 14:53, 14 February 2011 (UTC)
Ok, I should probably clarify and expand on some of my points. First, that was off-topic of me and non-productive. Second, I feel that templates (infoboxes and navboxes) are incredibly powerful ways to categorize pages, so I support their usage early and often. Third, my point was somewhat stated by Ishy (Navboxes typically correspond to a category), so I feel they have the simplest categorization, over both infoboxes and wikicode. Fourth, I gave both the idea of separate templates and namespace-aware categorization, but neither are that hard, nor ugly. Yes, you have duplicate templates, but generally the people who make the duplicate templates are aware of how to do it right and/or update the user version. And making it namespace-aware is kinda self-explanatory. --JonTheMon 21:50, 14 February 2011 (UTC)

Call for action: help keep current the Item of the Week farming guide

I am posting this because I would like to encourage more people to contribute to GWiki's farming guide for Nick Traveler and thus help to keep it current, perhaps within 24-48 hours of Nick's move.


A GWW contributor wants to delete from GWW:Nicholas the Traveler the link to Guide to Item of Week Farming. His argument is that it's not updated promptly every week. Although I think the GWW contributor is being hasty in expecting that the link be updated within 48 hours of discovering Nick's new location, I don't think it's unreasonable to expect to see current information after following the links from one of the official wiki's most visited pages.

I also believe that our guide serves more people if it is linked from GWW. And I believe it's the best gateway drug to lead people to Guild Wiki, i.e. it's among our most valuable and visible articles; it helps to differentiate GWiki from GWW.

Please, therefore, help keep it up-to-date. Thank you.  — Tennessee Ernie Ford (TEF) 02:24, 16 February 2011 (UTC)

I don't mean to sound like a stick in the mud, but I think that person is pretty much disrespecting two communities. For one, I feel that if this person wants to delete the page from that site, because it's not "up-to-date" to suite them. Then, they need to learn that they can do something about it - come update the guide. Anyone can and it shouldn't be just on us to update it to suite someone else who would rather see it gone, because they can't "use it" if it's not updated. Just because something isn't up to speed, does not mean that it's "dead" or not worth keeping. After all, Nicholas is suppose to recycle again, right? If so, which is not a doubt in my mind of it. Then the person is removing a link that is helpful even for future references and has no ground really to remove it. If I wasn't "banned", I'd basically told the person to go update the page, instead of removing it. After all, I have no doubts that they would be reverted by other users - who have updated this or who do use it when it's updated by members. For this week, I will update it. I can't speak for every week of it being updated, because not everything works the same. Ariyen 03:37, 16 February 2011 (UTC)
I second this, although I don't play the game anymore, so I can't really update it :| — Scythe 4:36, 16 Feb 2011 (UTC)
Well, as I said, I think he's being hasty. But I'd rather we avoid giving anyone any reason to question why the link is there.  — Tennessee Ernie Ford (TEF) 04:49, 16 February 2011 (UTC)
Well, to be honest... He's not too bring to question why it's there in the first place if he can't place two obvious facts together. That by December, Nick is going to recycle and the link would have no reason to be removed. If removed, it'd be added back by then, so his "questioning" now would be only for disruption and meaningless. 07:04, 16 February 2011 (UTC)
Couldn't we clear the guide every Monday morning, add the location info once it's up, and have an edit link asking people to share farming tips? That way, somebody who comes over when the page is not updated gets invited to contribute. --◄mendel► 13:59, 16 February 2011 (UTC)
Seems like a fine idea. Btw, I also don't play the game anymore so I can't update.--TalkpageEl_Nazgir 16:31, 16 February 2011 (UTC)

(Reset indent) Probably, we can do something similar to what has been done for Nick: use a template (linked to Nick's research table) that shows a request for tips if there's no new guide and the actual tips if there is. (Would require changing how we store the guides from a single page into subpages.) (But oh! Someone suggested we move the guides to subpages a while ago and someone else did the heavy lifting.) Something like:

  • check for [article=trophy]/Farming
  • if it exists, point to it and redirect IotW Farming to that page for the week.
  • if not, request tips to be published at that location
    • ideally, create that page using a modernized version of the established templates

I don't have the coding skills to make that happen, so I can only criticize help whichever wikifu-practitioner who cares to volunteer. (And, of course, there's probably an easier way of setting it up than I have suggested. And we need to take into account mats. And perhaps the farming notes should get moved to a section on the actual article. Sigh. More buts than a chicken farm.)

For those who don't visit Nick (or, heck, those who have stopped playing), if you would like to help, you can do so by copyediting new tips and/or helping to standardize the old ones. One of the things I really like about the page is it's also the most prominent place where new (or infrequent) contributors can make a big difference. That means lots of new ideas, but also odd formatting or reiterating details are already covered in depth elsewhere.  — Tennessee Ernie Ford (TEF) 18:16, 16 February 2011 (UTC)

Conditional redirects don't work - #REDIRECT must be the first thing in the wiki-text in order for it to be treated as a redirect. (Unless you weren't talking about actual wiki redirects when you mentioned that?) However, conditional page transclusion (for <item>/Farming format, via standard template syntax) or section transclusion (for <item>#Farming format, retrieving item name from SMW and passing it to DPL) does work, so the guide could dynamically transclude the farming details for that week's item. —Dr Ishmael Diablo the chicken.gif 20:09, 16 February 2011 (UTC)
I probably (as usual) offered too many details, giving the impression that I thought I knew what I was talking about. The main idea is: if we have something worth reading, that's what folks see. If we don't, they see an invitation to start the notes. The next bit is that I hope we can automate enough of it so that, when the cycle loops around, we don't have to do anything; the guide keeps pointing (or transcluding or dpl-ing or SWC-ing or...) the current info. And, as a small point, let's also make it easy for people to follow the style convention (even if we have to craft a new one to do so).  — Tennessee Ernie Ford (TEF) 08:11, 17 February 2011 (UTC)
What I thought TEF meant was using a template or something which showed one thing if the criteria were fulfilled and another if they weren't (in this case, the existance of a correct weekly farm article). While my coding skilzz aren't good enough yet to do it myself I bet you could it it's possible ish. Naz here, at school, cbb to long in. --
Did you click the link I put up there? That's what it does - if the item's page has a "Farming" section, then it transcludes it (now, also the "What drops it" section); if not, it displays a message. —Dr Ishmael Diablo the chicken.gif 14:40, 17 February 2011 (UTC)
I apologise, I seem to have totally missed your post there O.o --TalkpageEl_Nazgir 15:06, 17 February 2011 (UTC)
Ditto. I didn't see the blue link at all. (Doc Ish's suBtlety was lost to this contributor, I am sorry to say.) Nice job.  — Tennessee Ernie Ford (TEF) 04:58, 18 February 2011 (UTC)

Rapid response, part 2

The impressive human bots of GWiki went into impressively quick action (perhaps faster than the official wiki's minions) to update oodles of articles based on today's rebalancing update. Nice work by Doc Ish, Gig, Yamagawa, and anyone else's whose name I am too blind to see in the list of recent changes.  — Tennessee Ernie Ford (TEF) 04:56, 18 February 2011 (UTC)

Would now be a good time to clear Category:Pages that need updating? --◄mendel► 07:24, 18 February 2011 (UTC)

Getting worse? (Curse servers)

→ Moved to GuildWiki:Bug reports#Getting worse? (Curse servers)

Seeking Fansite status (2)

(moved TEF's post from above, --◄mendel► 18:40, 21 February 2011 (UTC))

Bad news. Although we are (afaik) the only community site to consistently and conveniently post detailed guides (suitable for beginners and veterans) to farm Nick's weekly requests, the official community news is pointing to a single user's youtube guide, purportedly doing the same. I haven't reviewed it (since I generally think videos are overkill for farming), but obviously whoever is deciding what to feature isn't paying attention to our site.  — Tennessee Ernie Ford (TEF) 18:26, 21 February 2011 (UTC)

Adapt and embrace? With the youtube widget, we can easily place these video guides on our page as well. --◄mendel► 18:40, 21 February 2011 (UTC)
(a) The reason I posted here was to point out that whoever is deciding what constitutes news doesn't look here. That's a bad thing. (b) I posted in seeking fansite status because this is directly related to that idea (and not a separate new one). It has nothing to do with adapting or embracing.
(c) If we want to adapt or embrace, we can just point the Nick page directly to the direct you tube link (or we can get fancy), but (d) I believe that there are probably only 2-3 Nick farms in which a video guide is as useful as a text-based one.  — Tennessee Ernie Ford (TEF) 01:17, 22 February 2011 (UTC)
I realized what your motive was; the reason my reply takes another direction is that it concerns something we can actually do something about, and if ArenaNet wants to reward fansites that do have video guides, maybe it'd help if we had them too.
Some people obviously find these video guides useful; to have them along the text guide and map on a wiki page makes them even more useful, even if not everyone who uses the page is going to play the video; being on the wiki makes the video easier to find (also via search engines). NOte also that linking to a video is not half as useful as embedding it. We might also arrange a mutual link exchange with the person who does these videos, thus driving traffic here. But I've already argued for guide videos once before, and got berated over my involvement in that matter, so I'm not planning to invest further energy in this; I'll just chalk it down to "opportunity lost" if we keep not having them. --◄mendel► 10:30, 24 February 2011 (UTC)
I certainly would not like to use this person's videos without his consent, whether we link to them or embed them. If we get consent (and a mutual exchange would be even better (best option would be convincing the dude to come here!)), then I'm all for it. Felix Omni Signature.png 15:59, 24 February 2011 (UTC)

Skill QRs and DPL Powa

So, given the recent changes to Dervish skills, particularly the attribute changes, I think it might be a good plan to automate our skill quick references. Currently, they are static wiki code that calls templates. I think that we could convert it to DPL and save ourselves work in the future and be faster in getting up-do-date.

The downsides are: protting pages and server load. The first is less severe than it seems, since it would be limited to attribute and profession skill QRs. The load issue I would defer to Ishy's or mendel's judgement, but they are static lists most of the time. --JonTheMon 20:12, 21 February 2011 (UTC)

Include allowcachedresults = true in the DPL, and it will get stored in MW's standard parser cache, which has an expiration time of 24 hours (can be configured in LocalSettings, but has not been modified on GuildWiki). The load should be fairly low anyway, since these would only list the contents of a single category (no fancy unions or intersections or anything like that). —Dr Ishmael Diablo the chicken.gif 20:22, 21 February 2011 (UTC)
There's a recent dpl parameter (might be dpltime, it's in the last section of the manual overview) that tells you how much time the query took. --◄mendel► 22:55, 21 February 2011 (UTC)

image missing

I added two images, File:image missing.png and Image missing-16.png and now also File:image missing.svg, which scales better, when I thought about ways to cut Special:WantedFiles down to manageable size. The redlinked images on that list could be #REDIRECT'ed to these files (using the -16 for images used in line with text). Note that images that could or should be uploaded ought to remina redlinks; and that images wanted as a result of a misspelling had better have that misspelling corrected than be redirected. Profitable applications of this icon are for missing signature images, or for any images used on user pages that the user has failed to upload or that have been deleted for copyright reasons.

It may be useful to upload a larger version of the big image.

As a project, anyone can work on it if they choose a section of the WantedFiles that nobody is presently engaged upon. The special page is updated once daily, I think. If this project is completed, that page could serve as a guide to the screenshots that the wiki still needs to be provided with, and possible errors with image names and the like; it can't be that now because it is too huge and too cluttered with images that aren't really wanted. --◄mendel► 22:04, 23 February 2011 (UTC) & 15:07, 25 February 2011 (UTC)

It might be easier the other way around: have a bot manually redirect any pages older than e.g. 6 months to e.g. file:image missing.png; as we come across articles with truly missing articles, we can fix the redirects. As Mendel notes, the wanted files is huge. I took a glance at the first 250 and I couldn't begin to tell you which, if any, deserve real images are not.
If that suggestion is too draconian, then perhaps a bot (or other software) could determine which of the subset of the long list fits a set of pre-emptive criteria, perhaps
  • only link is to user space (user, user talk, user contribs)
  • image is not set to appear in primary spaces, e.g. main, GuildWiki
  • only link is from a page that has not been touched in x months, x>6
The idea is that we reset the wiki so that wanted files becomes a manageable size for cleaning up/maintaining and hope that, over time, we catch (and fix) the inappropriate redirects. (And, if we don't, arguably, the images aren't wanted all that badly.)  — Tennessee Ernie Ford (TEF) 02:13, 24 February 2011 (UTC)
Well, AWB can't do it, but basically this could be automated:
  1. For each file on Special:WantedFiles , fetch the pages that link to it or use it (Special:WhatLinksHere)
  2. If at least one of these pages is in mainspace, GuildWiki: or Template: , do nothing
  3. Otherwise, redirect the file to the "image missing" icon.
The question is, redirect to where? Some images are used inline and shouldn't be larger than 20px, others are displayed as thumbnails with captions and should have some size.
I'm not afraid of "huge"; fixing 20 files per day, the number is going to come down eventually. ;-P --◄mendel► 08:06, 24 February 2011 (UTC)
Today, the list has 2,021 entries. I think at top speed, it would take me at least a minute each to review, find reference pages (to determine context) and decide: is it meaningful/not, typo/not, needs repointing/not...and, if we really need a new image, tagging it somehow so that someone else doesn't have to re-review it?.
Is this really worth 34+ hours of labor? Since it would take over 3 months to cleanup the backlog by fixing only 20 files per day, wouldn't you rather automate as much of that as possible?
At worst, shouldn't we use automation to prune the list? How much do we really care if we're missing an image in an archive? If it's on a user's talk page? How many of these entries only link to one page vs 5+? Can we not assume if it's an image on a talk page that we can redirect it to the 20px inline missing-image (and sort it out later)?  — Tennessee Ernie Ford (TEF) 08:58, 24 February 2011 (UTC)
There are only around 250 wanted files with more than one link. I've gone through 11 single-link entries in a bit more than 20 minutes, and dealt with many more redlinked images since many pages I worked on had several redlinks on it, so it's actually less than a minute per image. The ways I dealt with them varied: sometimes I replaced the image name on the wiki page with image missing.png directly; sometimes I disabled the wikicode using <pre> or <nowiki> tags, or <!-- HTML comments --> or simply replaced the link with italics; when the image was linked via a template that auto-generated the name, I used a redirect. (See my contribs if you want more detail.) Of course, no automation can make these kind of editorial decisions.
I also found out that the special page does not seem to be cached, as the redlinked images I dealt with are gone from it now (or at least they're not in the same place as before). --◄mendel► 10:05, 24 February 2011 (UTC)
The "reporting" special pages like that were cached on Wikia (probably by setting $wgMiserMode to true) and rebuilt by a maintenance script that ran every 24 hours. We haven't enabled that parameter on Curse, so all those special pages will (should) update automatically. —Dr Ishmael Diablo the chicken.gif 14:10, 24 February 2011 (UTC)
I just took care of a number of skill icon-related redlinks, and the list is down to 1,891. —Dr Ishmael Diablo the chicken.gif 17:37, 24 February 2011 (UTC)
Down to 1721. There are quite a few missing armor images (example: File:Armor R ShingJea Male Undye Full Front.jpg), have they been renamed at some time in the past? Most of them only have one link, so I'd like to put the new versions of these images on the pages that have them. Is there a discussion someplace that would educate me to the change that occurred, or can somebody else deal with those? --◄mendel► 14:52, 25 February 2011 (UTC)
That was one of the first projects I did, standardizing the file names for armor gallery images. This was long before MW had the capability to move files, so I had to re-upload to the new name and delete the old one. (I seem to remember someone else (Entropy?) told me to go ahead and delete the old one completely instead of making it a redirect.) Just update them to the standardized file names — the example you gave would be File:Ranger Shing Jea Armor M gray front.jpg. —Dr Ishmael Diablo the chicken.gif 15:16, 25 February 2011 (UTC)
Fixed some galleries and whatnot, down to 1580. The standardized armor file names are great! --◄mendel► 23:49, 25 February 2011 (UTC)

File:image missing.svg scales better than the .png (i.e. to any size) and should be used for anything but unscaled signature images (use the -16 for those). --◄mendel► 15:07, 25 February 2011 (UTC)

Down to 1500. I'm using File:no image available.svg for character images created by templates if they allow a parameter because it looks less harsh, and it's less of the user's fault for this image not existing, compared to those who placed an image link themselves and then not uploaded the picture or not responded to the copyrigth warning. In quite a few cases I was able to replace the wanted image with one we actually have. --◄mendel► 12:23, 26 February 2011 (UTC)
1400 :) --◄mendel► 11:50, 27 February 2011 (UTC)
Broke 1300, with 180 multiples left. --◄mendel► 14:58, 27 February 2011 (UTC)
Less than 1200, with less than 150 multiples now. I figured out that I can keep the original filename if I simply insert the "no missing image.svg|" before it (note the pipe |). Thus, the name of the nonexistent file becomes the image caption; if there's a caption already, the old filename is not shown at all. --◄mendel► 02:05, 1 March 2011 (UTC)
Below 1100, with 125 multiples. :) --◄mendel► 15:23, 1 March 2011 (UTC)
Past 1000. --◄mendel► 22:11, 1 March 2011 (UTC)

The Template:LocationInfo rollout has added over 150 WantedFiles; most outposts never needed a map, so now they redlink on that. This constitutes ~15% of all Wanted Files; in other words, 1 in 7 WantedFiles currently come down to this issue. I worked hard for the numbers to go down instead of up, and I am taking a break from this task until this issue is fixed. I'm already more than halfway done, feel free to start on the other half in the meantime. --◄mendel► 00:03, 6 March 2011 (UTC)

Page load times should be are dramatically improved.

Since the announcement went up, page load times have dramatically improved: I haven't seen an error message on read/preview/save and the very slow response times I've seen have been consistent with something else slowing kb/s on my end. Thank you to who ever on our side worked with whomever on Curse-side to get this addressed.  — Tennessee Ernie Ford (TEF) 16:13, 2 March 2011 (UTC)

Indeed. Domo arigato gozaimasu! --TalkpageEl_Nazgir 16:26, 2 March 2011 (UTC)
+1 I've done a lot of editing, and the wiki feels very responsive now. Having non-cached special pages is a definite boon! --◄mendel► 03:20, 3 March 2011 (UTC)
I'm glad to hear it. Now I shall finally apply for fansite review. Felix Omni Signature.png 04:07, 3 March 2011 (UTC)

April showers

Is it me, or are the pagevieuws slower to load? Last night, around 00.00 GMT, I even had some error screens. Arnout aka The Emperors Angel 09:50, 4 April 2011 (UTC)

I haven't had any trouble; even WikEd widget loads nearly instantly.  — Tennessee Ernie Ford (TEF) 16:24, 4 April 2011 (UTC)
The WikEd code is hosted on Wikipedia's servers, so that wouldn't be a good benchmark for GuildWiki performance. Also, it's a gadget, not a widget. :P —Dr Ishmael Diablo the chicken.gif 16:51, 4 April 2011 (UTC)
now everything is borked. The things usually on the top of the page (userpage, contributions, clock), and the page tools (edit, talk) are now on the side bar. And the searchbar is now below the rest of the page. WTF? Arnout aka The Emperors Angel 17:11, 4 April 2011 (UTC)
NVM it's back to normal. Arnout aka The Emperors Angel 17:13, 4 April 2011 (UTC)
That can happen if your browser doesn't load the CSS completely, since those elements are generated after everything else in the raw HTML, but receive absolute positioning from their CSS properties. —Dr Ishmael Diablo the chicken.gif 17:37, 4 April 2011 (UTC)
I was having some issues last night of loading and saving some of my work in the sandbox. Ariyen 22:27, 4 April 2011 (UTC)

Geographic location template

What does anyone think of borrowing this template for use in our location articles? Currently, each campaign seems to have its own standards when it comes to listing exits/neighbors, so this would be a very easy way to standardize that. (Personally I kinda like the way a lot of Factions explorables do it, using map icons to indicate what type of location each neighbor is; example.) It could also eliminate the need to list exits in the infobox, thereby reducing its size. —Dr Ishmael Diablo the chicken.gif 21:20, 5 March 2011 (UTC)

Standardization is good. I find it convenient to see the neighbors in the infobox, but it is redundant with "exits." Can you mock up a page with what you have in mind?
I'd also like to see us do something simpler with rez shrines (they are part of geographic orientation as well as important services). I've mocked up something in GWW, but I like the geo-locate template better.  — Tennessee Ernie Ford (TEF) 22:56, 5 March 2011 (UTC)
You propose to remove "neighbours" from the infobox and add it to the article instead? So that previously, we had location infoboxes with neighbors in them, and now we get infoboxes with services? I'm sorry, "neighbors" (along with "parent" and the type) is the most useful info on that box (why not put the map number at the bottom? one of the best spots in any list, and it's currentyl wasted on whatever service comes last); I know of no infobox that lists "exits"; and a map does more to show the positions of exists and the locations of the areas they lead to (areas may be located in a different direction than the exit is facing, especially on outposts) than such a crude 8-directional overview can. --◄mendel► 00:09, 6 March 2011 (UTC)
Mendel, please re-read what I wrote. I did not propose to remove the list from the infobox, I merely said this template could replace that list, not that it had to do so. I'm fine with continuing the current duplication, but the in-article list is lacking standardization, and I am not fine with that. This template provides a simple way to enforce standardization, and at the same time de-clutter the list by eliminating the need to type out the direction.
Furthermore, I never wanted to add the services to the infobox; other people (including you, I thought?) convinced me it was a good idea.
I arranged the entries with the same philosophy as with ItemInfo: all single-valued properties first, then the multi-valued lists at the bottom (salvage entries for items, Neighbors/Services for locations), so that none of the single-values get hidden waaaaaay down below the lists. It's not "wasting" a position in the list or anything like that - with the reduced font size, the entire infobox is immediately visible on most articles (except for Towns with their giant list of services) even at lower resolutions (1024x768).
Finally, could you explain what you mean by: "areas may be located in a different direction than the exit is facing"? Are you just saying that, for example, a portal located on the east edge of an area may actually be "facing" north? Like from Cliffs of Dohjok to Champion's Dawn? We've never cared about the directionality of the portals themselves, I'm not sure why you thought that would change with this. —Dr Ishmael Diablo the chicken.gif 15:38, 6 March 2011 (UTC)
I used propose in the sense "To put forward for consideration, discussion, or adoption; suggest"; isn't that what you did?
The template provides space for eight directions, when a large number of zones have no more than two exits. This means we'd have a lot of "wasted space". Whether this is more than the current list format wastes would remain to be seen.
On Champion's Dawn, the exit to the Plains of Jarin is listed to be north when the zone lies actually northwest, and Cliffs of Dohjok are west with the outpost exit bearing southwest. For orientation inside the outpost, this is very useful; but if we have a spatial representation of how the zone relates to its neighbours (as the Wikipedia template attempts to do), people will assume that the spatial location indicates where the zone is, and not where the exit is (especially if they've been seeing the design on Wikipedia, where it does work that way); so if we were to keep listing exits in such a way, they'd better be labeled "Plains of Jarin exit" etc., or people will confuse the two meanings.
Now take Foible's Fair, which has an exit south to the zone it is embedded in. Oh, and Wizard's Folly lists Foible's Fair as being "near the center, slightly towards the north". I challenge you to come up with a standardized location scheme (with no way to type out the direction) that comes even close in usefulness to that description; unless of course you go with maps that contain a zone, its neighbors, with clearly marked boundaries and portals -- this would be a definitive improvement, but also a lot of work.
Cognitively, people notice the top and bottom entries in a list first, and they're easy to visually find if you're looking for it; therefore, these are the best positions for information you want people to notice. What we would be "wasting" is an opportunity to consciously place some interesting info in that favored spot, when we're just having whatever happens to be last of the services there. As you say, on most browsers that position should still be well above the fold.
I do not recall weighing in on the services discussion other than to say that using icons for the common services would be a good idea [1],[2]. We don't have them, so I can't have been that convincing. ;-P --◄mendel► 19:09, 6 March 2011 (UTC)
Okay fine, whatever. Mendel says it's a stupid idea, I'm giving up. —Dr Ishmael Diablo the chicken.gif 19:24, 6 March 2011 (UTC)
Eh? It's a good idea; we need something better than what we have.
I think there are different ideas brought out here, and they can be decided independently.
  1. Can we improve the way in which the info box presents exit information?
  2. Can we make use of Wikipedia's geo-locater template to improve how the data is presented in the body of the article?
  3. Should we only put the information in the info box? only in the body? both?
  4. Can we do something similar to improve the presentation of shrine locations and utility?
(1) Yes, I like exits, but I would like seeing something indicating approximate location, too. (2) Yes, I like how the geo-locater looks. (3) I don't have a strong opinion about whether we display the info twice, as long as it's easy to find. (4) Please, I find it hard to answer simple questions about the shrine (is the Kurz shrine always Kurz? to which outpost is it closest?)  — Tennessee Ernie Ford (TEF) 21:06, 6 March 2011 (UTC)
1) I don't know if we can easily improve on the list in the infobox, but that wasn't my original point. 2) This was my original purpose in posting here - the in-article lists are inconsistent and unwieldy, this template would organize and standardize them with only a very few oddballs (Foible's Fair, Harvest Temple, Olafstead, the Command Post exit into Jahai Bluffs). 3) Please forget I ever said anything about removing the list from the infobox. 4) Ernie brought this up, and I think it should be given a separate discussion so as to not confuse what's being discussed here. Short answer: Shrines at an outpost entrance are controlled by the faction that currently owns the outpost; shrines in the middle of an area are non-aligned.Dr Ishmael Diablo the chicken.gif 22:28, 6 March 2011 (UTC)
Let's focus then on the original idea: a more consistent presentation of exit information in the article. Yes, let's be consistent and yes, I think the wikipedia template works.
The shrine issue is directly connected: many of GWiki's explorables merge shrine details with exit info, e.g. Arkjok Ward. (Also, the outpost-control/shrine rule isn't obvious or well-understood (the only people who don't ask about it on 2x bonus weekends are faction farmers). We can make this easier for more people.)  — Tennessee Ernie Ford (TEF) 22:41, 6 March 2011 (UTC)
I agree that the shrines also need standardization, but I can't think of any easy way to combine that with the geo-location template, which is why I think it should be separate. —Dr Ishmael Diablo the chicken.gif 23:07, 6 March 2011 (UTC)
Oh, sorry: yes, shrines & exits separate. But I wonder whether we could use the same template as a starting point (i.e. geographically oriented, rather than organized by God, faction).  — Tennessee Ernie Ford (TEF) 00:56, 7 March 2011 (UTC)
Well, I'm a bit late to the hootenanny, but I'll chime in. I do think that having the list in the infobox would be good, since that's a quick reference. I do think that the template might have spacing issues for areas w/o many neighbors, but it is a nice presentation for though that do, though I think the max is 5. Shrines can be oddly placed, so I don't think that they'd take as well to such a template (map would be better in that case). --JonTheMon 13:47, 7 March 2011 (UTC)
I'd like to see a mock-up of what Ishmael is proposing, for both an area with several adjacent zones, and one with few, so I can get an idea of what it'd look like both ways. Jink 18:48, 7 March 2011 (UTC)
Here's a mockup for an explorable, and here's one for an outpost. Those use the WP setup of having percentage-width columns; we could change that to fixed-width if we preferred. I left out the compass rosettes because I felt they were extraneous (the WP discussion seems to indicate they were completely decorative anyway), and besides, it saves some width on the table. The arrow icons are hotlinked from WP, we would obviously upload our own copies if we implement this. —Dr Ishmael Diablo the chicken.gif 23:23, 8 March 2011 (UTC)
So, the one for Maatu Keep seems ok, a little sparse. The one for Pongmei definitely feels out of place simply due to the fact that there is a map right next to it. --JonTheMon 20:10, 9 March 2011 (UTC)
Yeah, it does feel a little redundant when there's a map right next to it. Of course, having the list in the infobox and in the main article could also be seen as redundant. Otherwise, I rather like it. I'd like to see other users weigh in with their opinions, of course. Jink 23:44, 9 March 2011 (UTC)
I had started typing a reply here to a few of the above points, but I just don't care anymore. Mendel took my idea and completely derailed it. I'll just move on to something else. —Dr Ishmael Diablo the chicken.gif 16:05, 8 March 2011 (UTC)
I apologize, I did not mean to derail your initiative with my "Exits" section below. Having an overview on User:Mendel/Exits‎ was intended to aid discussion, not abort it. It was to provide some information to help design a good template (e.g. by making all "special cases" readily visible), and to provide a basis to compare the mockups to. Your concern is that "the in-article list is lacking standardization", so I explored what would happen if we standardized it based on our current S&F (note that haven't done any sort of complete job of it just yet). You also suggested "using map icons to indicate what type of location each neighbor is", so I took care to comment on that as well (definitely a good idea). I'm looking forward to seeing some mockups. --◄mendel► 17:08, 8 March 2011 (UTC)


I made some DPL to illustrate the inconsistencies, the most prominent one being that the section is most often named "Exits", but sometimes also "Exits / Neighbor Areas" with varying spellings. See User:Mendel/Exits (this does not update automatically). --◄mendel► 22:55, 7 March 2011 (UTC)

I've edited some locations to comply more fully with GuildWiki:Style and formatting/Explorable areas (the S&F for Towns is similar), mainly to get them to show up on my DPL list (and also for consistency), and here are some observations.
  1. Calling the section "Exits" is good, because not all of them are portals.
  2. Some exits are reached by talking to people, and have more comments than simply a compass direction.
  3. The style guide standard of placing the direction after the zone name (in parentheses) makes sense, because it provides a place for comments.
  4. It's faster to retype a compass direction than to copy & paste it.
  5. "Points of Interest" should long ago have been updated to "Landmarks". I am undecided about this being a separate section from "Exits".
  6. Having icons for outposts (and maybe dungeons) is a good thing, even though they're not standard yet.
  7. Icons look best when placed first, because they line up then, and preferably they should replace bullets instead of having both.
  8. The third level headers for the zone type are very bold and "outshine" the level 2 "Exits" header. To remedy this, either the header style would need to be changed, or the exit list could do without headers - a definite possibility if outposts and dungeons were always indicated by icons.
  9. Listing outposts ahead of explorables seems sensible.
  10. To have the subheaders on zones that have either explorable exits or outposts, but not both, seems superfluous.
--◄mendel► 08:17, 8 March 2011 (UTC)
  • Third level headers: yes, should not outshine second level headers. Since this has nothing to do with the current topic, could you (Mendel) start an appropriate discussion (or simply fix it)?
  • Landmarks are not exits; they should have their own section. Alternatively, the section could be called Points of interest, which would include: exits, shrines, landmarks, ...
  • Icons instead of bullets sounds sensible and consistent with the evolution of the wiki since inception.
  • I think the point of the geo-locator is that it allows to have both exit (direction) and direction (exit), each of which answers a different question. Sometimes I want to know where I can go; sometimes, I want to know; sometimes I want to know which way to go.
    • If we do use icons instead of bullets and if we label as exit (direction), I don't see any point to separating outposts from explorables. Often, the list will be small and the division complicates the presentation. (For areas with 8+ exits, I could be persuaded that a divided list might be easier to read.)
 — Tennessee Ernie Ford (TEF) 16:52, 8 March 2011 (UTC)
Yes, I meant one section that would have exits and landmarks as subsections. Not an important issue, but if we went to a very map-like representation (e.g. a map of the zone, with areas outside tinted and labelled, and landmarks shown with icons, labeled, and maybe linked via an imagemap), it would make a lot of sense to have these geographical features united.
Going by a quick scan of my list, there seem to be two areas with 7 exits, two with 6, and the others have 5 or less exits. --◄mendel► 17:20, 8 March 2011 (UTC)

New style suggestion for headers

User:Mendel has proposed that we update our current headers in our style sheets to something like this. I support this change (although I suspect that folks will offer suggestions for tweaking the style before it is implemented.)  — Tennessee Ernie Ford (TEF) 21:30, 8 March 2011 (UTC)

I agree with the changes to the headers. :-) Ariyen 23:48, 8 March 2011 (UTC)
This suggestion gets El_Nazgir's official Baby Seal of approval. --TalkpageEl_Nazgir 11:36, 9 March 2011 (UTC)
Tested this out on a few different pages using Firebug. My main concern is that I don't like the italics on 4 and 6. For one, bold+italics tends to distract my eyes very easily (much more so than either bold or italics alone), but it also makes those levels "outshine" the levels above them:
  • 3 now has nothing except size to distinguish it, while 4 is a bit smaller but is both bold and italicized.
  • 6 is imperceptibly smaller than 5 (100% vs 105%), both are bold, but 6 is italicized.
Non-bold 3 also just looks weird... While it does does solve the problem of 3 outshining 2 (sort of; I thought 2 was distinguished enough by having the bottom border), I guess I feel that headers need something to set them apart from text besides simply being larger.
Maybe I'm just too comfortable with the default styles, I don't know. I won't fight against consensus, though, since I can set what I want in my personal CSS anyway. —Dr Ishmael Diablo the chicken.gif 21:10, 9 March 2011 (UTC)
4 is more noticeable than 3 imo, and Ish's right about the bold+italics.--TalkpageEl_Nazgir 22:12, 9 March 2011 (UTC)
I can't think of a better way to distinguish the headers, unless we change the typeface. I don't see 4 being more noticeable then 3, maybe we're going to have to some browsershots to identify browser issues. --◄mendel► 22:22, 9 March 2011 (UTC)
I have always disliked the default styles. But perhaps it might make sense to use more than font size, weight, and italics to distinguish the levels. Microsoft Word (as an e.g.) uses more than one font, makes use of rules/underlines, and so on. (On the other hand, Wikipedia does not as far as I can see.)
  • Mendel: could you try coming up with 2-3 alternatives that strongly contrast with your original proposal? The idea is to make the abstract concrete for the rest of us (my eye isn't nearly as good as yours for this type of thing). I don't expect us to end up using one of the alternates; instead, I expect us to have a better discussion after seeing them.
  • Ish: I realize you've said that you are comfortable with the default (mebbe), but could you go crazy with 1-2 mock-ups of your own? (I believe we often end up using ideas from your just-an-example examples.)
Thanks.  — Tennessee Ernie Ford (TEF) 22:41, 9 March 2011 (UTC)
Initial impressions: yes, there needed to be a difference between the old 3 and 4. New 4 could probably do w/o bold, but it could go either way. I think new 6 should be smaller, since it's almost as prominent as 5. --JonTheMon 22:45, 9 March 2011 (UTC)
Personal preference here, but I'd rather the headers all be consistent in some fashion. All bold, all italic, all bold + italic, something along those lines. The second group just seems rather uneven and visually jarring as they jump between bold and italic. I'd pick the first group, myself.Jink 16:44, 10 March 2011 (UTC)
Concerning consistency: the default styles aren't perfectly consistent, as they have h1 and h2 as non-bold with an underline, while h3–h6 are bold with no underline. However, I'm simply pointing this out; I don't think that perfect consistency would be better, necessarily, because h1 and h2 have special purposes and thus should be slightly different. (h1 is the article title (its usage within articles is discouraged) and h2 marks the main sections of an article, which the underline helps to reinforce. Long articles would feel like one giant mess without those visual breaks.) —Dr Ishmael Diablo the chicken.gif 17:20, 10 March 2011 (UTC)
Addendum to my first comment above: I scanned our last DB dump (from right after we moved to Curse), and the h6 level is only used on user pages and on a couple how-to guides. So it probably isn't worthwhile to bother changing the h6 style; on the other hand, if we do change it, it won't have any notable effects. Either way, my comments on the h6 style don't matter as much anymore. —Dr Ishmael Diablo the chicken.gif 17:35, 10 March 2011 (UTC)
I realized after the fact that the first two are underlined, which makes sense. I wasn't even thinking about the horizontal bar, just the look of the font. Jink 17:22, 10 March 2011 (UTC)
What about something more like in the second area here? Ariyen 17:34, 10 March 2011 (UTC)

(Reset indent) OK, I set to comparing Wikipedia and GuildWiki, and the monobook style seems identical, yet looks different. I made screenshots, they're at the bottom of my mockup page now, with the "fat" H3 in evidence, but strangely enough, GuildWiki now looks like Wikipedia; I could not take that screenshot now. The Wikipedia design is fine and balanced and doesn't need changing, IMO. --◄mendel► 01:30, 11 March 2011 (UTC)

Bad Gateway / At Capacity

They're back. ∵Scythe∵ 19:27, 13 April 2011 (UTC)

fullwiki copyvio

Here: "This article uses material from the "Eye of the North (location)" article on the Guild Wars wiki at Wikia and is licensed under the Creative Commons Attribution-Share Alike License." The copy is dated February 2010, gives us credit, but the license is definitely wrong. That wiki project put all of Wikia's wikis in one big wiki, see e.g. campaign for an example of a page that has content from several wikis. --◄mendel► 10:40, 7 May 2011 (UTC)

I sent the following via

Legal issues

"All original content is licensed under a Creative Commons by-nc-sa license. All other information, art, skill images, are Copyright to their original creators, NCsoft, or ArenaNet." -- vs. the page footer, which states "This article uses material from the "GuildWiki:About" article on the Guild Wars wiki at Wikia and is licensed under the Creative Commons Attribution-Share Alike License."

Subject: noncommercial license

I am User:M.mendel on , and I am one of the "bureaucrats" entrusted with administrating that wiki.

Unlike most other Wikia wikis, GuildWiki was acquired by Wikia in 2008, and retained its original Creative Commons noncommercial license. All of the fullwiki pages that have GuildWiki content misstate this license as the lesser Creative Commons Attribution-Share Alike License that is lacking the noncommercial clause.

I also feel that you are not attributing the individual authors of the license as much as the license would require - a backlink to Wikia is not sufficient, because the content was contributed in an environment that attaches individual credit to each contribution (via the "history" tab or button), which your setup fails to do (unless I'm missing something).

I request that you remove the GuildWiki data from your archives; or, if you want to keep republishing our data, do attach the correct copyright license information to it.

I request that you give proper credit to the individual authors.

Thank you! Michael Mendelsohn

Maybe some of the bureaucrats here wish to unite their voices with mine? --◄mendel► 13:18, 7 May 2011 (UTC)

I'm still admin there right? Count me in. --TalkpageEl_Nazgir 15:53, 7 May 2011 (UTC)
I have three four thoughts:
  1. ^^ what Mendel sez.
  2. Even then, the attribution is ambiguous (the From Guild Wiki at the top should link to either Guild Wiki or the attribution note, at the bottom).
  3. They are confusing Guild Wiki with Guild Wars @Wikia.
  4. Complete segue: I like the style sheet that they use (if anyone agrees...and thinks we should do something similar...please don't respond to this, but let's start a new thread for it; if you disagree, please ignore).  — Tennessee Ernie Ford (TEF) 16:37, 7 May 2011 (UTC)
Yeah, the style's nice. Maybe we could offer it as an alternative skin? (But the it doesn't have to have any controls or stuff like that.)
I am bringing this up here because they made the copy in 2010; at the time, that wiki was GuildWiki, and it was run by this community. That's why I expected that the GuildWiki bureaucrats would like to speak out on this as well, representing the editors that actually created the content. --◄mendel► 17:30, 7 May 2011 (UTC)

Tab display when previewing vs editing

When I edit an article, my FF 3x and 4x tabs show, Editing [article]. However, when I'm previewing, they display, [article]. Back at Wikia (and at GWW and all other wikis), previewing either gets you Editing [article] or Previewing [article]].

Can this be easily fixed by our capable wiki admins? Or do our Cursed sponsors have to do something special? If the former, I encourage someone to to adjust accordingly. If it requires action by our hosts, then we should let them know it's not urgent (it's been this way since we got here; it should be fixed, but the time frame is probably unimportant).  — Tennessee Ernie Ford (TEF) 19:45, 14 May 2011 (UTC)

It might be a quirk/regression of MW 1.16.0, which is what we're running. GWW is still on 1.15.1, and Wikia is on 1.16.4 (WP is already on 1.17). In any case, I can't find any system message that would change that (the only 2 that seemed likely already had their default value as "Preview", so they obviously weren't the right ones). It's possible to change the window title with JS, though, if you'd like someone to write that up. —Dr Ishmael Diablo the chicken.gif 14:38, 15 May 2011 (UTC)
I'm 90% certain I've seen this since I joined both wikis over two years ago and 80% certain that wikipedia had this for even longer. (Seems like a strange thing to lose during an upgrade, but I've seen sillier stuff lost before.) I'll do some web sniffing to see if there's an answer that doesn't require adding a script that might become obsolete (or in the way) later.
Preview would be a good alternative when previewing, but we should resolve this at some point; it's easy to lose an edit by mistake if one goes by the tabs alone.  — Tennessee Ernie Ford (TEF) 17:21, 15 May 2011 (UTC)
For research purposes, I created a login for another MW1.16.0 site, Wowpedia. And, 'sho' 'nuff, on preview, the tab loses the editing [x] (I went to five 1.16.0 sites...and each required a login!) I've also done some searching on google, bugzilla, and mediawiki sites and cannot find any mention of this (as a feature or an issue). (Perhaps I don't know the correct terms to use for searching.)
So... I think we ought to do something about this, but perhaps it's not a big issue to anyone else. What do other people's think?  — Tennessee Ernie Ford (TEF) 17:56, 15 May 2011 (UTC)
Wowpedia is another site and presumably uses the same MediaWiki install, so that doesn't prove it is a MediaWiki issue - it might still be a problem with the local install. Other than trawling through the php sources, there's little hope of tracking this down in any way (I looked for the "previewing" message on and failed, so there goes the easy way); I'm not sure whether it's worth the effort if the next regular MediaWiki update that's installed might just fix this anyway. (Would you say it would be worth potentially 2+ hours digging through code to fix this?)
Knowing it also affects Wowpedia, it might be a godo idea to bring this to the attention of the technical staff, though. --◄mendel► 21:07, 15 May 2011 (UTC)
Official wiki just updated...and they are suffering the same feature. Sigh. Progress ain't cracked up to be what it used to be. (Or something like that.)
Is it worth time troubleshooting? No, b/c it looks like a mediawiki issue. I don't know if it's on their list of things to restore. (Added) Their buglist doesn't seem to include this particular error and I'm not inclined to create a login just to report it.  — Tennessee Ernie Ford (TEF) 18:57, 31 May 2011 (UTC)

Proxies - when *should* I use them

Can anyone point me to a good resource to learn about why individuals should (or should not) use proxies?

There are lots of things in the universe that remain a mystery to me including: proxies for individuals is one of 'em. I have firewalls and anti-virals setup and the PC connects to the internet via a router that connects to the modem. I also routinely disable scripts, lots of ad-related cookies, and remove flash-based cookies regularly. (Heck, on my test PC, I even disable flash and cookies for all but a few sites.)

My downstream DSL speeds are icky at certain times of the day, so I hate to do anything that taxes the bandwidth any more. On the other hand, I'm always game to consider a speed/security trade-off. I imagine my ISP knows everything about my browsing/gaming habits, so I assume that at most all I can do is hide the dynamic IP I use from other sites.

So, with all that background, are there good rules of thumb to consider when deciding whether to use a proxy or not? Do you use 'em? What plug-ins/tools should I consider? I've tried googling around and I can find lots of stuff that tells me how to proxy, but nothing that tells me what an individual should consider.

Thanks  — Tennessee Ernie Ford (TEF) 21:21, 14 May 2011 (UTC)

Proxies hide your ip, so if you are looking at stuff that you don't want to know your ip or don't want to be connected to, use one. Don't use one when editing a wiki, their ip sets tend to get banned because of vandals using them for the above reason. Also: Your ISP only knows a small subset of information about your browsing. It's a legal grey zone to whether or not they can monitor your traffic, and is currently under debate in Canada, where isps tried to charge based on what kind of information is being sent. Games are special because they send usually heavily encrypted packets that can't be understood by browsers, and most of the time connect to an unnamed ip address of a server, so game packets are mostly useless chatter that can't be accessed without a client or server program anyway, and WoW packets look exactly like GW packets, if your running a non web browser game, the packets are entirely incomprehensible to tracking software. Back on topic: Browsing things where you don't want people to know your ip, like 4chan, is when you use proxies, sometimes when connecting to an irc program if you can't manually mask your ip. Other then that, it's just base paranoia because viruses and malware just straight up ignore proxies anyway, so there not very useful for regular internet perusing.--Łô√ë Gigathrash sig G.jpgîğá†ħŕášħ 21:54, 14 May 2011 (UTC)
"What plug-ins/tools should I consider?" the TOR project is an excellent choice of proxy. It's open source has a client (means no annyoing 10000000000 character long URLs) that presumably connects via VPN to their network of servers, and if you really want, then have a graphical configuration tool.
TOR provides a good synopsis of why you should use proxies, and why they're around/their goals, here.
You are correct, the most proxies really do is hide your dynamic ip from the world. ∵Scythe∵ 23:37, 14 May 2011 (UTC)
See on how proxies help people in authoritarian regimes - there's a news item to go with that here. For personal security, proxies are not high on the list, though they make it possible to break your assumption that your ISP knows what you're doing - if you're using a proxy, all they know is precisely that (for all traffic that goes through it) (unless they use very sophisticated analysis methods).
Using a proxy adds very little overhead to your connection (much like SSL on an https request); it appears slower because your connection is routed through several different machines ("onion-routing") while being cryptographically treated at each step, and you share them with others. If your connection isn't that fast to begin with, you may not notice much degradation, though I definitely don't recommed using it for games. --◄mendel► 03:10, 15 May 2011 (UTC)
(extra indent) Super. That's all very helpful (especially the teaching me to fish link and the SSL comparison). I'm guessing I can add on to Firefox something that allows me to proxy surfing while gaming and updating my anti-virals will go through the system default. (No need to respond to that last assumption, unless it's horribly wrong.)  — Tennessee Ernie Ford (TEF) 17:24, 15 May 2011 (UTC)
You're welcome! Please do tell us what you finally did, and how it worked out for you, once you've done something. --◄mendel► 21:08, 15 May 2011 (UTC)


Looks like we're seeing the test edits of spambots (they often do edits like these before they go on to spam, as these edits confirm that they can indeed spam the page) - I'm not sure how equipped we are to deal with it at the current time, anyone know if we can get at least some of the following measures installed?

  • CAPCHA for new IPs
  • AbuseFilter extention
  • WriteAPI for sysops (I was trying to use a bot to clean up the spam, but [[Special:ListGroupRights|Sysops can't use the writeAPI] - which is annoying
  • Sysop/b'crat can add and remove bot to help clean up spam without disrupting RC.

-- RandomTime 01:34, 5 June 2011 (UTC)

I don't have experience with running high-traffic mediawikis, but a permissive AbuseFilter might be the best way to go. In the very short term I would probably suggest blocking all registrations and edits from anonymous users, if you're certain these are "probe edits". — ızǝℲ 02:06, 5 June 2011 (UTC)
An AbuseFilter we can turn off and on, and prehaps blacklist a few terms would be good for a start, the only problem is that we need it installed now to stop the attacks now, which isn't going to happen -- RandomTime 02:07, 5 June 2011 (UTC)
Looking at my user page, I can say that I prefer ips to edit and use captcha on any page, no matter if it's a link or not. If people don't understand, it's due to prevent outbreaks like this. It's just my opinion though. Also, i'm for the AbuseFilter, but it won't help with so many different ips editing. I think a "blacklist" of ips would be better on that. Ariyen 02:10, 5 June 2011 (UTC)
A blacklist would offer no benefit compared to just blocking the IPs - AbuseFilter allows us to set triggers to block edits -- RandomTime 02:38, 5 June 2011 (UTC)
what in the world is going on >_> Cress Arvein Cress sig.JPG 02:39, 5 June 2011 (UTC)
Someone is having fun playing with their botnet, using it on us .. basically. Mauirixxx 02:40, 5 June 2011 (UTC)
ReCaptcha and Captcha have both been broken by bots for months now. Other than utilizing your abuse filters and building up your blacklist, there's not a lot that Curse can do. Every wiki we have are dealing with spam issues atm, it goes in waves... I will look into QuestyCaptcha, I heard that is still potentially functional and if so, I will see about getting it installed, but it's not going to happen until some time next week would be my guess. -- Wynthyst User Wynthyst sig icon.png talk 03:21, 5 June 2011 (UTC)
Anonymous editing has been disabled until a better solution can be found. Good work guys! -- Wynthyst User Wynthyst sig icon.png talk 08:11, 5 June 2011 (UTC)
TY Wynthyst! Mahalo, and aloha. Mauirixxx 08:13, 5 June 2011 (UTC)
This is one case where periodic database dumps would be very useful - we could compare the dumps before/after to make sure all the spam is reverted correctly. Wyn, could you please pass along to Bryan that we would really like to have periodic dumps implemented for GuildWiki? —Dr Ishmael Diablo the chicken.gif 16:22, 5 June 2011 (UTC)
If it's true that you guys have shell access to modify the wiki files themselves, then you should be able to do your own database dumps. Good reading is here. The less waiting we have to do for support, the better. If we don't actually have shell access to the wiki ... then umm ... nevermind the preceeding statements :P Mauirixxx 18:55, 5 June 2011 (UTC)
No, we don't have shell access. Donovan had promised it to us when we were planning the move from Wikia, but nothing ever came of it. —Dr Ishmael Diablo the chicken.gif 20:17, 5 June 2011 (UTC)
I manually checked all anon edits from that day. Only the cat had to be deleted, everything else was reverted. --Vipermagi 19:15, 5 June 2011 (UTC)

Site notice - please make it more prominent

Could the powers that be make the site notice much more prominent? It currently looks like any minor announcement. It should, instead, reflect the fact that this wiki took a drastic (but necessary) step in protecting itself. In other words, this is a time for World War III headlines: bold, font-size:++, jarring colors, etc. For example:

GuildWiki is the target of a spam botnet. To protect the content, our administrators have taken the drastic step of disabling anonymous edits until the attack ends or we find alternatives to defend the site. We apologize for the inconvenience.

Thanks.  — Tennessee Ernie Ford (TEF) 00:38, 6 June 2011 (UTC)

Uhh ... I 2nd this motion? :P Mauirixxx 00:57, 6 June 2011 (UTC)
And Felix demonstrates nimbly once again why he is Omni (Thanks, m8.)  — Tennessee Ernie Ford (TEF) 01:34, 6 June 2011 (UTC)
Dang, definately bold. ^.^ I like it, much more of an attention getter. Ariyen 01:35, 6 June 2011 (UTC)
However, it completely violates our policy, quietly prevent TEF from designing color schemes. I'm sure one of the other admins can maintain the WWIII, attention-grabbing attributes, without sending everyone into repeated epileptic seizures.  — Tennessee Ernie Ford (TEF) 01:38, 6 June 2011 (UTC)
I'd only worry about seizures if the background color was flashing to multiple different colors. The red grabs your attention by your eye balls and fails to let go, even after you've screamed uncle. Mauirixxx 01:45, 6 June 2011 (UTC)
Could just do...
GuildWiki is the target of a spam botnet. To protect the content, our administrators have taken the drastic step of disabling anonymous edits until the attack ends or we find alternatives to defend the site. We apologize for the inconvenience.
Ariyen 02:09, 6 June 2011 (UTC)

How to proceed

Now that it is no longer the weekend, we should implement a plan of action geared towards reinstating anon edits. The best option I have seen is the Questy Captcha that is already included in the package that we have installed on the mediawiki. To implement this, we still do not have shell access so will have to go through curse reps. Since shell access was promised to Ish when we first moved to curse, I shall be forcing that issue with Donovan. In the meantime, thoughts on what to do next?--Łô√ë Gigathrash sig G.jpgîğá†ħŕášħ 06:07, 8 June 2011 (UTC)

For reference, here's the exact text of the chat we had with him. He never says "Yes" explicitly, unfortunately, but he also doesn't dispute when Felix says "sounds like 'yes' to me."
7:09:03 PM  dr_ishmael:  what about shell access? i know we could do a lot of stuff over FTP, but modifying the wiki config or adding extensions would be easier on the command line 
7:09:14 PM  Donovan:  shouldn't be an issue ;D 
7:09:21 PM  Felix Omni:  That sounds like a yes to me 
7:09:25 PM  Donovan:  i wouldn't want 20 people to have it 
7:09:29 PM  Donovan:  bu 2-3 people is fine 
7:09:31 PM  Felix Omni:  Oh good heavens no 
7:09:40 PM  dr_ishmael:  we only have 2-3 people we'd want to give it to anyway 
7:09:42 PM  Felix Omni:  We only have a handful of people with the expertise 
7:09:46 PM  Donovan:  perfct 
7:09:46 PM  Donovan:  yeah 
7:09:48 PM  Donna:  Will we able to administrate and install MediaWiki to our liking? <-- 
7:09:56 PM  Donna:  just answered :P 
7:09:58 PM  Donovan:  should be no problem 
7:09:59 PM  Donovan:  ;D
The full chat is still archived at Ishmael Diablo the chicken.gif 12:34, 8 June 2011 (UTC)
FWIW having FTP access is nearly as good as having shell access - it would just take longer to add stuff to the wiki, though because of how relatively small extensions are filesize-wise, even that's a non-issue. The FileZilla FTP client allows you to right click edit text files with ease. I can understand WHY they wouldn't want to give out shell access (security), but FTP access is just as good, and slightly easier to configure in terms of locking down a user to a specific directory from an administrative stand point. It's just a few extra clicks on your end to edit a text file, and to unzip an extension and manually upload it. From where I'm sitting, it appears you may have an easier time getting FTP access then shell access. Especially if they're running the wiki on a Windows server instead of a Linux server (thought I read somewhere that Curse runs Windows based servers?). Mauirixxx 17:50, 8 June 2011 (UTC)
Apache and MySQL are running on *nix servers, it's the fileserver that's Windows-based.
True, FTP would be almost as good, but I doubt that would be acceptable either since they use a CVS-style code repository. Mendel and I already have access to said repository, so we can post changes, but we still have to get Kaelten/Bryan to push them to the live server. With shell access, we could perform that push ourselves without having to bother Bryan. —Dr Ishmael Diablo the chicken.gif 18:25, 8 June 2011 (UTC)
That's quite an interesting setup, to say the least :) In any case, I think I fully understand what you're dealing with now, thanks for explaining Ish. This may be a stupid question (I don't code, I "admin" for a living), is there no controls from the CVS client available to "push" a change through? On 2nd thought, is there even a CVS client, or am I assuming down the wrong path? Color me curious ... Mauirixxx 18:56, 8 June 2011 (UTC)
Yeah, we were similarly incredulous when we found out. And of course we didn't find out until we were importing our File:s and we couldn't figure out why some of them didn't import. And then I had to go cobble together an extension to handle that.
They're using Mercurial on the backend, and I'm using the TortoiseHg Windows client to manage a local copy of the repo and push my changes. I have no clue if TortoiseHg has the capability to push changes live, or whether Mercurial even allows that from external clients. —Dr Ishmael Diablo the chicken.gif 19:28, 8 June 2011 (UTC)
The problem with QuestyCaptcha is that the human controller of a bot could teach it the answers to specific questions. We'd have to 1) come up with a huge set of possible questions that have easy, obvious answers (so we don't frustrate our actual editors with obscure or ambiguous answers), and 2) rotate the questions regularly to stay ahead of the botters.
I would recommend MW:Extension:Asirra, a module for ConfirmEdit that uses Microsoft's Asirra service. Instead of requiring the user to reproduce distorted text, it requires the user to identify all the cat pictures in a set of 12 pictures of mixed cats and dogs. The photos are drawn from a database of over 3 million that is maintained at, where the pictures have been manually classified as either cat or dog. The challenge itself is quite simple for most humans to solve while being very difficult for computers, requires less brainpower and time than re-typing distorted text, and who doesn't like looking at pictures of (mostly) cute animals? —Dr Ishmael Diablo the chicken.gif 19:24, 8 June 2011 (UTC)
Now THAT sounds interesting - reading up on it now. If only there was a way to make a list of (relatively) current editors to bypass that. I read on the Mediawiki mailing list a few weeks back about an extension that while it still allows anyone to edit and "publish", the actual edit would be flagged for an admin to verify and actually publish (or something to that effect). Good for "small" wiki's - which I know GuildWiki is NOT small by any stretch of the imagination, but it is yet 1 more alternative. I'll see if I can dig it for everyone to check out. Mauirixxx 19:37, 8 June 2011 (UTC)
Ish, that IS awesome! I hate captcha, I suck at them. But this is easy, cool and cute! Arnout aka The Emperors Angel 19:59, 8 June 2011 (UTC)
Here we go: Approved Revisions & Flagged Revisions. From what I understand, "Approved" is the "basic" one, and "Flagged" is the "advanced" extension. I haven't looked at either extension personally, I'm going off of what I have saved from the Mediawiki mailing list. In either case though, it does create more "work" for admins, as they would have to approve the final edits, which on a "small" wiki might not be a problem. In any case, more food for thought. Mauirixxx 20:01, 8 June 2011 (UTC)
CATcha (see what I did there?) sounds like it could be good. I don't like the idea of having to approve revisions, and if we were going to install additional extensions, I'd personally push for AbuseFilter. --JonTheMon 20:12, 8 June 2011 (UTC)
@Arnout: "Unlike many image-based CAPTCHAs which are abstract or subjective, Asirra’s challenges are concrete, inoffensive (cute, by some accounts), require no specialized or culturally biased knowledge, and have definite ground truth. This makes Asirra less frustrating for humans. Some beta-testers found it fun. The four-year-old child of one asked several times to “play the cat and dog game again.”"[3]
@Mauirixxx: I agree with Jon, approved/flagged revisions wouldn't be a good choice for this wiki. Granted, the volume of anonymous edits is quite low, but that would still place an additional burden on "approvers" (admins or whoever else we grant that power to) to check the wiki regularly just in case there are edits that need checking. It also somewhat undermines YAV by saying, "Your edits aren't as valuable because you're not logged in."
"If only there was a way to make a list of (relatively) current editors to bypass that." ConfirmEdit is already configured to only present a challenge to anonymous editors, and only when they add an external URL to a page. So it really didn't do anything for the recent bot attack, because those edits didn't add any URLs to the page, they just inserted random text. We'd have to remove that restriction, so it would present a challenge on any anonymous edit. (We could also consider that a new feature that warns certain users when they aren't logged in. :P) —Dr Ishmael Diablo the chicken.gif 20:39, 8 June 2011 (UTC)
With the sheer amount of pages GuildWiki has, I would hate to put something like FlaggedRevs on it, I was merely throwing it out there as yet 1 more alternative - maybe as a last resort for when all captcha's are finally defeated? I personally don't mind the CATcha (hehe) option either. Mauirixxx 20:41, 8 June 2011 (UTC)
So, are we going to implement any of these ideas? --JonTheMon 14:27, 9 June 2011 (UTC)
It looks like Questy Captcha has been decided against. If we are going to implement one it should be for all anon edits, as otherwise it's just defense against edits that aren't happening. I have been on the receiving end of Approve Revisions, and it is one of the most frustrating experiences to go through. Especially if it has been a week+ and your submission hasn't even been looked at. I would rather have no anon edits then approve revision. It should also be noted that we do not have Asirra installed, and Donovan is currently at E3, so don't expect any implementation immediately. Food for thought.--Łô√ë Gigathrash sig G.jpgîğá†ħŕášħ 14:43, 9 June 2011 (UTC)
Yet another argument for why we need direct access to do that ourselves. —Dr Ishmael Diablo the chicken.gif 14:48, 9 June 2011 (UTC)
Yet another part 2: I tested Asirra on my local wiki clone, and it requires a special PHP feature (curl) to be enabled (it's part of the core instal, but disabled by default). We do NOT have access to php.ini in the repository, so any PHP changes have to be communicated to Kaelten for him to make. —Dr Ishmael Diablo the chicken.gif 19:42, 9 June 2011 (UTC)
I'm waiting on consensus so it doesn't look like I'm using my authority to push through a "master plan". It sounds like everyone supports replacing ReCAPTCHA with Asirra. Does anyone object to enabling ConfirmEdit on all anonymous edits? It's possible that the recent botspam could have been prevented if that had been enabled. —Dr Ishmael Diablo the chicken.gif 14:37, 9 June 2011 (UTC)
Did either of you look into AbuseFilter? While an updated confirmedit would stymie anon edits, this could give us the worst-case scenario "big red button" and also allow us to check if the attack is continuing (it logs things it blocks). --JonTheMon 14:56, 9 June 2011 (UTC)
I have, but it seems like it has a steep learning curve and might be overkill for the relatively minor problems we experience. Still, having a "big red button" would be nice. —Dr Ishmael Diablo the chicken.gif 16:11, 9 June 2011 (UTC)
The best thing about abusefilter is that you don't have to learn a lot about it, since you can look at other's versions. Like, for the ip vandals, we could have applied a variant of this filter from wikipedia. --JonTheMon 17:12, 9 June 2011 (UTC)


(Reset indent) I have changesets prepared to update ConfirmEdit (replace ReCaptcha with Asirra and modify the triggers) and to install AbuseFilter (no sense ignoring a tool that could be useful). I will push them to the repository as soon as we agree that there is consensus for these changes.

Also, @Giga: Have you begun to pursue the direct access with Donovan? —Dr Ishmael Diablo the chicken.gif 21:30, 9 June 2011 (UTC)

If we get AbuseFilter, I'm not sure we'll need to update the CATcha triggers. --JonTheMon 13:46, 10 June 2011 (UTC)
They serve different purposes. ConfirmEdit is preventive, while AbuseFilter is reactive. You can't define filters in advance for every single attack that will happen in the future, but if the bots can't save any edits in the first place, you'll have fewer successful attacks that require a response. —Dr Ishmael Diablo the chicken.gif 14:37, 10 June 2011 (UTC)
Fair enough. I can live with that. --JonTheMon 14:48, 10 June 2011 (UTC)
I have every confidence in you (plural you) and fully support your decisions. A F K sig 2.jpg A F K When Needed 15:38, 10 June 2011 (UTC)
I'm going to request that the AbuseFilter extension be installed today. We are using it on the Terraria Wiki quite successfully against these types of gibberbots that started attacking early yesterday. Jon created the filter, and overnight it disallowed 99 gibber edits. You can choose to use it or not, but if you wish to see anon edits re enabled, it's probably the fastest solution. While it's not perfect, it's a relatively easy. -- Wynthyst User Wynthyst sig icon.png talk 13:18, 13 June 2011 (UTC)
Great, thanks! I'm also pushing the ConfirmEdit change to Asirra (or CATcha as Jon likes to say :P ), but without the new trigger settings - it will still only trigger if a new external link is added, when creating an account, and after 3 failed login attempts. —Dr Ishmael Diablo the chicken.gif 15:23, 13 June 2011 (UTC)
CATcha is live. —Dr Ishmael Diablo the chicken.gif 16:25, 17 June 2011 (UTC)
No, it's not. -- 21:09, 17 June 2011 (UTC)
Try with a link to an extremely unlikely page to have been linked before, say, here (random link to random amazon). "it will still only trigger if a new external link is added, when creating an account, and after 3 failed login attempts." ∵Scythe∵ 23:48, 17 June 2011 (UTC)
That's a nice sofa. If it only blocks new external links, we could just add links to the spamlist as they come up. Eventually we'll run out of old ones. Felix Omni Signature.png 01:30, 18 June 2011 (UTC)
That's no sofa! (it's a slipcover, they're made to prevent your cushions from becoming threadbare.) ∵Scythe∵ 02:13, 18 June 2011 (UTC)
Sofa is the last word in the product title, therefore it's a sofa. Felix Omni Signature.png 04:13, 18 June 2011 (UTC)
You're all idiots, for different reasons.
@Mr. IP: You added those links on the Sandbox within an HTML comment. That's not actually adding a link to the page, because it isn't displayed.
@Scythe: "a new external link" means a new link on that article, not new to the wiki overall. That's just dumb.
I know it was enabled because I tested it - I logged out, then added a link to an article that wasn't on the article before and was not hidden in a comment. Asirra was triggered. —Dr Ishmael Diablo the chicken.gif 04:50, 18 June 2011 (UTC)
Asirra was installed on GuildWiki and another Curse wiki yesterday, but after testing it was discovered that it was blocking new user registrations for some reason. It's been removed and ReCaptcha has been installed until they can figure out what the problem is with Asirra (or another alternative). -- Wynthyst User Wynthyst sig icon.png talk 05:09, 18 June 2011 (UTC)
"You're all idiots" seems like a bit of a harsh critique... :'( ∵Scythe∵ 13:47, 18 June 2011 (UTC)
Goobers? —Dr Ishmael Diablo the chicken.gif 14:04, 18 June 2011 (UTC)
That may be a personal attack depending on whether you mean nostril mucus or the delicious candy. Felix Omni Signature.png 15:01, 18 June 2011 (UTC)

Outcome of anonymous editing blocking

Has there been any negative connotations since the temporary move of blocking anonymous edits, or have we been operating in a business as usual since the anonymous ban? Mauirixxx 08:08, 9 June 2011 (UTC)

We don't know. I haven't heard anything, but with all anon edits blocked, people who are blocked can't comment on the fact saying that they are blocked.--Łô√ë Gigathrash sig G.jpgîğá†ħŕášħ 08:49, 9 June 2011 (UTC)
Unless they login if they have an account or register (if that's still an option for registration for new users). Ariyen 20:52, 9 June 2011 (UTC)
Anonymous folks can still register an account. They just can't edit anything still. Mauirixxx 20:55, 9 June 2011 (UTC)
We had 12 new users register since the block was implemented, about 5.5 days (not counting reclaimed accounts or Rask). That's about as many as we'd had in the previous 2 weeks. So it definitely encouraged users to register. —Dr Ishmael Diablo the chicken.gif 21:29, 9 June 2011 (UTC)
While I don't think blocking anonymous edits has had a crippling devastating effect, I'd still like to get them back asap. Felix Omni Signature.png 22:33, 10 June 2011 (UTC)