Guild Wars 2 Wiki:Reporting wiki bugs

From Guild Wars 2 Wiki
Jump to navigationJump to 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 used to report bugs with the wiki, this does NOT cover in-game issues.

  • If you are experiencing an in-game bug or issue that requires technical support, check the Guild Wars 2 official forums.
  • If you are experiencing difficulties getting past a specific part of the game, please 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 corresponding talk page if more help is desired.
  • If you have a problem with contents of a wiki page, use the associated talk page.

Please review existing bug reports before creating a new one, these will be listed below. 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 actions taken.

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

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

No File uploads receive extra whitespace before selected licensing templates[edit]

Reported on Discord by Doodleplex.

If you upload a file, and in Special:Upload you type out the License template in the summary box, then it uploads fine and the wiki source is as expected. Example:

== License ==
{{ArenaNet image|screenshot}}

If you upload a file, and in Special:Upload you select a licensing template from the dropdown list, then an extra newline is inserted before it. Example:

<!-- extra newline -->
== License ==
{{ArenaNet image|screenshot}}

-Chieftain AlexUser Chieftain Alex sig.png 17:32, 2 April 2020 (UTC)

My upload created
== Summary ==
== Licensing ==
{{ArenaNet image|icon|Effect icons}}
I put == Licensing == {{ArenaNet image|icon|Effect icons}} into the upload summary field. Something might be wrong with mw:Manual:$wgUploadDialog --Tolkyria (talk) 12:15, 4 April 2020 (UTC)
Same issue exists on the Spanish wiki too. - Doodleplex 23:26, 29 August 2020 (UTC)
Confirmed still exists in MW 1.36. -Chieftain AlexUser Chieftain Alex sig.png 22:31, 22 October 2021 (UTC)

No Semantic query: Printout skips data[edit]

Background: I'm using a semantic query to find out which items are currently available for Black Lion Claim Tickets and for how many. In this test query on Special:Ask you can see that I try to read Has item cost.Has item value, but the column is empty for many rows. However, the combined field Has item cost always contains a proper value. This can especially be seen in the JSON version of the request - Has item cost's child property "Has item value" is correctly set, but the direct access to gives an empty result. This broke with the recent maintenance.

I don't know if other, similar, queries are broken of if this is specific to the claim ticket vendors. 11:43, 2 April 2021 (UTC)

Agree looks like a bug, somewhat odd that it appears to work fine for inline #show queries using subsets of the same data, but both #ask and Special:Ask result in the same missing data
For my later reference:

Hidden JSON

