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. https://wiki.guildwars2.com/api.php?action=opensearch&format=json&formatversion=2&search=Template%3ASTD&namespace=0%7C1%7C2%7C3%7C4%7C5%7C6%7C7%7C8%7C9%7C10%7C11%7C12%7C13%7C14%7C15%7C102%7C103%7C106%7C107%7C108%7C109%7C200%7C201%7C202%7C203%7C274%7C275&limit=10 - 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: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TitleKey/+/497086/ , https://github.com/MabiWorld/TitleKey/commit/35d6b56469455bd3f1c2e6849a32555f676ca6f3 - 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: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TitleKey/+/382968/
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. 157.131.222.238 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)

No Extension:Widget scripts breaking with Extension:MobileFrontend[edit]

Since there are two distinctly different errors here, I'm splitting them up. This section is for any Mobile view, where Widgets display their source code on the page, and partially run their scripts then throw errors into the console.

Something is breaking Widget:Event timer when viewed using the mobile theme - Example link in mobile mode - appearance. It appears that the widget is loaded so far, and then gives up and displays the source instead which is very weird indeed, especially considering that it apparently works ok in the template namespace (Template:Event timer) but fails in the main namespace (Event timers). -Chieftain AlexUser Chieftain Alex sig.png 23:26, 26 March 2020 (UTC)

