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 Autocompletion on search box uses Article (or Special) namespace only[edit]

This issue is known about by ArenaNet. We have attempted initial debugging and my personal current conclusion is that it appears the API call being made - e.g. - isn't returning any valid results, when it should be, considering that this syntax matches that used on mediawiki etc. Weirdly the "Special" namespace works ok. Current suspected extensions affecting this functionality are the ones providing the popups, i.e. Extension:Popups, Extension:TextExtracts or Extension:PageImages. -Chieftain AlexUser Chieftain Alex sig.png 23:28, 25 March 2020 (UTC)

So ArenaNet have traced the issue to mw:Extension:Titlekey. Paraphrasing: "[A] There's a known bug where namespace suggestions broke due circa MW 1.32 (which has a suggested patch as of today, however applying this patch throws an error!) however this conflicts with [B] another commit where they're trying to get letters with-accents to appear in suggestions when you type without-accents."
Links for A: , - and the error when trying to use the patch Error from line 109 of /var/www/sites/gww-en/includes/api/SearchApi.php: Call to undefined method TitleKey::getProfiles()
Links for B:
For the moment this means we have two options, either:
(1) Leave the extension as it is, which provides case-insensitive search autocompletion results for Mainspace articles only. This impacts basically only editors.
(2) Disable the extension, which will require us to type pages in a case-sensitive manner but will match on any namespace. This will impact viewers and editors.
Seems like we have to live with Option 1 for the moment. -Chieftain AlexUser Chieftain Alex sig.png 23:08, 1 April 2020 (UTC)
What about option 3, using another search extension? :P --BuffsEverywhere (talk) 23:53, 2 April 2020 (UTC)

(reindent) Do you mean things like typing "User:Chief" no longer resolves to "User:Chieftain Alex"? I didn't want to start a new section if this is the same bug.

It's unfortunate that this cannot be fixed. As a non-editor, I use this to find categories and pages such as Tanetris' guide to gear. I can remember that user's name. I can never remember what the page is called or how else to find it.

Thanks for trying to find a solution. My compliments to coder(s) behind the SAB theme. 04:41, 20 April 2020 (UTC)

Sorry for the late reply but yes, what you describe is the same search bug as this topic. -Chieftain AlexUser Chieftain Alex sig.png 06:07, 29 April 2020 (UTC)
What if mw:Extension:TitleKey won't get an update soon? Picking up BuffsEverywhere suggestion, what about: mw:Extension:AdvancedSearch, mw:Extension:CirrusSearch and mw:Extension:Elastica, used by many wikis, e.g. wikipedia and mediawiki. See here for the provided features: mw:Help:CirrusSearch, but most importantly: we would be able to see namespace previews. Whether we want to browse templates or properties as wiki editor, files or categories as wiki user, right now it's quite tedious to find them without any preview. --Tolkyria (talk) 19:50, 29 April 2020 (UTC)
Please consider replacing TitleKey with an alternative. Not having autocompletion is really annoying! --BuffsEverywhere (talk) 21:23, 26 May 2020 (UTC)
(Reset indent) Guild Wars 2 Wiki talk:Requests for technical administration#Removal of the broken mw:extension:TitleKey and replacement with something that works - discussion raised. If you think anything has changed from the above, please chime in. I'll wait a day or two for feedback then put a tech request in. -Chieftain AlexUser Chieftain Alex sig.png 21:15, 7 December 2020 (UTC)

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)

Yes Property's allows value are stuck[edit]

