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, 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 Newly created user accounts don't appear in Special:RecentChanges[edit]

Basically mw:Extension:RecentChangesLogFilter doesn't work properly due to the changes to the mw hooks. same issue. I suggest we disable the extension until it is rewritten for 1.34 for the moment.

For reference, about 20 accounts are being created per day versus 350 edits so the proportion is low enough to not need the filter active atm. -Chieftain AlexUser Chieftain Alex sig.png 20:08, 31 March 2020 (UTC)

I’m aware of this and on it. You can use the new user log for now. poke | talk 20:32, 31 March 2020 (UTC)
I've temporarily updated MediaWiki:Recentchangestext to link to the special page you suggested, I still think this needs fixing though. -Chieftain AlexUser Chieftain Alex sig.png 19:45, 28 September 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)

No 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)

Supposed crashes with /wiki command in-game reported on GW2 official forum[edit]

See following links

--Life Infusion «T» 21:05, 4 December 2020 (UTC)

Is this an interaction between gw2 and chrome? Are there any reports on browsers other than Chrome? -Chieftain AlexUser Chieftain Alex sig.png 21:10, 4 December 2020 (UTC)