Guild Wars 2 Wiki:Reporting wiki bugs

From Guild Wars 2 Wiki
Jump to: navigation, search

Please report all bugs found on Guild Wars 2 Wiki here.

This page is NOT for reporting game bugs, those should be reported at the official forums.



This page is for reporting bugs that you may encounter in the wiki. This does not cover in-game issues that you may encounter, nor does it cover page contents within individual articles.

  • If you are experiencing an in-game bug or issue that requires technical support, check the Guild Wars 2 support forums.
  • If you are experiencing difficulties getting past a specific part of the game, use the "Search" box on the left to find the specific quest, mission, or region that you are finding difficult. You can review any tips on that page, and discuss it on that page's talk page if more help is needed.
  • If you have a problem with contents of a page, use the associated talk page.

Please review existing bug reports before creating a new one. If you add a bug not related to the wiki (such as a bug in the game itself), the report may be removed with no action taken.

When reporting a new bug, be sure to provide a description of the problem, your wiki username, the information from any error message received, and any additional comments that may help someone reproduce and troubleshoot the suspected bug.

Key: Yes = Solved, No = Unsolved, No = Not a bug

Yes Search bar weirdly case-sensitive[edit]

If I'm about to write a two-word search and I do not capitalize the second word, I'm not getting an article suggestion in the drop-down menu, even if the search term is exactly matching an article. Screenshot 1
However if I instead capitalize the second word (and I don't need to capitalize the first), I'm getting the correct suggestion. Screenshot 2
A minor bug, but somewhat annoying. —Nelg (talk) 18:06, 27 May 2015 (UTC)

Not a bug, that's just how the base version of MediaWiki works. There are extensions that modify or replace the search engine, but we don't have any of them installed. —Dr Ishmael User Dr ishmael Diablo the chicken.png 19:09, 27 May 2015 (UTC)
Yeah, noticed that very long ago, and it really bugs me to have to capitalize that second word. >_> – Valento msg 19:13, 27 May 2015 (UTC)
I'd like to add something related to the search bar capitalization "issue". If you search something having capitalized the first letters (i.e Bowl of Spiced Meat Chili) and press "Go", you are promptly redirected to the correct webpage (http://wiki.guildwars2.com/wiki/Bowl_of_Spiced_Meat_Chili). If however you search without capitalizing (i.e. bowl of spiced meat chili), you are redirected to the "Create the page "Bowl of spiced meat chili" on this wiki!" page (although the correct result is indeed just below that). In some instances, when searching without capitalizing (i.e. bottle of elonian wine), you are redirected to the lowercase page "http://wiki.guildwars2.com/wiki/Bottle_of_elonian_wine" which shows a "502 - Web server received an invalid response while acting as a gateway or proxy server." I'm just mentioning it, so that you are aware of the 502 Server Error page, rather than any "fix" related to search capitalization. Father Eko (talk) 15:58, 15 February 2016 (UTC)
Per the request on the GW2W:TECH talk page, Stephane + Justin have plans to implement extension:titlekey which will resolve the problem for the few pages that the search fails to find due to case problems.
By the way, the Bottle of Elonian Wine problem was totally unrelated - the recipe list by discipline template craps itself if it is used on a frequently used item (some guy kindly added all the mystic forge recipes for elonian bottles of wine). The page needs splitting up. -Chieftain AlexUser Chieftain Alex sig.png 19:55, 15 February 2016 (UTC)
Hi hi, Justin installed the TitleKey extension and I tested "bowl of spiced meat chili)" successfully. Let us know if you see anything else not working following this change! Thanks --Stephane Lo Presti talk 16:03, 13 April 2016 (UTC)

Yes HTTPS login/search redirects to non-HTTPS page[edit]

Whenever there is a redirect, GW2wiki brings me to non-https version of the pages. For example,

1. Visiting the main page via https://wiki.guildwars2.com/ redirects to http://wiki.guildwars2.com/wiki/Main_Page

2. Logging in from https://wiki.guildwars2.com/index.php?title=Special:UserLogin&returnto=Main+Page&error= redirects to http://wiki.guildwars2.com/wiki/Main_Page

3. Searching an existing article (e.g. damage) from the search panel and press "Go" or

4. Searching via direct link https://wiki.guildwars2.com/index.php?title=Special:Search&search=damage redirects to http://wiki.guildwars2.com/wiki/Damage

--Fanolian (talk) 13:26, 30 September 2015 (UTC)

Purging a page by using "?action=purge" also redirects to an http address. -Chieftain AlexUser Chieftain Alex sig.png 17:35, 9 June 2016 (UTC)
This issue is now fixed (thanks Justin!) -Chieftain AlexUser Chieftain Alex sig.png 19:00, 6 July 2016 (UTC)

Yes Pages with apostrophe in title cause "too many redirects" error in Chrome[edit]

After trying to search for "Hero's Canton", I discovered that any page with an apostrophe in the title/URL causes Chrome to fail to load, citing a "too many redirects" error. I'm not a wiki or Chrome expert so I don't know why, but given that similar pages on Wikipedia load correctly, I'm inclined to suspect it's a problem with something this wiki is doing. NikkoJT (talk) 19:30, 16 March 2016 (UTC)

This doesn't appear to be just Chrome, as IE and Safari also exhibit the issue. I'm investigating. Justin Lloyd (talk) 19:48, 16 March 2016 (UTC)
And Firefox too, just to cover all bases. Also the bottom part of the page seems to be buggy too, I have to tab through the page and hit enter on the upload button to be able to upload images now because the button itself doesn't work. =( - Doodleplex 20:23, 16 March 2016 (UTC)
The upload button works in our test environment so at least it wouldn't appear to be a MediaWiki-specific bug. I'll investigate that as well. Thank you for pointing it out. Justin Lloyd (talk) 20:32, 16 March 2016 (UTC)
I would guess that its probably related to the "fix" implemented to work around "+" signs? (+10 Agony Infusion doesn't work either). -Chieftain AlexUser Chieftain Alex sig.png 20:46, 16 March 2016 (UTC)
I found a related issue in Phabricator (https://phabricator.wikimedia.org/rMWa89a21990e9d696487c4da72f88f765e2b4b1c34) so I applied a two-line fix to GlobalFunctions.php (lines 433 and 444 in the code at that link) and the affected pages appear to work now. Let me know if you see any further issues regarding this. Justin Lloyd (talk) 20:52, 16 March 2016 (UTC)
Just noticed your comment about plus signs as well. I'll see if a similar fix helps in our test environment. Justin Lloyd (talk) 20:57, 16 March 2016 (UTC)
Actually plus signs seem dangerous, though I have another place I can look regarding that. Justin Lloyd (talk) 21:00, 16 March 2016 (UTC)
Might also be related to why the link option in #ask (Example), which generates a link to Special:Ask, doesn't work at all now.--Relyk ~ talk < 21:17, 16 March 2016 (UTC)
For reference sake, Justin says via email that he has fixed the plus sign bug on all language wikis. -Chieftain AlexUser Chieftain Alex sig.png 17:25, 18 March 2016 (UTC)
Is the problem with #ask something related to a server software (e.g. Semantic MediaWiki) or content (i.e. that you guys can change)? -Stephane Lo Presti talk 22:06, 18 March 2016 (UTC)
The issue seems more like MediaWiki not liking the special characters in the URL generated by SMW. It's not a significant concern. The only thing I've used it for is links to query examples. Special:Ask itself uses an alternative way of forming the URL that works perfectly fine. The other site I checked had no problem handling the URL link generated by SMW.--Relyk ~ talk < 01:30, 19 March 2016 (UTC)

(Reset indent) Hello, pages with ampersand also have this issue (fr:Chercheuse senior de PR&T Takka), thanks --IruleManik (talk) 08:38, 29 March 2016 (UTC)

I've fixed the ampersand issue. Justin Lloyd (talk) 21:45, 29 March 2016 (UTC)

1Yes Captcha[edit]

I don't think the captcha is active anymore. It doesn't appear when using Special:CreateAccount. I suspect this is what is causing all of the spambots to be creating pages and accounts today (and why the abusefilter is consuming all of the space on Special:RecentChanges. -Chieftain AlexUser Chieftain Alex sig.png 13:32, 17 March 2016 (UTC)

I seem to recall we used to have some very weak GW2 questions on our createaccount page, but I think mw:Extension:ConfirmEdit#ReCaptcha (NoCaptcha) might be the latest thing to use instead. -Chieftain AlexUser Chieftain Alex sig.png 13:35, 17 March 2016 (UTC)
Our engineer is going to investigate NoCaptcha, since we're going to move captchas on all the wikis to the same captcha system. -Stephane Lo Presti talk 00:26, 18 March 2016 (UTC)
Adding to this, the captcha is broken on at least DE. If you try and create a page, the description for the captcha is shown, but the captcha itself is invisible, so you can't complete it, since there is no text boxes. --Tera (talk) 11:26, 18 March 2016 (UTC)
The captchas are all showing up again. Let me know if there are any issues with using them. Justin Lloyd (talk) 18:08, 18 March 2016 (UTC)

Yes Signature button[edit]

mw:Manual:$wgExtraSignatureNamespaces needs to be enabled for Guild Wars 2 Wiki/Project, Help, and User. We might want Main for whatever reason, although it would dissuade anonymous users from commenting and signing on the mainspace instead of talk.--Relyk ~ talk < 06:14, 17 March 2016 (UTC)

I've enabled this for the three specified namespaces and it appears to be working. Let me know if there are any issues and if you want the Main namespace added. Justin Lloyd (talk) 20:15, 31 March 2016 (UTC)

No de/fr/es: Main page tab untranslated[edit]

On the non-en wikis the tab titles for the main pages say "Main page" instead of their translated version (like "Hauptseite" in german). It seems like this is caused by a missing translation entry. It can be worked around by editing MediaWiki:Mainpage-nstab, but I thought I'll mention this here. --Tera (talk) 11:26, 18 March 2016 (UTC)

Yes Image Page Bug[edit]

Not sure if it's my browser(Firefox) but if I go to any image page, it shows me as logged out, so I wouldn't be able to revert or upload a new version of that image. However if I then click "Edit" on the page I'm magically logged back in again and can tag stuff. Logging in on the page doesn't work either, it still shows me as logged out. - Doodleplex 18:23, 31 March 2016 (UTC)

I'll add that this just started happening to me as well, so it is gated to only one person. In order to upload I had to click the 'upload file' link. I can't follow a red-link for a file to upload it. -Darqam (talk) 19:51, 31 March 2016 (UTC)
Likewise. Wierd. -Chieftain AlexUser Chieftain Alex sig.png 19:56, 31 March 2016 (UTC)
Just tested on chrome, an issue there as well... damnit I'm trying to hide a typo here >.> -Darqam (talk) 19:57, 31 March 2016 (UTC)
Curiosity found your typo before you even mentioned it, I thought perhaps it was just the file name in the game that you wrote it like that until you said that. XD - Doodleplex 20:00, 31 March 2016 (UTC)
This may have been a server-side issue. Let me know if you're still experiencing this issue. Justin Lloyd (talk) 20:03, 31 March 2016 (UTC)
Looks good to me so far. - Doodleplex 20:04, 31 March 2016 (UTC)

Yes vendor item table row[edit]

Template:Vendor item table row hates apostrophes now. In the cost column it gives Expression error: Unexpected < operator. (for instance, see Priory's History (achievement)) for items with an apostrophe in their name. Items without an apostrophe work fine --Gimmethegepgun (talk) 21:00, 4 April 2016 (UTC)

Thanks for the report. The problem was the comma, not the apostrophe, but this error was introduced by me when fixing a problem related to brackets in page titles at the weekend. -Chieftain AlexUser Chieftain Alex sig.png 22:07, 4 April 2016 (UTC)
So it was just a coincidence that the items I checked fell into that pattern then. Neat. Oh well, bug found and fixed --Gimmethegepgun (talk) 01:38, 5 April 2016 (UTC)
Yeah, it was any item costing over 1000 coins ("1,000"). Luckily {{vendor item table row}} is fairly unusual, and {{vendor list result format}} had a fix that worked. -Chieftain AlexUser Chieftain Alex sig.png 05:58, 5 April 2016 (UTC)

No Loading all css twice[edit]

This is pretty minor, but -at least according to firefox element inspector- it seems that at least the common.css stylesheet is loaded twice. The first time it loads, it is minified and combined with other stylesheets (this is how it used to be), and the second time it loads, it has not been minified. This effectively means that the user has to load an additional 477 CSS rules that they already have. -Chieftain AlexUser Chieftain Alex sig.png 17:29, 7 April 2016 (UTC)

Yes CAPTCHA for registration doesn't show[edit]

It's impossible to register an account on the wiki. The CAPTCHA on the registration page doesn't load in Firefox, Chrome nor Internet Explorer (Without plugins of any sort). 130.226.70.48 19:37, 11 April 2016 (UTC)

I think this is either insta-resolved or a problem on your end. I just created an account using chrome with add-block and a few other extensions running. -Darqam (talk) 19:49, 11 April 2016 (UTC)
Justin (ArenaNet back end wiki dude) is looking into problems like these, the issue is widespread on the de wiki at least. -Chieftain AlexUser Chieftain Alex sig.png 20:16, 11 April 2016 (UTC)
The actual captcha and account creation do work, as you can see recent accounts created aside from my Test accounts on Friday, so the problem may well be at the users' ends and/or routing related. That said, account creation was working against the google-proxy URL prior to the move from ReCaptcha to NoCaptcha. So having more data about whether the problem is just with the non-English wikis and whether everyone everywhere is affected or perhaps just outside the US, for example, would be helpful. Justin Lloyd (talk) 20:48, 11 April 2016 (UTC)
Info blurb in case it does help. Currently in Canada (and not doing any fancy connection jumping), able to register accounts on En, De, and Fr wikis. This done on firefox. The preceding unsigned comment was added by Darqam (talkcontribs) at 20:55 11 April 2016 (UTC).
User Chieftain Alex account creation captcha fail.jpg
Firefox, United Kingdom. Could not create account. 404 error when attempting to reach "https://google-proxy.ncplatform.net/recaptcha/api.js". Same error with my add-ons disabled too. -Chieftain AlexUser Chieftain Alex sig.png 21:42, 11 April 2016 (UTC)
We've made an adjustment to a load balancer configuration that may have been causing this for people outside of North America. Please let us know whether the captcha appears to be working any better now for those of you in the EU. Justin Lloyd (talk) 16:11, 12 April 2016 (UTC)
Successfully created "User:CA Captcha test 01". Well done! -Chieftain AlexUser Chieftain Alex sig.png 16:57, 12 April 2016 (UTC)
Thanks, Alex! Justin Lloyd (talk) 17:01, 12 April 2016 (UTC)

Yes Exclamation point breaks Template:Effect in Template:Item infobox's description field[edit]

As seen on an old version of Killstreak Experience Booster, using Template:Effect with an exclamation point at the end completely breaks the description field of Template:Item infobox. Putting in an invalid name with an exclamation point at the end does not result in the bug. The effect icon is shown, but the effect description is not, and all further text in the description field of Item infobox is cut off. It is instead present on the mouseover text of the icon. This icon is able to be changed with effect's icon field, but stacks is put into the mouseover. Using Template:Effect icon manually with {{effect description|Active Kill Streak!}} as the second parameter, the way Template:Effect does, results in the same bug. Manually inputting the same text string does not. However, no problem occurs in either case if the template is used standalone, outside of Template:Item infobox, and the bug only involves the description parameter. Putting the other parameters below description does not involve them in the bug, and they appear normally. --Gimmethegepgun (talk) 07:40, 3 May 2016 (UTC)

Semantic mediawiki doesn't like exclamation marks in titles. The SMW query code syntax to exclude a page is [[Located in::!Tyria]] (this would return locations in the mists for example), so i don't really think we can avoid this. -Chieftain AlexUser Chieftain Alex sig.png 19:07, 6 July 2016 (UTC)
Update: looking at it a bit harder, inspecting the old html showed that the description was being inserted into the hover text for the image. Removing the description from the hover text should fix this issue in the future. -Chieftain AlexUser Chieftain Alex sig.png 19:19, 6 July 2016 (UTC)

Yes Change notification emails are failing SPF checks[edit]

The emails come from arena.net, which specifies arena.net. 300 IN TXT "v=spf1 include:spf.protection.outlook.com -all", but they're being sent by 64.25.39.17 (64.25.33-17.ncsoft.com), which I'm pretty sure isn't going to be listed in Outlook's SPF records. I guess the fixes are either to update arena.net's SPF record, or to change the envelope sender the wiki uses. -- Dagger (talk) 21:09, 18 May 2016 (UTC)

Hi Dagger, we're looking into the issue (no eta on the fix). How impacting is this for the word of editors? --Stephane Lo Presti talk 23:05, 18 May 2016 (UTC)
Depends on how their email server handles SPF failures. If it outright rejects them (like my backup server does) then they just won't get any notifications. I'm not sure what Gmail/Hotmail/etc do though. It's been like this for at least a month or two so I guess nobody cares much (or maybe they're just enjoying the break from the constant stream of page edited messages). -- Dagger (talk) 00:25, 19 May 2016 (UTC)
Hi Dagger, our engineer did some changes. Can you let us know if it now works for you? Thanks --Stephane Lo Presti talk 21:46, 26 May 2016 (UTC)
Thanks for taking a look. If I put the new mail details into [1] (IP: 64.25.39.16, sender: community@guildwars2.com) it tells me that the policy goes over the limit of 10 DNS queries for SPF, so the SPF check fails with status permerror. And if I look at my server's SPF preferences, they're configured to accept mail that fails SPF with permerror. So technically it does fix things for me.
I don't know how common it is for email servers in general to ignore permerror though. It might be a good idea to try and avoid that (although I'm not sure how, since most of the queries happen via dependencies on SPF records from other people's domains...).
GW2 order confirmations and login authorization mails are also sent from guildwars2.com, so if this caused widespread issues then I guess we'd know about it by now. On the other hand, if there are unexplained delivery failures to a few people, this might be why. -- Dagger (talk) 22:32, 27 May 2016 (UTC)
I've made a change to the guildwars2.com TXT resource record so you should now see Pass responses in the Received-SPF email headers for the wiki guildwars2.com emails. Justin Lloyd (talk) 22:02, 1 June 2016 (UTC)
Yep: Received-SPF: pass (guildwars2.com: 64.25.39.17 is authorized to use 'community@guildwars2.com' in 'mfrom' identity (mechanism 'mx' matched)).
I was just wondering what happens to mail from zdsys.com (Zendesk), or from spammers. SPF validators are limited to doing 10 DNS requests in the course of validating a record, and you have enough includes in your record (after recursion) that it goes over that limit when trying to process the zdsys.com include. Depending on how a user's mail server is configured, either legitimate mail from Zendesk (= GW2 support) will be rejected (because SPF validation failed) or some spam mail will be accepted (for the same reason).
Either way -- my own problem of not receiving wiki mails is fixed, so thanks for that. I just thought I'd point out this extra potential issue that I noticed while I was at it. -- Dagger (talk) 23:51, 4 June 2016 (UTC)
You're correct, we definitely understand that this is still a problem and it is something we're discussing internally. The domains we allow in our SPF record just use so much recursion that we need to come up with a better approach to suit our requirements. Justin Lloyd (talk) 15:50, 6 June 2016 (UTC)