We added the [[Allows value::Dragon Response Mission]] to the Property:Has location type (see also smw:Help:Special property Allows value). While the special smw property Allows value stores this new value (see Special:Browse/:Property:Has location type), the Constraint schema doesn't recognize it which should be the internally relevent part. Furthermore, we also removed an allowed value, nevertheless the allowed values in the constraint schema didn't update; it's stuck. Hence it doesn't recognize "Dragon Response Mission" as valid location type (see e.g. Dragon Response Mission: Metrica Province in the infobox or the smw tool Special:ProcessingErrorList). Neither purging nor deleting + restoring the page (to somehow force a property rebuild, I don't know if this is resonable approach at all) solved this problems (see also Property talk:Has location type). Can this be fixed by running a smw backend repair script? --Tolkyria (talk) 09:27, 19 November 2020 (UTC)

Do you recall we used to have "Has game context"? It so totally broke that we had to create a whole new property. We also used to have another very widely used property with fixed values.. we ended up removing all of the allowed property restrictions. So this isn't the first time we've had this occur, but hopefully it isn't quite that bad.
Not sure what button Kvothe tried, as a full rebuild on this wiki takes a few days and breaks loads of templates whilst rebuilding- we should put up a site notice if we're doing that.
If you get one of the admins to ping Stephane/Ruby on discord then they can get Justin to have a look. Otherwise I'll have a look when I get my pc working next week (hopefully), I however wonder be able to see much more in terms of smw than you though. - 17:30, 19 November 2020 (UTC)
Hey all, I have this page on my watchlist. :) I saw the initial message but since I'm not really familiar with how to use SMW in general and specifically the complex ways in which it's used on these wikis, I held off until there was further discussion on the issue. That said, I'm happy to do what I can to help with this, so if there is a maintenance script that might help (I run rebuildData.php on every major upgrade), I can certainly do that, but I'd definitely want to ensure the SMW experts here feel such a nuclear approach would be warranted. Thoughts? Justin Lloyd (talk) 17:35, 19 November 2020 (UTC)
Okay, there are several answers, I'll try to group them a bit:
  • Alex, the property "Has game context" was before my time. Trivia: the only time I worked with the "Has game context" property was in 2019 when I changed it to "Has context" in an inline query, four years after this incident.
  • I'll change the in-text property annotation to the #set annotation in the {{Location infobox}}, not longer suppressing the link but still showing the smw warning (maybe I'll hide this as well).
  • I think Kvothe already rebuilt the whole wiki in less then 20 hours, if I understood his comments correctly, see the property talk page, using this smw:Help:Repairing SMW's data#Using a special page.
    In the meanwhile I doubt that a simple rebuild command will fix this (it's just a feeling, but based on what we (especially Kvothe) already tried, again see the property talk page). I'm not familiar with the smw backend but I think that the property page somehow lost its connection with its internal representation. E.g. the Property:Has location type shows the stuck Constraint schema tab which isn't updated when removing or adding new allowed values (note that no other property shows this tab in general); as already stated above, the special Property:Allows value (connected with the page) is up to date. Hence, I suspect that we need some kind of "purge exactly this property" command, however not sure if something like this even exists.
  • Probably, we should wait for Alex and give him some time to investigate it before we take further actions.
--Tolkyria (talk) 18:19, 19 November 2020 (UTC)
Reading smw:Help:Maintenance script rebuildData.php, there is the parameter --page=<page>, so what about this: php rebuildData.php --page="Property:Has location type" -v, there is also the option -f ("Fully delete all content instead of just refreshing relevant entries. This will also rebuild the whole storage structure. May leave the wiki temporarily incomplete."), not sure how dangerous this option is or if it's actually doing what we want, namely completely reseting the property. --Tolkyria (talk) 18:54, 19 November 2020 (UTC)
There are a couple of SMW maintenance scripts I run daily, as you can see in, specifically I run rebuildData.php --skip-properties --dispose-outdated, which obviously skips properties. So I can try your suggestion if there's further consensus that it's likely safe. We could also reproduce the issue and test whatever fix on the Dev wiki first for those who have access to it. Let me know what you think. Justin Lloyd (talk) 20:28, 19 November 2020 (UTC)
Sorry, I was probably too impatient, in the end it currently affects only three pages; right now we won't need more allowed values, just for the future it would nice to have an actually editable property. Let's wait for Alex until he got his new PC, he has more power and knowledge to look into it properly.
Regarding the reproducibility, we created Property:Test and copied the same wiki text there, it has no issues at all. --Tolkyria (talk) 22:11, 19 November 2020 (UTC)
Rebuilding the property page alone seems ok, I think tolkyria's fragment should be ok to run. (assuming -f is compatible with --page selector). I am wondering if any page refering to that property will also need a kick but we can figure that out later. Justin can we try a one off run of php rebuildData.php --page="Property:Has location type" -v (without "f" as a first attempt). -Chieftain AlexUser Chieftain Alex sig.png 20:26, 24 November 2020 (UTC)
Alex, I tested the command in dev and it seemed ok, so I went ahead and just did live as well. Hope it helped! Justin Lloyd (talk) 20:34, 24 November 2020 (UTC)
Unfortunately it's still bugged, you can check it with e.g. {{#set: Has location type=Test}} in mainspace or userspace (preview is enough), if there is no smw warning then it worked. Note that we removed all allowed values, hence setting it to "Test" should work and should not display a warning; however, the warning sign is there and displays the old stuck allowed values list: "Continent, Region, Zone, City, Lobby, Activity, Guild hall, Area, Point of Interest, Dungeon, ..." --Tolkyria (talk) 21:08, 24 November 2020 (UTC)
I just tested it with the -f flag on dev and that still shows the bug. Also, just FYI, it took about 18 seconds to run and probably broke the wiki during that time, so doing it in live would certainly necessitate a short, early morning downtime. Justin Lloyd (talk) 21:15, 24 November 2020 (UTC)
(Reset indent) For the record, we've implemented a workaround for the moment where we've created a duplicate property Property:Has location type 2. Until this issue is fixed we'll leave this workaround in place (who knows, might be fixed next time we do a complete SMW rebuild). -Chieftain AlexUser Chieftain Alex sig.png 21:10, 4 December 2020 (UTC)
This property magically became unstuck after the most recent wiki update. See Property talk: Has location type#Post update. --BuffsEverywhere (talk) 06:47, 20 May 2021 (UTC)

Yes Mw Indicator Smw Entity Examiner[edit]

Is this element with the id mw-indicator-smw-entity-examiner supposed to stay on the page and load forever? Because it seem to do that on most pages when not logged in. (Being located close to the edge of the screen to the right of the page title.) Nightsky (talk) 02:05, 2 April 2021 (UTC)

I believe this is related to the SMW backend being unresponsive due to it being excessively slow per Stephane's post on discord. For reference here is Stephane's comment:
"Stephane Lo Presti — 03/31/2021 > Hey everyone, I've got a quick update following yesterday's maintenance. Our engineer discovered an odd error in the backend. It's very technical and he needs to investigate this further to really understand what's going on and create a fix. Meanwhile it may mean that the SMW data update may be running slow (?). I also asked our engineer to look into the slowness."
Also related to this bug where the page osillates.
In the meantime I've applied a CSS rule to hide it completely, though I suspect this will bug will vanish when the backend finishes processing/the bug is fixed. -Chieftain AlexUser Chieftain Alex sig.png 11:36, 2 April 2021 (UTC)
icon still appears on small screen devices (responsive design mode for mono book). Indefinitely loading on main page. 22:12, 7 April 2021 (UTC)
Actually, while annoying, would't it be better to leave it visible to be able to tell more easily if it's fixed or not? Nightsky (talk) 17:46, 8 April 2021 (UTC)
What you say makes sense, but not worth it if it causes the entire page to vibrate up and down for some users... -Chieftain AlexUser Chieftain Alex sig.png 18:25, 8 April 2021 (UTC)
For what it's worth it seems there is a POST call being made each page load that tries to perform a smwtask (run-entity-examiner) but fails to do so for permission reasons (writeapidenied). At least while not logged in, it works fine and the div with this id is empty while logged in. Nightsky (talk) 02:26, 1 June 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)

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)