* {{#show: Black Lion Claim Ticket#vendor10 | ?Has item cost.Has item value }} <!-- should both be 1, and works fine -->
* {{#show: Black Lion Claim Ticket#vendor11 | ?Has item cost.Has item value }} <!-- should both be 1, and works fine -->
{{#ask: [[Has vendor::Black Lion Claim Ticket]] [[Has item cost.Has item currency::Black Lion Claim Ticket]] [[Is historical::false]]
 |?Has item cost.Has item value=Has item value
 |?Has item cost
 |?Sells item.Has game id=Has game id
 |?Sells item
 |searchlabel=... further results
 |class=sortable wikitable smwtable
}}<!-- should return valid numerical results for each item, but even on the individual items which work fine above, one shows 1 and one is blank/unset -->


    "Black Lion Claim Ticket#vendor10": {
      "printouts": {
        "Has item value": [1], <!-- OK -->
      "fulltext": "Black Lion Claim Ticket#vendor10",
    "Black Lion Claim Ticket#vendor11": {
      "printouts": {
        "Has item value": [], <!-- why is this blank -->
      "fulltext": "Black Lion Claim Ticket#vendor11",
-Chieftain AlexUser Chieftain Alex sig.png 13:40, 2 April 2021 (UTC)
Reported on discord- same bug will affect templates including Template:World boss table (ref). I'm concerned that this might be cached results on the browse page versus live results on the ask query... there's a risk if people went around purging recipe and achievement pages etc that we may not get the data working at all. -Chieftain AlexUser Chieftain Alex sig.png 14:42, 2 April 2021 (UTC)

Hi, we made a change this morning that could affect this bug. Could you please check again to see if it's happening? --Stephane Lo Presti talk 15:09, 7 April 2021 (UTC)

Still getting this error on the various ask printouts. -Chieftain AlexUser Chieftain Alex sig.png 16:30, 7 April 2021 (UTC)
The linked query still has empty cells. I noticed an interesting behaviour while testing the Ask page for the bug above, though. I added "Sells item.Has game id" as sort option. I still get the same number of results, 144, but without any empty cells. 07:22, 13 April 2021 (UTC)
I don't know if this helps, but here is the diff between the query without the specified sort option and the query with it. Justin Lloyd (talk) 20:27, 5 May 2021 (UTC)
In case anyone is wondering what the full queries are here are a few Special:Ask links producing likely the same queries for anyone interested: withouth sorting and with sorting. Nightsky (talk) 00:52, 6 May 2021 (UTC)
Interestingly, performing the same query for the vendor Gem Store and the item currency Gem with this sort-trick doesn't work, some property chain values are not returned. Not to mention that this trick isn't practical at all, namely first the sort method might not make any sense in the current context and second using sort properties restricts the result to pages/subobjects that have this property set while one is also interested in pages without this property (i.e. it basically adds [[<sort property>::+]] to the query, internally it appears as the additional INNER JOIN in the format=debug, as described by the two editors above).
So most likely in the process of obtaining the results (the order how the results are obtained) and sorting them, some subobject's property chain values are lost (one can also use the order = rand and experience that a result has the property chain value and after querying again it doesn't return a value). I guess that this is either caused by an incorrect smw dev edit between SMW 3.1.6 and SMW 3.2.2 or probably by a changed default configuration parameter. Offtopic, but SMW always had problems with property chains, for example when using them in sort combined with simple properties, e.g. sort = <property1>.<property2>, <property> internally rearranged the sort properties into sort = <property>, <property1>.<property2> (first sorting by all property chains of length 1 and then of length 2), completely ruining the intended sort order (probably the SMW devs aren't aware of such complicated query constructions). So in my opinion it's quite likely that this may be SMW bug, the question then however is how to fix it as several crucial templates on this wiki heavily rely on property chains.
I'm not sure if this would make any difference but what about changing the subobject names from e.g. #<subobject>1 to #<subobject>001 by using {{#padleft:<number>|3}}? Then the subobjects would be sorted 001, 002, 003, ..., 010, ... rather than 1, 10, 2, 3,... (which somehow always appears in this bug context). To be honest, I don't expect much from it. -- 12:41, 6 May 2021 (UTC)
Someone posted this at, let's see what the smw devs will say. -- 16:46, 7 May 2021 (UTC)
That was me. :) Justin Lloyd (talk) 16:52, 7 May 2021 (UTC)
Sorry, no it wasn't, thought you were referring to a post I made to the SMW users list. Justin Lloyd (talk) 16:53, 7 May 2021 (UTC)
The more attention this gets, the better; also it's "good" to see that it affects also other wikis and not only related to this one. -- 18:38, 7 May 2021 (UTC)
Today, I have set up an issue page on the sandbox SMW to actually demonstrate the issue 4988, it's now labelled as bug and not longer as a question. Furthermore, I also tried the world boss table (see directly below) in a simplified version on the sandbox SMW, exactly the same bugged result. --Tolkyria (talk) 22:47, 19 May 2021 (UTC)
Looks like they've made some progress on this one + have identified the commit that killed it. -Chieftain AlexUser Chieftain Alex sig.png 22:26, 1 August 2021 (UTC)
Fix identified under this pull request, awaits deployment and then inclusion in a SMW release. -Chieftain AlexUser Chieftain Alex sig.png 22:07, 1 November 2021 (UTC)

World Boss Table: No Boss Names[edit]

Went to see when a boss was up and the small event table at the top of is not showing the names of the bosses. This edit page also no longer has the buttons to add signature etc. The preceding unsigned comment was added by Justaplayer (talk) at 12:40, 8 April 2021‎ (UTC).

For what it's worth: The buttons still appear fine for me at least. Though i wouldn't be surprised if this page specifically has any problems as it's showing me the content of the page in the log in link (that shows up while not logged in) at the top of the diff preview again. Hasn't done that for a long time before now though so will probably go away again at one point or another again like last time or not; what do i know i guess. Nightsky (talk) 17:46, 8 April 2021 (UTC)
Yes this is related to missing printouts. -Chieftain AlexUser Chieftain Alex sig.png 18:31, 8 April 2021 (UTC)
Tried blanking the data subpage, re-adding the content (events, then timers) and purging between, but no dice. -Chieftain AlexUser Chieftain Alex sig.png 16:40, 22 April 2021 (UTC)
I rewrote the world boss template to use #show instead of property chains (very ugly way to code it, I don't recommend it unless necessary). In my opinion the wiki user experience should not suffer, especially on such a prominent page, with no fix in sight. Here I would argue that leaving it bugged won't fix it faster, only frustrate the wiki users. -- 18:38, 7 May 2021 (UTC)

Gem Store missing prices[edit]

Was told it is the same problem, so adding here so we don't forget. Many items listed on Gem Store#List of currently available Gem Store items don't have any price listed (although they have it on the Data subpage correctly), only the gem icon is there. ~Sime 11:50, 5 May 2021 (UTC)

This seems to be fixed now. Did someone apply any change or did it fix itself? --Stephane Lo Presti talk 18:49, 5 May 2021 (UTC)
Property chains of the type record can be either obtain with ?<record property>.<record field N> (bugged) or ?<record property>|+index=N (currently not bugged, at least right now it's working), see also smw:Help:Type Record/Searching a record. While this special case was fixed by using an alternative notation, any non-record related property chain can't be rewritten in a similar way, e.g. World Bosses above. -- 20:43, 5 May 2021 (UTC)

Template:Damage traits table[edit]

The property chain ?Is for skill.Is in trait line.Has canonical name in the Template:Damage traits table (see also this Special:#ask) leaving skill fact subobject, entering the trait line page and finally trying to get its canonical name fails to return a result sometimes, see also this suboptimal intermediate fix. --Version history (talk) 22:47, 11 May 2021 (UTC)

No Image cache bug[edit]

Icon cache bug[edit]

File:Hearty Sugar Rib.png - version displayed in infoboxes (40px) displays an old version with a gold border. Tried replacing the file with a new one of a different size, moving the old file, purging, refreshing, nothing seems to change it. Might need a kick on the backend for this file? -Chieftain AlexUser Chieftain Alex sig.png 13:25, 3 April 2021 (UTC)

Image / thumbnail generation seems to work only sporadically. —Kvothe (talk) 10:05, 5 April 2021 (UTC)
This one appears to be okay now, as far as I can tell, but I did a backend cache purge just to be sure. Can you confirm? Justin Lloyd (talk) 11:21, 8 April 2021 (UTC)
There's no border, for me at least, now anymore. Nightsky (talk) 17:46, 8 April 2021 (UTC)

Purge! Purge them all![edit]

Ive tried to upload a new version for File:Skritt (white fur).jpg. That works fine but I cant see the updated version on any other pages. Wanted to purge the page cache but cant even open the purge page normaly. After Ive finaly got there and hit the purge button, it took a min to purge yet I still see the old version of the image. --DiegoDeLaHouska (talk) 17:43, 7 April 2021 (UTC)

The new version shows up fine for me. This might be your browser cache playing tricks on you. Try Ctrl+F5 on a page that should show the new screenshot. Nightsky (talk) 18:08, 7 April 2021 (UTC)
Nope . Still can see the old image at Chittukk. --DiegoDeLaHouska (talk) 19:08, 7 April 2021 (UTC)
Ah, yes. My bad. I swapped the images; thinking the new one was the old and the old one the new because it loaded the old one instead of the new one in the place of the large preview. Nightsky (talk) 19:15, 7 April 2021 (UTC)
I've manually purged the image from the web servers' Varnish caches and all of the pages that link to the image seem to be correct now. Let me know if you find further instances of this kind of problem and I'll dig deeper. There were changes to the caching configuration, partially related to cookies, with this latest version upgrade, so it's possible there may be unforeseen side effects that I'd need to investigate. Justin Lloyd (talk) 11:14, 8 April 2021 (UTC)

Another one apparently[edit]

Mastery Point (Heart of Thorns).png should show up as now but it to me appears to be stuck on the previous version still. The filesize of the new version seems to be correct at least, so there's that. Nightsky (talk) 17:44, 25 April 2021 (UTC)

Regenerate (fern hound).png should be now too. And the images i uploaded before that that differed in size also seem to still show the old size in places. Nightsky (talk) 17:53, 25 April 2021 (UTC)
This is probably a caching issue which affects all images uploaded, continuing to show the previous version before eventually showing the new version. It can be manually circumvented to some degree by requesting a version from the wiki that isn't cached. Requesing a slightly smaller image usually does the trick. Compare e.g. [[File:Forbidden white.png]] and [[File:Forbidden white.png|19x19px]]. (These will look the same given some time but untill then they'll look different even though they are the same file if of being rendered at slightly different sizes.) This will work for looking at images to see if they are uploaded propperly but it's no option to go through all pages the image is used on and change the sizes slightly in order to get it to show up. So it's not usefull in that regard. Nightsky (talk) 21:12, 13 September 2021 (UTC)

No Mobile theme when viewed on desktop - not loading custom css at all[edit]

Compare the appearance of with . The table under the Category section previously loaded themes from MediaWiki:Minerva.css. It appears this is no longer the case. I cannot therefore see a way of styling the Minerva skin for desktop users.

Note that it appears Mobile.css is however served correctly for mobile devices.

Additionally I am sometimes seeing "document.body" is null being thrown in the javascript console (apparently from -Chieftain AlexUser Chieftain Alex sig.png 17:41, 26 May 2021 (UTC)

For what it's worth seems to work fine. If i use the "Mobile view" toggle at the bottom it shows up fine too. Where do you have the useformat link from if i may ask? (The useskin link from me here is from the preferences. (I recently included it in my common.js; adding to the sidebar to the left a category with preview links for all skins but the current (mw.config.get("skin");) one.)) Nightsky (talk) 02:20, 27 May 2021 (UTC)
"?useformat=mobile" is the parameter string recommended on the extension page for previewing the minerva skin, so I copied that.
"mobile view" button at the bottom still does not load any of the custom table css for me. I've also got a bunch of verifications from other folks on the discord with screenshots.
I'm also not receiving the table css with ?useskin=minerva.
In case it isn't apparent, the table being blue is the sign I'm using that stuff is working or not. -Chieftain AlexUser Chieftain Alex sig.png 06:57, 27 May 2021 (UTC)
Ok what the hell, I made an edit to a page in mobile view, and the blue header is loading again for all three options... and then I visited another page, and it's gone again, but I am receiving this JS error:
Exception in module-execute in module skins.minerva.scripts:     load.php:2:530
TypeError: document.body is null    load.php:2:567
   > jQuery 4
-Chieftain AlexUser Chieftain Alex sig.png 07:01, 27 May 2021 (UTC)
For me the table was blue with both "useformat=desktop" and "useskin=minerva" as well as with the "Mobile view" toggle and not blue with "useformat=mobile". While now it's also not blue with the "Mobile view" toggle anymore. But i don't have any errors in the console, so i'm afraid but i'm not sure i can help you here. Nightsky (talk) 17:36, 27 May 2021 (UTC)

(Reset indent) Nightsky, Chieftain Alex: Is this still an issue? Justin Lloyd (talk) 20:44, 25 June 2021 (UTC)

Still failing to render any wiki css for me if I operate from a desktop after clicking on mobile mode, so yes. -Chieftain AlexUser Chieftain Alex sig.png 22:33, 25 June 2021 (UTC)
If I browse anonymously in a new session without logging in, the theme loads. -Chieftain AlexUser Chieftain Alex sig.png 22:35, 25 June 2021 (UTC)
I can report that i had the "document.body is null" error occur now too (almost (the only difference being the language being en-gb and there being an additional &target=mobile at the end.) the same as for Alex above as well as another one simultaneously with the only difference being jQuery 9 instead of 4.), altough only on first load.
Same for me with loading fine with the toggle at the bottom while logged out but not when logged in. While when logged out contains Mobile.css in and css array in style, it doesn't when logged in, while it probably should have it then too (since it does have it while logged in on wikipedia too). Nightsky (talk) 15:22, 26 June 2021 (UTC)
Confirmed still occurs as of November (post mw update). -Chieftain AlexUser Chieftain Alex sig.png 09:59, 18 November 2021 (UTC)

MW 1.36 upgrade (20/10/2021)[edit]

Please add bugs related to the upgrade below this heading, thank you. -Chieftain AlexUser Chieftain Alex sig.png 17:44, 20 October 2021 (UTC)

Note resolved/mitigated things have been moved to the archive. -Chieftain AlexUser Chieftain Alex sig.png 09:59, 18 November 2021 (UTC)

No Caching appears to not work[edit]

It seems that when viewing any page, then refreshing/reloading it (Note: Not purging.), the cache timestamp changes even if done before the time the pages are set to be cached for; indicating it might not work propperly. Try e.g. the following code on any page, refresh/reload it, then try it again.

var r = mw.config.get("wgPageParseReport");
console.log(r.cachereport.timestamp, r.cachereport.ttl);

The date will be different even if this is done when less than the seconds indicated have passed. At least it is always different for me. Nightsky (talk) 18:20, 21 October 2021 (UTC)

On the plus side, time based templates should never be wrong due to caching this way; at least imidiatelly following a page reload. (E.g. 14:02:12 TT.) Though pages semingly always being reparsed doesn't paint an all to well picture of server load.
And while technically better fitting under the Mw Indicator Smw Entity Examiner heading, which weirdly seems archived even though it's not realy fixed, i wonder if that fix, if it's even in place which i can't tell as it got never answered so i have to speculate even more, is possibly responsible for the slowness of bot edits. Nightsky (talk) 07:09, 2 November 2021 (UTC)

No Editing robot fails to upload[edit]

Several files fail to actually upload from Widget:Editing robot even though the page says they were successful. Confirmed this happening with ranges of files and repeating the upload (up to 4 times in one case) was needed to upload. The fact that they silently failed and looked like they uploaded made it hard to track down what was missing as well. Dak393 (talk) 19:27, 26 October 2021 (UTC)

I've added some more error handling to the widget such that it should stop the execution and appear in the red box if it triggers (for example) the type of MW error that was being experienced in the section above (apiwritedenied) - if its a MW error it'll say it succeeded with the request, but it will actually have failed + there should be a message to look at. The reason for failing will appear in the dev console (F12 for Firefox) -Chieftain AlexUser Chieftain Alex sig.png 20:49, 26 October 2021 (UTC)

No Page requires a refresh to properly load javascript[edit]

Sometimes occurs when:

  1. Searching for a chatlink on Special:Search - the MediaWiki:ChatLinkSearch.js bit apparently does not fire, and the decoded chat link never appears.
  2. Visiting a random page - the trading post prices never appear and the loading placeholder remains.
  3. Visiting a random page - the chatlink does not load and remains blank - not sure this still occurs post widget upgrade
  4. Monobook occasionally does not receive a masthead - the script that does this is at MediaWiki:Monobook.js (I have just added a debug message) - sometimes it loads the js faster than the rest of the page (i.e. it tries to target an element which does not yet exist). Might be a smart way to wait until its been created?

I need to have a look at the console next time I experience this bug. -Chieftain AlexUser Chieftain Alex sig.png 20:57, 1 November 2021 (UTC)

It also affects expandable tables, which uses MediaWiki:CollapsibleTables.js, by not collapsing them on page load. This includes the template Spoilers that to be honest should never fail.
Could this be a browser-related bug, namely only affecting Firefox? I'm not using Chrome that much and can't remember if it occured there for me, but right now I couldn't reproduce it. --Tolkyria (talk) 22:04, 1 November 2021 (UTC)
Like with almost everything i can only guess but if it's in any way related to jquery not loading then the only thing i could find about that back when i looked for why that might be was mw:ResourceLoader/Migration guide (users)#jQuery and mw:JQuery#ResourceLoader, which looking at Guild Wars 2 Wiki:Changelog could be possible (since there's a lower version than 1.17 listed), but i wouldn't know how to tell if it's both a thing and or if it's even related or not. Nightsky (talk) 07:09, 2 November 2021 (UTC)

No Special:Search occasionally does not redirect when searching for a single chatlink[edit]

Reported on discord by BuffsEverywhere and Sime:

When performing a /wiki [chatlink] search from ingame, occasionally MediaWiki:ChatLinkSearch.js does not redirect to the target page.

The chatlink is extracted and the page is displayed below the search bar, indicating that the JS is working, but apparently it is not then redirecting.

I have asked for confirmation that they actually close their browser between gaming sessions + that they haven't searched for the same page twice in the same session - currently the script is written to deliberately prevent redirect on second search, to allow use of the browser back button. -Chieftain AlexUser Chieftain Alex sig.png 20:44, 24 November 2021 (UTC)

There wasn't anything besides the chat code part of the search either i presume? Since that would prevent a redirect from occuring as well; even if it were only spacing, as per the regex. Also, do there happen to be any surviving search queries for which this occured? If not, it might help collecting them going forward? Nightsky (talk) 21:29, 29 November 2021 (UTC)

Yes The maintenance scripts are no longer running[edit]

There's the warning sign (⚠) that's currently before the Outdated entities entry on Special:Statistics and the not presence of logs on Special:Log. And if this is to see if the wiki is faster i can report that that doesn't seem to be the case to me. Also, for all i can tell it might just contribute to the slowness if left unchecked; as i thought it would have slowed down the wiki before, back when it were many more, didnt it? Nightsky (talk) 21:29, 29 November 2021 (UTC)

I'm investigating this. It seems they haven't run since the upgrade to 1.36. I'm running them by hand now and working to figure out why they haven't been running properly every night, as the system logs say they have but Special:Log shows they haven't run since October 20. Justin Lloyd (talk) 21:50, 29 November 2021 (UTC)
I've figured out the issue. The script is running manually right now but should return to automated runs tonight. Justin Lloyd (talk) 13:54, 1 December 2021 (UTC)
Seems it did just that. Which, if it continues as it did last time, which i don't see why it wouldn't, means everything is back to normal. (Appart of it running an hour later now, at least relative to UTC; as well as in a different order. (Which i'm guessing is because of DST vs. not DST and doesn't matter.)) Well done! And so quickly too. Nightsky (talk) 17:35, 2 December 2021 (UTC)