This bug is originating from the JS function drawRow used in index.php (approx. line 940) on the Widget:Event timer page. The mobile version and the desktop version escape the div's correctly, while the mobile version does not for some reason. The line looks like the following on the desktop page and on the Template:Event timer page:
var barcontainer = $('<div class="event-bar-container ' + metaKey +'" data-abbr="' + metaKey + '"></div>');
In the mobile version, it looks like this:
var barcontainer = $('<div class="event-bar-container ' + metaKey +'" data-abbr="' + metaKey + '"></script></p></div></div>');
I am not a web dev, but it seems like JS sees the </script> tag and freaks a little bit. I am not sure if this is only occurring within the context of the page or if the additional tags are required on the mobile version, but the Template page itself renders correctly on mobile because it uses the top version. I also have no idea how to edit on scripts themselves, so this is all the information I can really offer, and cannot test a fix within the context of the mobile page.
This could be occurring due to auto generation for the index.php page for the Event timers on mobile or some larger issue. Alternatively, I could be completely wrong (still not a web dev) and this could not in fact be the issue. Hope this puts you on the correct path. Caddox (talk) 17:46, 28 March 2020 (UTC)
Thanks Caddox. The actual file that widget_editors* (special user group given to people - limited edit rights due to potential to mess up other people's pcs) can modify for this is located in the source of Widget:Event timer.
Similar error also occurs using Mobile view at Helpful Hero#Map which uses Widget:World map. This time the line
$('#worldmap').append('<div id="worldmapcoords" style="position:absolute; bottom:5px; left:5px; display:block; background-color:rgba(255,255,255,0.7); font-family:consolas; z-index:900;"></div>');
is malformed into:
$('#worldmap').append('<div id="worldmapcoords" style="position:absolute; bottom:5px; left:5px; display:block; background-color:rgba(255,255,255,0.7); font-family:consolas; z-index:900;"></script></div></div>');
again it seems to be breaking where I'm inserting a div node with jquery. Need more evidence to figure this out. -Chieftain AlexUser Chieftain Alex sig.png 19:26, 28 March 2020 (UTC)
Evidence you say? I found 10 separate cases by going to each widget listed on the Category:Widgets a page (which is lower than I expected to find, so that's a plus) and 9 of them were div related. Only one was a malformed p. All of them contained malformed </script> tags. Interestingly, there is a getCoin function that is reused multiple times and fails consistently. This function can be found on Widget:Tp_total_calculate. Another (good) thing to note is that wrapper templates sometimes do not propagate the failure. Again, I am no expert, but it seems some parser is internally getting confused when attempting to auto-generate the index.php file, and deciding to add a </script> tag and finishing the HTML structure surrounding it, almost like it thinks the script is over early.
For reference, the following mobile pages all render incorrectly:
Widget:Tp_total_calculate, Widget:Wikify_patch_notes, Widget:Rollback_robot, Widget:Gallery (Functions correctly through the template, but not the widget), Widget:Fullscreen_images (Functions correctly through the template, but not the widget) Widget:Filter_table (Three separate failures here. p malformation is in here. Do not know if the template fixes it.), Editing_robot, Wintersday_Gift/research, Widget:Achievement_table, Widget:Account_inventories
Let me know if you need more evidence. I'm invested in this now! Caddox (talk) 03:46, 29 March 2020 (UTC)
I think the parser for MobileFrontend is a bunch of crap. Having said that, splitting the script from the widget's main page (e.g. Widget:Achievement table) onto a subpage (e.g. [[Widget:Achievement table/script.js]]) seems to work. I don't like it at all, but if it works, it's probably worth doing for the high traffic widgets. -Chieftain AlexUser Chieftain Alex sig.png 10:41, 29 March 2020 (UTC)
I agree on the first sentence. It's also broken on Map#Interactive world map. I agree that it looks like something sees the </div> tag inside the script and trims everything before it with an ellipsis and adds a closing tag, which causes it to dump the rest of the script onto the page. It looks like it knows it's inside a script tag because it seems to try to close that properly, but it doesn't know not to trim while inside a script tag... --zeeZUser ZeeZ Sig.png (talk) 17:10, 26 May 2020 (UTC)
JavaScript appears as text on mobile view
Bug report widget javascript as text.jpg

On mobile view javascript appears as content of the page.

For example on Silence (story) it appears before the NPCs title.

On desktop view it works fine.

Exactly the same as #Extension:Widget scripts breaking with Extension:MobileFrontend above. -Chieftain AlexUser Chieftain Alex sig.png 21:48, 29 April 2020 (UTC)

Potential solution[edit]

(Reset indent) So I have found https://phabricator.wikimedia.org/T168567 which basically explains why longer widgets work fine on mobile in the "Template" namespace but not the Widget or Main namespaces. There is an array in extension.json of MobileFrontend called $MFMobileFormatterNamespaceBlacklist which blacklists the Template (and Special) namespaces. I'm not sure if we can over-ride it from localSettings.php or if we'd need to modify extension.json directly. Possible solutions:
(1) Add the option to localSettings.php in a way that works - idk how to do this.
(2) A potential option would be to directly add (i.e. hack extension.json) the Article (ns0) and User (ns2) namespaces to this array, which would make all widgets work everywhere of note - this is easy and proven to work.
(3) Fix the problem at the source - In terms of where that variable goes to, it is used in includes\MobileFrontendHooks.php to determine whether "domParse(" is used or not - that function is in includes/ExtMobileFrontend.php. In an ideal world, we'd modify that function to respect widget code and not attempt to parse it further. I haven't spent a great deal of time trying to analyse why it breaks yet.
-Chieftain AlexUser Chieftain Alex sig.png 23:23, 7 April 2020 (UTC)
Option 2 isn't required since I've figured out what the syntax is for Option 1. Adding the following to LocalSettings.php would prevent the mobile formatter from destroying the widget outputs.
$wgMFMobileFormatterNamespaceBlacklist = [
	NS_SPECIAL, # -1
	NS_MAIN, # 0
	NS_USER, # 2
	NS_TEMPLATE, # 10
	274 # Can't use NS_WIDGET because its defined by an extension
];
It would also however prevent sections from being collapsible in the above identified namespaces. Still worth pursuing Option 3 to see if there is a better fix. -Chieftain AlexUser Chieftain Alex sig.png 17:28, 8 April 2020 (UTC)
Widget:Jquery test - test page if we're doing any testing of extensions. -Chieftain AlexUser Chieftain Alex sig.png 19:37, 8 April 2020 (UTC)
I suppose the real questions are (1) should the combination of Widgets and MobileFrontend break on something as simple as adding a div with jquery, and (2) should all the widgets just be rewritten without jquery anyway. -Chieftain AlexUser Chieftain Alex sig.png 19:48, 8 April 2020 (UTC)
Regarding 2; without html tags inside of script tags would suffice. I'll see if i can do that some time soon. Nightsky (talk) 01:39, 26 September 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)