1Yes 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 Database error received when searching[edit]

Searching for "Great work! Now train your essence manipulation Mastery on Jormag's minions outside the walls of the keep." in Special:Search produces a database error. See "Great+work!+Now+train+your+essence+manipulation+Mastery+on+Jormag's+minions+outside+the+walls+of+the+keep." this. Removing the quotes around the phase appears to work in this instance but the error is unexpected. Cutting out any words from the quote also appears to work. (page with this quote is Researcher Yarixx).

Reported by Adeira Tasharo on discord. -Chieftain AlexUser Chieftain Alex sig.png 16:26, 2 April 2021 (UTC)

This appears to be caused by a MySQL full-text search error that may require some database parameter tuning. I have a support case opened with AWS and will update here when I have a resolution. Justin Lloyd (talk) 12:47, 7 April 2021 (UTC)
It turns out that the MySQL parameter that needs tuning is currently not available in the set of parameters able to be tuned within AWS Aurora, but it is being worked on though with no ETA (extensive testing is needed), so unfortunately there is no fix for the exact issue at this time. Hopefully the workaround will suffice for the time being, but I will be sure to stay on top of this issue and follow up when there is a change on the AWS side. Justin Lloyd (talk) 17:25, 7 April 2021 (UTC)
The database change was made a little while ago and I did some quick testing and didn't get a database error. That said, a big enough query can potentially take long enough to timeout, resulting in a "504 Gateway Time-out" message, and that's a separate issue that I'm hoping the move to CirrusSearch will resolve. Let me know if you have any further/other issues regarding this. Justin Lloyd (talk) 17:34, 7 July 2021 (UTC)
Superb great work, marking as resolved. -Chieftain AlexUser Chieftain Alex sig.png 18:16, 7 July 2021 (UTC)
Searching for any article with "-" causes a database error. See here --BuffsEverywhere (talk) 13:42, 12 July 2021 (UTC)
This is a long-standing bug in MediaWiki. You can work around it with quotes, e.g. "-" (which doesn't return anything) but "aux-1" brings up that page and "aux-" does return results with the AUX-1 page being the main result. Justin Lloyd (talk) 14:18, 12 July 2021 (UTC)
Currently being tracked under
I have added an additional line into MediaWiki:Databaseerror-text such that will give a little clue as to the issue. -Chieftain AlexUser Chieftain Alex sig.png 17:34, 12 July 2021 (UTC)

No Link to Special:ListTransclusions missing from sidebar on every page[edit]

Previously I am virtually certain there used to be a sidebar button linking to Special:ListTransclusions with the current page name entered in the top of it. That link isn't there anymore. I guess MW changed the functionality associated with the hook.

NB: Actual special page still entirely functional. -Chieftain AlexUser Chieftain Alex sig.png 23:03, 2 April 2021 (UTC)

Deprecation notice on mw:Manual:Hooks/BaseTemplateToolbox is probably related, apparently since 2017, seems the replacement is mw:Manual:Hooks/SidebarBeforeOutput which has similar syntax. -Chieftain AlexUser Chieftain Alex sig.png 23:14, 2 April 2021 (UTC)

No Parts of menu not available on phone/phone version[edit]

When using the mobile view of wiki on my phone, many parts of the menu are missing (Community portal, Recent changes). Usually I could fix it with a page refresh or two, but now it is has been a persistent issue since the last wiki update. ~Sime 14:21, 4 April 2021 (UTC)

The way we previously implemented it got removed with MW 1.35, so I had to unfortunately remove the associated code from Mediawiki:Mobile.js. All ears if someone knows a new way to modify the menu though. -Chieftain AlexUser Chieftain Alex sig.png 14:36, 4 April 2021 (UTC)
Marking as not a bug. -Chieftain AlexUser Chieftain Alex sig.png 16:30, 7 April 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 apperently[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)

No Page forms non-loading script[edit]

Visiting the page "Special:RunQuery/Base ingredients query", i.e. and receiving an error in the console telling me the script isn't loading

Loading failed for the <script> with source “”. index.php:1:1

I personally can't reproduce this bug in browsers other than firefox, but I asked the wiki discord and other people have been able to reproduce this issue on mobile too. (May not just be firefox) -Chieftain AlexUser Chieftain Alex sig.png 20:23, 7 April 2021 (UTC)

The link just worked for me on Firefox (also on Edge, fwiw). Can you confirm it's still a problem? Justin Lloyd (talk) 10:53, 8 April 2021 (UTC)
Can confirm it occasionally happens on any query form. -Chieftain AlexUser Chieftain Alex sig.png 17:26, 17 April 2021 (UTC)

Yes User:Relyk/SMW/location tree[edit]

Well, that. It appeared a short while ago on Special:ProcessingErrorList (broken query), and can't be visited as it gives 504 timeout every time I try to look. It's not a high priority, but I'd like to see what causes it and/or fix the broken query. DJemba (talk) 10:11, 26 April 2021 (UTC)

I've noticed that too after adding the allows values to Property:Has location type. I had a short glance at it then and figured it might be "empty" because it times out, though since i didn't have a thorough look at it i'am not at all certain. I'll edit it to not time out anymore for the time being. Remains to be seen if it still shows up as error after that then. Nightsky (talk) 18:09, 26 April 2021 (UTC)
Should be good now. I'm not sure weather or not to add a further |limit=100 to the ask query that's inside of the arraymap but it's no longer on Special:ProcessingErrorList and also doesn't time out anymore now (at least for me). Nightsky (talk) 18:57, 26 April 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)

Yes SMW galleries appearing as a column[edit]

moved from Guild Wars 2 Wiki:Reporting wiki bugs#What happened to most gallery pages?

I don't know when that happened exactly, it must be recently. Now in many gallery pages Category:Item galleries by type (not all Black Lion weapon set gallery) the images are ordered in a single column, instead of at least 4-6 in a row. And are the thumbnails set be even smaller? Maybe because of a MediaWiki update?

That's not how you fulfill the purpose of galleries! 10:39, 10 June 2021 (UTC)

Just hit purge on them, it's left over from some work that happened. Dak393 (talk) 11:10, 10 June 2021 (UTC)
Well I bothered to go through and purge all the the ones in the category but there are for sure more and if you find more cases just purge the page to fix it. (Also fixing page links above) Dak393 (talk) 11:17, 10 June 2021 (UTC)
Sadly, purging with "?action=purge" at the end of any of mentioned gallery URLs and confirming the prompt with "OK", seems only to work for 10 seconds when you reload the page with your browser again and again. It doesn't matter, if it's with F5 or ctrl+F5. After that, it's back to displaying it as a single row. Even after multiple manual attempts, for instance "". 15:44, 10 June 2021 (UTC)
For years I thought this bug was to do with SMW's fancybox/JS. It might be, but the visual appearance is actually the result of a stylesheet not loading, or not loading the fragment required. If I add this css fragment the column is restored. I'll look into this a bit further and see if I can figure out if there are other CSS rules not loading or if its just this bit. If it's just this section (as in exactly my sandbox) then I can paste this into the Common.css rules as a workaround. -Chieftain AlexUser Chieftain Alex sig.png 17:00, 10 June 2021 (UTC)
edit, i've tracked down the resource url and amended the link above.
Normally mediawiki only loads modules if it detects it needs them based on the wikitext... I wonder if SMW parses it too late and misses the opportunity to add it into the module queue to load? Not sure why it would work 100% of the time on page preview though.
I've identified an identical github issue for this bug here. Considering its quite an old bug, I will implement the workaround so we don't see this bug in the future for a while. -Chieftain AlexUser Chieftain Alex sig.png 17:16, 10 June 2021 (UTC)
Workaround now implemented until a solution for the extension is implemented. -Chieftain AlexUser Chieftain Alex sig.png 17:40, 10 June 2021 (UTC)
Potentially don't need to worry about this bug any more since we've installed extension:mediaviewer (which is incompatible with SMW galleries, requiring SMW gallery removal), however I'll leave the patch in for a bit (maybe 1 month?) until we're happy all occurrences of SMW galleries are gone. -Chieftain AlexUser Chieftain Alex sig.png 17:51, 24 June 2021 (UTC)
The mw:Extension:MultimediaViewer is actually "compatible" with the smw result format = gallery, just the parameter "overlay = yes" isn't, as clicking on a image thumbnail opens both, the MultimediaViewer image overlay and the fancy format = gallery overlay.
However, the format = gallery has three problems:
  1. The problem specified in this topic: after an edit the gallery may be compressed into one column only, fixed by Alex with some CSS.
  2. That's however not all, it also displays the text Property:Has caption, which is set to [[<page name>|<canonical name>]], as exactly this, i.e. it displays it as raw wiki code and doesn't parse it. This isn't fixed yet and needs a purge every time.
  3. The problem specified in the next topic. A single smw format = gallery query isn't able to open the image with the MultimediaViewer, it needs an additional dummy image.
But it's quite tricky to create a gallery by using custom format since:
  1. format = plainlist with an own result format introduces [[SMW::off]]/[[SMW::on]] tags which must be removed when wrapping it in a {{#tag:gallery|<query>}}.
  2. format = array doesn't have the [[SMW::off]]/[[SMW::on]] problem, but adding a line break separator is kinda hard. The best one I found so far is: propsep = {{!}} and sep = <nowiki/>\n: where \n inserts an actual line break, exploiting the fact that the gallery tag is able to parse :File:<file name>.png.
Given these bugs, I'm still tempted to replace the format = gallery with a plain query format (although the plain queries are tricky) wrapping it in gallery tags.
Also, I have replaced all mainspace format = gallery occurrences with template calls - the remaining templates are now the following:
--Tolkyria (talk) 18:59, 24 June 2021 (UTC)

Yes Extension:Multimediaviewer with SMW format = gallery[edit]

When using mw:Extension:MultimediaViewer together with smw:Help:Gallery format there's some wierd behaviour. The "overlay = yes" incompatibility is already documented there in the help (as those are stacking), so I'm trying to remove those. In this process, I noticed that sometimes the MultimediaViewer is working and sometimes not, for example see Gallery of mount skins (working) and Gallery of Raptor skins (not working). The only difference, both are using exactly the same smw query with "format = gallery", is that the page Gallery of mount skins calls the query several times and Gallery of Raptor skins only once. When inspecting with the browser, the image thumbnails on the first page show an event while the second page don't. On pages with one query only, if we add a simple icon before or after, e.g. [[File:Skill.png]] or even with deactivated link [[File:Skill.png|link=]] (i.e. it doesn't show up in the MultimediaViewer), the MultimediaViewer suddenly works; without it doesn't.

Note that the SMW format = gallery is a historical remnant, because up to now it was then nicest way to display images; not sure if we should replace it with a custom format just using <gallery> tags.

Summary: Quite wierd, when using only one smw query with format = gallery as content on a page, it fails to activate the MultimediaViewer properly. --Tolkyria (talk) 13:40, 24 June 2021 (UTC)

Okay, I should have checked on the smw sandbox wiki first, same behaviour there, see here: one query only and one query and one image call. I guess this is a general problem then, it seems like that there can't be done much at the wiki backend then (@Justin), but we (the editors) have to avoid using single gallery queries instead. --Tolkyria (talk) 14:07, 24 June 2021 (UTC)
It's actually not that trivial to create a smw gallery query without the format = gallery but with e.g. format = plainlist/array, unless I'm missing something completely. The easiest fix would be to add the dummy <div style="display:none">[[File:Skill.png|link=]]</div>. --Tolkyria (talk) 15:59, 24 June 2021 (UTC)
If we template the dummy fix bit we could remove it later fairly easily. -Chieftain AlexUser Chieftain Alex sig.png 17:32, 24 June 2021 (UTC)
Uploaded File:Gallery dummy.png (1px transparent) and added it to the gallery templates/turned mainspace queries into template calls (mostly Template:Gallery). If there are no objections, I'll mark this as solved. --Tolkyria (talk) 18:07, 24 June 2021 (UTC)

Database error[edit]

In the last hour I have received the following message a few times. (Also reported by two on discord.)

My error a few minutes ago (page "Pact Fleet Torch"):

Database error
A database query error has occurred. This may indicate a bug in the software.
[b1f577ece21966fca2e53c2f] 2021-07-20 13:23:30: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

(earliest other reported)

[e58cae12cc2d32cb2430af8e] 2021-07-20 12:48:33: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

(second report, page "Stalker Visage")

[7a4d03133449ba65a5293a21] 2021-07-20 13:02:52: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

Kvothe (talk) 13:35, 20 July 2021 (UTC)

This has happened a few times now due to occasional heavy database loads are causing the wiki to fail over to the secondary database node, which is read-only. (I believe the heavy loads are due to the occasional heavy text search that can generate a large database query result.) I'm working on a solution to this issue, part of which is the CirrusSearch implementation project that is in its early stages. Justin Lloyd (talk) 13:39, 20 July 2021 (UTC)

Page Loading Issues[edit]

Is there something wrong with the Wiki? Last few days pages are pretty slow loading, but today it is so much worse. Lots of 503 (Backend Fetch Failure) (Got one on this edit) errors, and it takes between 30 seconds and 2 minutes to load a page or any changes. I suppose it could be me, but I'm not having any issues with the Forum or any other Guild Wars 2 sites. Inculpatus cedo (talk) 17:57, 4 August 2021 (UTC)

This is a known backend issue that we are working on. Justin Lloyd (talk) 18:08, 4 August 2021 (UTC)
I am still investigating this, the brief maintenance was a necessary step. Justin Lloyd (talk) 19:31, 4 August 2021 (UTC)
I see there are several posts about this issue on the forums. As well as issues with the game. No idea if the Wiki and the game share anything. I hope it is resolved shortly, as it surely discourages using the Wiki. (Oh, and trying to purge a page gives a 'Semantic Wiki tried to purge and failed' error.) Inculpatus cedo (talk) 19:56, 4 August 2021 (UTC)