This page is an archive. The contents have been moved from another page for reference purposes only, and should be preserved in their current form. Discussion or voting on this page is not current. Any additions you make will probably not be read.
The current version of this page can be found at Guild Wars 2 Wiki:Reporting wiki bugs.

Not actual bugs

Infobox error

Infoboxes appear to override coordinates when map1-5 or map1-5-text are used, showing only the linked images and not a map for the coordinates. Unsure if this is related to the wiki upgrade or not. Sunlion (talk) 06:59, 27 March 2020 (UTC)

That's just how the infoboxes are coded. Previously we've set coordinates for certain pages, then decided that we'd rather show the map screenshot images - particularly if the NPC is within a cave system etc. If you think this is stupid, can you please raise a new section on the respective infobox talkpage and we'll discuss it. -Chieftain Alex

07:04, 27 March 2020 (UTC)

SMW query further results

The template {{skill list}} displays all skills that have a certain skill fact (e.g. Might or Bleeding) which are stored in a skill fact. So I'm asking for the subobjects and sort this based on the skill's 1) profession, 2) specialiation, 3) weapon type/skill type, 4) their page name (well actually, we don't have a page name property, so I'm sorting this by its subobjects which somehow sufficient). Because I'm asking for skill facts (reminder: subobjects), I have to use chain property to get to the skill properties, e.g. for weapons I have the following sort parameter:

sort = Is for skill.Has profession sort order, Is for skill.Has specialization sort order, Is for skill.Has weapon type sort order, Is for skill.Has subobject

But here is the problem, before the March 2020 wiki upgrade all skills have been displayed but now afterwards the sort is somehow too expensive and reduces the displayed results to ~50-70 (although the limit is set to 500), the rest can be accessed with further results.

Any ideas, do I have to adjust the properties or can there anything be done at the backend?

P.S. the sort = [..], Is for skill.Has subobject is required to group skills with multiple skill facts that do the same, furthermore simply using , (i.e. sorting by result name) is not possible because SMW (intended or not) sorts the sort properties by hierachy, first unchained, then level 1 chained, etc... Hence, internally it would be handled in the following way, completely ruining the sort idea:

sort = ,Is for skill.Has profession sort order, Is for skill.Has specialization sort order, Is for skill.Has weapon type sort order

--Tolkyria (talk) 10:41, 29 March 2020 (UTC)

I forgot to add some examples: Bleeding#Weapon skills that apply bleeding, Vulnerability#Weapon skills that apply vulnerability (see also [[:Category:Pages with further semantic mediawiki query results]], please note that this is temporary redlink category) --Tolkyria (talk) 11:46, 29 March 2020 (UTC)

Edit, again, moving from Unsolved to Not a bug: The problem seems to be my sorting hack using sort = [..], Is for skill.Has subobject with in general 5-10 or even more subobjects causing the smw sort to explode. Furthermore, I don't expect that this will happen anywhere else, hence: Not a bug.

However, am I allowed to create the unfortunately obivious and elsewhere redudant property: Has page name and set it in {{Skill infobox}} and {{Trait infobox}} to fix the skill list and display all skills of a certain context as a whole? Note that the property Has canonical name is not enough, multiple skills with several identical skill facts may have the same canonical name, and hence grouping them together by page name is not possible. --Tolkyria (talk) 12:24, 29 March 2020 (UTC)

Well, impressive how I failed to see the overall picture, I literally wrote everything down: "5-10 subobjects" & "~50-70 displayed results" & "limit is set to 500".

Combining ~7 subobjects x ~70 displayed results = 490 ~ 500 = limit. Previously, using multivalued properties in the smw sort have been treated as one (maybe the first or all together, idk exactly), but now each property value counts towards the limit. --Tolkyria (talk) 14:14, 29 March 2020 (UTC)

SVG images do not respect EM sizes

See below:

[[File:Info logo.svg]]
----
[[File:Info logo.svg|15px]]
[[File:Info logo.svg|30px]]
[[File:Info logo.svg|45px]]
[[File:Info logo.svg|120px]]
----
[[File:Info logo.svg|1em]]
[[File:Info logo.svg|2em]]
[[File:Info logo.svg|3em]]
[[File:Info logo.svg|8em]]

-Chieftain Alex 23:27, 26 March 2020 (UTC)

Marking as not a bug. Just need to specify the image sizes in pixels when using SVG - only really a problem for various boilerplate templates like {{notice}}. -Chieftain Alex

20:11, 31 March 2020 (UTC)

High ratio of Outdated entities to Entities on Special:Statistics

We're currently at 4.2M/5.9M (71% outdated). Per this help topic the outdated entries can be removed with the "disposeOutdatedEntities.php" script.

A comparable wiki has been linked as https://runescape.wiki/w/Special:Statistics - that wiki is on about 4% which seems more normal. -Chieftain Alex 00:02, 27 March 2020 (UTC)

There is a deletion task now running in the background, it will be running for several days (possibly a week to finish its first run). -Chieftain Alex

20:20, 31 March 2020 (UTC)

We've been plotting the number of outdated entities (we assume the script is still running) and it's dropped to 33% since the 31st. I'm going to mark this as not a bug since ArenaNet stated they will look at doing a regular sweep after this mega-one-time-job is complete. -Chieftain Alex

12:27, 8 April 2020 (UTC)

Tables with a caption have a different color

Examples:

Month	Gizmo
January	Champion's Burning Swords
February	Champion's Dragon

Rotation of the First Place Gizmos
Month	Gizmo
January	Champion's Burning Swords
February	Champion's Dragon

—The preceding unsigned comment was added by BuffsEverywhere (talk • contribs) at 06:54, 8 April 2020‎ (UTC).

This isn't a new issue, it's been this way for 7 years. Apply class="heading" to the primary row in the second table would have the same effect. e.g.

Rotation of the First Place Gizmos
Month	Gizmo
January	Champion's Burning Swords
February	Champion's Dragon

-Chieftain Alex

07:16, 8 April 2020 (UTC)

Thanks. However, I found that heading class doesn't work on sortable tables.

Rotation of the First Place Gizmos
Month	Gizmo
January	Champion's Burning Swords
February	Champion's Dragon

--BuffsEverywhere (talk) 20:36, 14 April 2020 (UTC)

API map tiles not displaying

To confirm this is not a wiki-only bug, the HTTPS certificate has expired. Not After 4/12/2020, 12:51:50 AM (British Summer Time). This will mean all non-local map tiles will appear blank for everyone. -Chieftain Alex 00:04, 12 April 2020 (UTC)

HTTPS certificate expiry dates have been updated according to https://discordapp.com/channels/384735285197537290/384735523521953792 -Chieftain Alex

11:57, 13 April 2020 (UTC)

Scrolling thru articles featuring maps

Each time I scroll with mouse wheel through any article containing map I'm getting stuck on map itself - cursor gets captured within the embedded part and starts to zoom in/zoom out map. Would be great if articles containing maps would have maps sections collapsed by default - if that's possible of course. It's not nearly a bug but annoyance I guess but I wish you consider fixing it. --178.43.140.17 12:13, 7 April 2020 (UTC)

I don't know about this one. I guess you're using the scroll wheel in the middle of the page? Would moving the mouse to either side of the map not be sufficient?

I would personally rather that the maps are visible when the page loads. -Chieftain Alex

17:55, 7 April 2020 (UTC)

Not really, I'd have to set it each time in sidebar which isn't "user friendly" way to browse wiki nor any page, I guess. I'm using 23' monitor, my browser window is quite big already and yet I'm still having this issue which wasn't a thing before map sections become so large. If not collapsible section then at least maybe making widget smaller by default and then with special button enlarging it and saving the size preference in cookies? --178.43.114.78 14:15, 10 April 2020 (UTC)

Wrong game link for Latte Dye

The game link for Latte Dye is the one for Chalk Dye. -73.15.89.240 22:43, 19 April 2020 (UTC)

Did you type it out by hand instead of copy/pasting it?

[&AgGITwAA] - Chalk (id 20360) --> has an uppercase "I" for India
[&AgGlTwAA] - Latte (id 20389) --> has a lowercase "l" for London

Marking as not a bug as I suspect this is a manual data entry user error. -Chieftain Alex

00:36, 20 April 2020 (UTC)

"Grothmar Valley Achievements" Missing data/requirements/information

It seems that, despite the "age" of this region, there is NO information available regarding [[Grothmar Skyscale Challenge]] (Bronze, Silver, Gold) to assist users in attaining these achievements. Undouble (talk) 16:37, 20 April 2020 (UTC)

How is that remotely a bug lol? That's just people not documenting stuff... actually it would help if you looked at the correct article.

The associated article is Grothmar Valley Skyscale Trial if you want to modify it. The tables indicate the time requirements to complete it. It's a bit tricky that one, but if you can find the 15 you'll be ok. -Chieftain Alex

16:43, 20 April 2020 (UTC)

Outstanding bug in daily fractal achievement

"Achievement name missing from API (ID #3213)" is listed for uncat (62) when it is a recommended fractal. Specifically under the {{Daily achievements}} call --Life Infusion «T» 21:14, 24 November 2020 (UTC)

To expand on this, I believe it might be because the "achievement was removed from the game" per the API, at least according to GW2 treasures. A workaround might be needed. --Life Infusion «T» 21:17, 24 November 2020 (UTC)

https://api.guildwars2.com/v2/achievements?wiki=1&lang=en&ids=3213 it's because as the display name suggests, it isn't in the API. I'm loathe to hard code the achievement lookups. -Chieftain Alex

21:20, 24 November 2020 (UTC)

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

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 Alex

21:10, 4 December 2020 (UTC)

Closing as no follow-up information, and likely beyond our control. -Chieftain Alex

19:57, 17 March 2021 (UTC)

Fixed bugs

Achievement Box broken

The achievement box on pages like this don't seem to show their content correctly and instead only render as a blue square: https://wiki.guildwars2.com/wiki/Cin_Business. (sorry if I did this report wrong, first time "posting") -46.84.173.218 21:11, 25 March 2020 (UTC)

Fixed. Due to the March 2020 wiki upgrade all smw:Semantic Mediawiki properties have been purged. Hitting the refresh button on the corresponding achievement summary page and then on the page itself should fix this problem; or simply waiting until the wiki refreshes itself. --Tolkyria (talk) 21:54, 25 March 2020 (UTC)

Creature Nav template and Drops table templates are broken

Example: Icebrood Wolf. Simek (talk) 21:44, 25 March 2020 (UTC)

Fixed. Due to the March 2020 wiki upgrade all smw:Semantic Mediawiki properties have been purged. Hitting the refresh button twice, first to build the properties via the infobox and second to ask and display the properties in nav, should fix this problem. Drop table uses the level range from the infobox on default, with this procedure this should be fixed too. --Tolkyria (talk) 22:02, 25 March 2020 (UTC)

Map Objective templates

I haven't gone in and looked at the coding of the template itself, but it seems that the map objective template is borked, which has borked all the location pages that use it, as well as the waypoint templates that reference the map objectives on said location pages. For example, even the Template:Waypoint page's referenced examples no longer work properly; they refer the editor to check the area page to see if the waypoint has been added. Checking the area page brings up what look to be properly formatted map objectives for those waypoints, but they're all tagged for improper usage. That tag says they have no location property set, but checking the editor shows they not only have it set but it's set properly in regards to the required parameters for that template. I have no clue what's being missed in translation between all the templates, but I'm noting it here rather than trying to unbreak it. -Pbandfluff (talk) 21:50, 25 March 2020 (UTC)

Area pages will need null editing twice (once to erase the old properties & recalculate the infobox properties, then a second time to calculate the properties for the subobject Map objectives template [which looks up properties from the parent page]). I've checked this works for

Durmand Priory Waypoint — . -Chieftain Alex

22:05, 25 March 2020 (UTC)

Heart template

The renown heart template used on enemy pages appears to be broken, not showing links or levels correctly. Example: Branded Rock Dog. Sunlion (talk) 22:07, 25 March 2020 (UTC)

The "Has canonical name" property of each heart page has not been calculated yet. Once it does get processed, each page calling the heart template will need to be refreshed too. (Notice how Help Sentinels instigate fights between ghosts and the Branded worked fine on that page?) -Chieftain Alex

22:11, 25 March 2020 (UTC)

Vendor List template

Template:Vendor list doesn't function correctly, not showing if an item is sold or not and saying "No results for vendor list. If the item is sold at a vendor, it may not have been added to the vendor yet." no matter if it is sold or not. Sunlion (talk) 22:12, 25 March 2020 (UTC)

This appears to be the same with templates such as Template:Contained in. Sunlion (talk) 22:15, 25 March 2020 (UTC)

Due to the March 2020 wiki upgrade all smw:Semantic Mediawiki properties have been deleted. The pages just needs to be purged, you can use the refresh button on the individual vendor/content pages (of course it's not obivious at all which those are, try "What links here" in the left side bar), see mw:Manual:Purge. The wiki runs through all pages and purges them automatically, however this may take some time until all the pages have been run through. --Tolkyria (talk) 01:18, 26 March 2020 (UTC)

Event timers randomly breaks on Firefox

Sometimes while loading https://wiki.guildwars2.com/wiki/Event_timers it completely breaks the page, stays on a loading loop and I can't click on anything, it even prevents Firefox from stopping the load. Even if it loads correct correctly try refreshing the page until you can reproduce it on Firefox. —The preceding unsigned comment was added by 179.53.28.124 (talk) at 22:43, 25 March 2020‎ (UTC).

I get the same bug. Idk what the fix is yet. -Chieftain Alex

22:49, 25 March 2020 (UTC)

Ok I think I've sorted it. I'll leave this at "not solved" for the moment - give me an update tomorrow and see if you can still get it to bug out for you. -Chieftain Alex

23:18, 25 March 2020 (UTC)

Used same fix on all other widgets, yet to see any issues. -Chieftain Alex

00:30, 26 March 2020 (UTC)

Yeah it seems to be fixed now. Thank you! —The preceding unsigned comment was added by 179.53.28.124 (talk) at 03:53, 26 March 2020‎ (UTC).

Mobile view bug

Recording that another fix has also been applied since the newline character doesn't work in mobileview, considered as illegal whitespace. -Chieftain Alex 22:41, 26 March 2020 (UTC)

Drop Research charts are broken

Example: Exceptional Ingredients Pouch Simek (talk) 23:21, 25 March 2020 (UTC)

Fixed. Due to the March 2020 wiki upgrade all smw:Semantic Mediawiki properties have been purged. Hitting the refresh button on the corresponding drop table summary page and then on the page itself should fix this problem; or simply waiting until the wiki refreshes itself. --Chieftain Alex

23:29, 25 March 2020 (UTC)

Broken event disambig template

Template:Event disambig is severely broken, showing up as numbers and also linking to the Swords page. Example: Defeat the dragon minions before they absorb too much ley-line magic. Sunlion (talk) 01:04, 26 March 2020 (UTC)

Fixed. --Tolkyria (talk) 01:13, 26 March 2020 (UTC)

Account creation fails and displays an Internal error warning

Attempting to create an account throws an internal error warning such as:

[aba4907ead6f7dafa901afc1] 2020-03-26 01:10:28: Fatal exception of type "Error"

-Chieftain Alex 01:12, 26 March 2020 (UTC)

This should be fixed now. Justin Lloyd (talk) 13:22, 26 March 2020 (UTC)

Nice one. -Chieftain Alex

21:20, 26 March 2020 (UTC)

List of Runes broken

https://wiki.guildwars2.com/wiki/Rune displaying only "Superior Rune of Speed". -216.121.185.139 00:56, 26 March 2020 (UTC)

This is the same SMW data issue as above. The source pages all need to recalculate. Atm i can see quite a few runes on there (i.e. its calculated some since your report last night). -Chieftain Alex

07:27, 26 March 2020 (UTC)

Galleries not working

All of the Galleries listed in this page below are not working(showing images and item titles) as intended:

Category:Item galleries by type

Other Page(s) that include galleries that does/do not work(s):

List of non-set armor pieces
[[Gallery of weapon skins]]
all outfit galleries.

other Page(s) that include galleries that however work(s):

note: all cultural and armor skin pages, and individual outfit pages are working. Leshie Leshie (talk) 05:24, 26 March 2020 (UTC)

This is the same SMW data issue as above. The source pages all need to recalculate. -Chieftain Alex

07:27, 26 March 2020 (UTC)

Searching broken

Using /wiki [item] in game to run a search query on the wiki returns no results - searching based on chat code doesn't work any more. --Atrophied.8725 (talk) 06:04, 26 March 2020 (UTC)

This depends on the item. For some items which have already had their SMW data recalculated, the search function works fine. Try /wiki [Black Lion Chest] chatlink - works fine. For some, the data needs to refresh first before it'll return the correct results. -Chieftain Alex

07:27, 26 March 2020 (UTC)

Waypoint template

Am seeing "nonexistent waypoint" errors when (as far as I can tell) they do exist. Examples found at Elon Riverlands and Flowers for Jimoh. Nirushuni (talk) 09:06, 26 March 2020 (UTC)

Fixed. Due to the March 2020 wiki upgrade all smw:Semantic Mediawiki properties have been deleted. The wiki runs through all pages and purges them to readd the properties again. Hitting the "Refresh" button (on the top bar, probably hitting it twice), 1) on the area page where the waypoint is located (search the waypoing in the search window in the left bar) and 2) on the page where the waypoint is used, should fix this problem. --Tolkyria (talk) 10:41, 26 March 2020 (UTC)

I've edited the waypoint template to redirect to the area page if the redirect exists and the waypoint subobject cannot be found. --BuffsEverywhere (talk) 13:57, 26 March 2020 (UTC)

Pet skills data is lacking

Only normal F2 pet skills are visible. Other pet skills such as SB merging skills and pet passive skills are missing.

Fixed. Due to the March 2020 wiki upgrade all smw:Semantic Mediawiki properties have been deleted. The wiki runs through all pages and purges them to readd the properties again. Hitting the "Refresh" button twice (on the top bar), 1) to add the properties via the infobox and 2) to load the pet family based on the infobox, should fix this problem. --Tolkyria (talk) 10:41, 26 March 2020 (UTC)

Internal Error occuring on some wiki pages

These are the page(s) so far I've found.

Key farming

—The preceding unsigned comment was added by SaiyanOfDarkness (talk) at 10:49, 26 March 2020 (UTC).

Fixed. --Tolkyria (talk) 11:19, 26 March 2020 (UTC)

Run query: Base ingredients not always working

The Run query: Base ingredients does not always show the ingredients. For example, when choosing the weaponsmith discipline for Spark Experiment, the box is rendered, but no base ingredients are listed. There is only 1 ID in the box, this is not the issue. —The preceding unsigned comment was added by 84.82.58.191 (talk) at 10:55, 26 March 2020 (UTC).

One or more ingredients doesn't have been purge yet, hence they are missing their crucial properties. Going through all the ingredients and hitting the "Refresh" button on the top twice should fix the problem of an empty table.

However, the Template:Recipe "Show base ingredients" links does not load the table automatically anymore, only after clicking "List constituent ingredients" it works. The Special/RunQuery link needs to be adjusted. --Tolkyria (talk) 11:39, 26 March 2020 (UTC)

The URL syntax has changed per this edit of the documentation. The solution is therefore to modify any templates linking to Special:RunQuery with &wpRunQuery=true to &_run -Chieftain Alex

21:07, 26 March 2020 (UTC)

Gathered From template has some issues

Refresh of page or template page won't help. Links are still broken. Example: Ruined Log Simek (talk) 11:54, 26 March 2020 (UTC)

It seems that you need to refresh every single node page, and only then the page where Gathered From template is used. Simek (talk) 12:09, 26 March 2020 (UTC)

Exactly, refreshing or simply waiting solves this issue. One can use Special:WhatLinksHere in the left bar to probably find these pages.

Detailed explanation why it behaves this way: with the help of smw:Semantic Mediawiki, the gathering pages use the template {{gather}} which sets the property [[Property:Gives resource|Gives resource]]. E.g. Mithril Ore (node) (see Special:Browse/:Mithril Ore (node)) gives the resource "Mithril Ore". Hence on the page Mithril Ore we are able to ask for all pages that gives the resource "Mithril Ore". Due to the March 2020 wiki upgrade all properties have been deleted and the wiki is running through all pages and setting the properties again (or you can manually purge them by hitting the refresh button).

Furthermore, almost all lists of pages somehow use the format [[<page name>|<canoncial name>]], hence e.g. [[Mithril Ore (node)|]] means that the page Mithril Ore (node) has no property Has canonical name (here: Mithril Ore, i.e. the ingame name) set yet, again refreshing the page solves this issue. I hope this is somehow understandable. --Tolkyria (talk) 13:12, 26 March 2020 (UTC)

No TP prices

Minstrel's Armor Recipe Book doesn't show any prices for the trading post. -37.201.7.222 12:52, 26 March 2020 (UTC)

Just a SMW cache issue - all of the related pages have since had their caches refreshed (you can do so for each linked page in the table by clicking on the "refresh" tab at the top of the page). Refreshing "Minstrel's Armor Recipe Book" has then fixed the lookup of the item ids for each linked page, allowing the JS to calculate the price with the API. Therefore no bug currently present on this page anymore. -Chieftain Alex

21:09, 26 March 2020 (UTC)

The Release infobox template doesn't format images properly anymore

Link. They were right aligned before. It doesn't seem to acknowledge the right anymore though. Nightsky (talk) 17:20, 26 March 2020 (UTC)

Fixed. --Tolkyria (talk) 17:39, 26 March 2020 (UTC)

Expression error: Unexpected > operator on Treasure Hunter

Under crafted items.

Can't see any errors on the page so I assume its a cache bug, fixed by refreshing the page like most other bug reports here. -Chieftain Alex

21:20, 26 March 2020 (UTC)

Redirecting to other Wikis

If you're using the ingame wiki search, the automatic redirecting to the other language wikis isn't working.--79.199.100.24 09:08, 26 March 2020 (UTC)

Can confirm this is broken, currently investigating to try and figure out if this is a javascript migration issue, new behaviour or a gw-client change (again). -Chieftain Alex

21:28, 26 March 2020 (UTC)

I believe this is now fixed - the html node got renamed. Let me know if this is still broken (or equally if you want to confirm the fix works!)

My only slight thought is what if the interwikiredirect loads more slowly than the chatlinksearch - if it does then there's a chance the EN wiki will redirect to the matching item before considering whether its an interwiki prefix. -Chieftain Alex

22:07, 26 March 2020 (UTC)

Incomplete NPC members list

Not sure what the finer details are but most NPC members/types list are missing a bunch of entries. See Centaur for an obvious example. 70.82.113.198 06:10, 28 March 2020 (UTC)

Yeah the pages using that template will need refreshing using the "refresh" button. Centaur looks ok so I'm putting this down as yet-another-smw-cache-issue. -Chieftain Alex

09:35, 28 March 2020 (UTC)

API not recovering the correct unlocks?

I have the Stellar Beacon (Torch) skin unlocked and when I go to the Stellar weapons, use my API key, only my Mace and Shield appear as unlocked. Could it be an error with that weapon skin only, but who knows, we could have more skin unlocks with the same issue. I just wanted to let you guys know this happened to me :) Thanks! (I did search the bug tracker for API, but I didn't find this bug as reported/fixed. 168.181.48.14 07:57, 28 March 2020 (UTC)

Heya, did you notice if the chat-links in the same table were displaying? Visually the table looks like it is working to my eyes - but then again I've only unlocked the shield so I can't test it like you are able to. I've purged the wiki-side cache for this page, but if you could reconfirm it's still broken or working that'd be great. -Chieftain Alex

09:23, 28 March 2020 (UTC)

I neither have the weapons unlocked, but it should work now.

An easy way to check if everything works correctly is checking the ids of the table rows, e.g. with "Inspect element" for Firefox.

It should look in the following way, here for Stellar weapons:

<table class="equip table">
  <tbody>
    <tr>...</tr>
    <tr>...</tr>
    <tr id="skins-7853">...</tr>
    <tr id="skins-7852">...</tr>
    <tr id="skins-7866">...</tr>
    <tr id="skins-7915">...</tr>
    <tr id="skins-7830">...</tr>
    <tr id="skins-7843">...</tr>
    <tr>...</tr>
    <tr id="skins-7832">...</tr>
    <tr id="skins-7906">...</tr>
    <tr id="skins-7912">...</tr>
    <tr id="skins-7890">...</tr>
    <tr>...</tr>
    <tr id="skins-7896">...</tr>
    <tr id="skins-7876">...</tr>
    <tr id="skins-7829">...</tr>
    <tr id="skins-7899">...</tr>
    <tr id="skins-7908">...</tr>
    <tr id="skins-7865">...</tr>
  </tbody>
</table>

As we can see, all ids are set and hence the widget is able to gray out obtained skins correctly. However, if there is an entry withouth an id, namely:

    <tr id="skins-">...</tr>

then

purge the skin page according to this line
purge the item page according to this line
purge the weapon overview page

See mw:Manual:Purge for different ways of purging, e.g. hitting "Refresh" button on top, or performing a null edit (click "Edit", click "Save changes" without editing anything, note that you won't show up in history)

--Tolkyria (talk) 10:10, 28 March 2020 (UTC)

Mobile browsing - Images adjacent to quotations look bad

Page: Merchandise#Hot Topic
Appearance: example

Reported by User:Sime on discord yesterday, the quotation template looks really bad when viewed on mobile browsers with a narrow page. -Chieftain Alex 18:29, 28 March 2020 (UTC)

Mobile.css patched. Floating images no longer float below 720px width due to likely collision. -Chieftain Alex

19:28, 28 March 2020 (UTC)

Inline icons and prose

Apparently whether you use a template with an icon (such as Waypoint) or text with div-inline elements (such as Sic), an unwanted line break is added. See the examples below:

This is a sentence. {{waypoint|Durmand Priory Waypoint}}. This is a sentence. This is broken.
: This is a sentence. {{waypoint|Durmand Priory Waypoint}}. This is a sentence. This works ok.

This is a sentence. {{sic|Spelling}}. This is a sentence. This is broken.
: This is a sentence. {{sic|Spelling}}. This is a sentence. This works ok.

This is a sentence. Durmand Priory Waypoint — . This is a sentence. This is broken.

This is a sentence.

Durmand Priory Waypoint — . This is a sentence. This works ok.

This is a sentence. [sic]. This is a sentence. This is broken.

This is a sentence. [sic]. This is a sentence. This works ok.

-Chieftain Alex 00:49, 26 March 2020 (UTC)

It can be broken down to the following problem (template waypoint ultimately uses {{map icon}}):

This is a sentence. <div style="display:inline">Div.</div> This is a sentence. This is broken.
: This is a sentence. <div style="display:inline">Div.</div> This is a sentence. This works ok.

--Tolkyria (talk) 00:56, 26 March 2020 (UTC)

I suspect this is due to the parser trying to produce only valid HTML5. Which sucks. I'm thinking until we identify a decent fix we should be using span wrappers around icons. -Chieftain Alex

01:25, 26 March 2020 (UTC)

It seem like this simple CSS is fixing the display issue but introduces few other minor display issues. I think it's not "elegant" and not safe enough and it will cause other problems in the future. (This in theory works for the pages as well as for the page previews)

.mw-parser-output > p { display: inline; }

I was experimenting with more complex rules using '+' and '~' selectors but without "previous sibling" selector (":has()" is still not widely supported) fixing this properly with CSS only is not possible. To fix this properly "display: inline;" need to be added to the "p" before and after every ".inline-icon" or "#sic".

Below you can find selectors fixing only "after" paragraphs:

.mw-parser-output > .inline-icon + p, .mw-parser-output > #sic + p

Simek (talk) 00:14, 27 March 2020 (UTC)

Thanks for providing a css approach, but what would happen if we simply switch them from div to span?

I checked the parameter usage of {{sic}} ({{parameter check|Sic|1}}, {{parameter check|Sic|1|500}}, {{parameter check|Sic|1|1000}}), not a single input requires a div.

All other icon templates use span, is there a special reason why exactly the template {{map icon}} uses div? --Tolkyria (talk) 10:41, 28 March 2020 (UTC)

Most of them use span yes. The only one that is less straightforward is Template:Borderless since it uses margins to crop stuff - needs some thinking. -Chieftain Alex

10:53, 28 March 2020 (UTC)

Marking this one as closed - I think most of the key templates have been updated from divs to spans. Borderless shouldn't be used in prose and is usually used as a bullet for skill icon anyway. -Chieftain Alex

21:44, 28 March 2020 (UTC)

I found that Template:Skill icon is still affected when used without list/bullets. I have added broken example to the template (source: Pump up the crowd!). Simek (talk) 22:57, 30 March 2020 (UTC)

Yes, it uses the Borderless template. If we insist on using Skill icon in prose we'll need to remove the borderless bit of it and show the black skill edges, unless there's a better solution. (css mask?) -Chieftain Alex

23:51, 30 March 2020 (UTC)

How about replacing both divs with spans and additionally adding display: inline-block; to the second span? Nightsky (talk) 08:25, 31 March 2020 (UTC)

Mobile view

On the main page in mobile view the "h2" header (steel and) is not displayed completely, see. —Kvothe (talk) 14:31, 30 March 2020 (UTC)

Thanks for the reminder. Fixed by removing the white-space:nowrap rule. -Chieftain Alex

19:13, 30 March 2020 (UTC)

Javascript resource modules loading separately instead of in one package

Each URL resource that is being loaded is being loaded as a separate request. screenshot. Normally mediawiki combines similar requests to minimise calls like these. -Chieftain Alex 23:46, 26 March 2020 (UTC)

Ok as an example let us compare visiting a random page on GW2W versus a random page on Mediawiki. For clarity I'm going to remove any file resources from the requests (.png, .jpg, .svg) and any user specific scripts that I have active (User:Chieftain Alex/common.js).

GW2W - Main Page - 53 requests every page load

GET
https://wiki.guildwars2.com/wiki/Main_Page
[HTTP/2 200 OK 440ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=monobook
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.dismissableSiteNotice.styles%7Cext.echo.styles.badge%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.content.externallinks%7Cmediawiki.skinning.interface%7Coojs-ui.styles.icons-alerts%7Cskins.monobook.responsive&only=styles&skin=monobook
[HTTP/2 200 OK 206ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.smw.style%7Cext.smw.tooltip.styles&only=styles&skin=monobook

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.srf.styles&only=styles&skin=monobook

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=site.styles&only=styles&skin=monobook

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.libs.tippy&skin=monobook&version=1wdrs
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.smw&skin=monobook&version=1vdzx
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.smw.purge&skin=monobook&version=oj9jn
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=smw.tippy&skin=monobook&version=qdtm5
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.dismissableSiteNotice&skin=monobook&version=1pp2d
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.echo.api&skin=monobook&version=1lxmf
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.echo.init&skin=monobook&version=oabs0
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.popups&skin=monobook&version=1xy3h
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=jquery&skin=monobook&version=1xgm5
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=jquery.client&skin=monobook&version=1d1dj
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=jquery.cookie&skin=monobook&version=k905m
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=jquery.getAttrs&skin=monobook&version=1p30m
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=jquery.highlightText&skin=monobook&version=1mh8h
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=jquery.suggestions&skin=monobook&version=1ucip
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.ForeignApi&skin=monobook&version=1q595
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.ForeignApi.core&skin=monobook&version=4joy6
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.String&skin=monobook&version=1bidf
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.Title&skin=monobook&version=sx80d
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.Uri&skin=monobook&version=bj8s5
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.api&skin=monobook&version=6hk5g
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.base&skin=monobook&version=m9box
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.cldr&skin=monobook&version=laa59
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.jqueryMsg&skin=monobook&version=mt8tq
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.language&skin=monobook&version=9wygu
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.libs.pluralruleparser&skin=monobook&version=ckbfi
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.notify&skin=monobook&version=14k5u
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.page.ready&skin=monobook&version=95tua
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.page.startup&skin=monobook&version=5umqm
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.page.watch.ajax&skin=monobook&version=fsejt
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.searchSuggest&skin=monobook&version=xtoaw
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.template&skin=monobook&version=n3v94
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.template.regexp&skin=monobook&version=2z7dd
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.util&skin=monobook&version=rfelv
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=oojs&skin=monobook&version=103x6
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=site&skin=monobook&version=1wpio
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=skins.monobook.mobile&skin=monobook&version=1ua0o
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=skins.monobook.mobile.echohack&skin=monobook&version=15n8b
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=user.defaults&skin=monobook&version=1bo8z
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.jquery.async&skin=monobook&version=2jds0

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.smw.tooltips&skin=monobook&version=1aqgw
[HTTP/2.0 200 OK 0ms]

JQMIGRATE: Migrate is installed with logging active, version 3.0.1 load.php:141:217

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.popups.images&skin=monobook&version=pfjll
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=ext.popups.main&skin=monobook&version=1ftqo
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.experiments&skin=monobook&version=1mkt8
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.storage&skin=monobook&version=1dq8q
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.ui.button&skin=monobook&version=1rhy1
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.ui.icon&skin=monobook&version=1rtrv
[HTTP/2.0 200 OK 0ms]

GET
https://wiki.guildwars2.com/load.php?lang=en&modules=mediawiki.user&skin=monobook&version=1bw4a
[HTTP/2.0 200 OK 0ms]

Mediawiki - mw:MediaWiki (equivalent to Main Page) - 8 requests every page load

GET
https://www.mediawiki.org/wiki/MediaWiki
[HTTP/2 200 OK 24ms]

GET
https://www.mediawiki.org/w/load.php?lang=en&modules=ext.uls.pt%7Cext.visualEditor.desktopArticleTarget.noscript%7Cext.wikimediaBadges%7Cmediawiki.ui.button%7Cskins.vector.styles.legacy&only=styles&skin=vector
[HTTP/2 304 Not Modified 15ms]

GET
https://www.mediawiki.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector
[HTTP/2 304 Not Modified 16ms]

GET
https://www.mediawiki.org/w/load.php?lang=en&modules=ext.gadget.site-styles&only=styles&skin=vector
[HTTP/2 304 Not Modified 16ms]

GET
https://www.mediawiki.org/w/load.php?lang=en&modules=site.styles&only=styles&skin=vector
[HTTP/2 304 Not Modified 15ms]

GET
https://www.mediawiki.org/w/load.php?lang=en&modules=ext.gadget.Edittools%2CcollapsibleTables%2Csite%2Ctabbedwindow%2Cuserfeedback&skin=vector&version=sesbq
[HTTP/2 304 Not Modified 16ms]

GET
https://www.mediawiki.org/w/load.php?lang=en&modules=ext.visualEditor.core.utils.parsing%7Cext.visualEditor.desktopArticleTarget.init%7Cext.visualEditor.progressBarWidget%2CsupportCheck%2CtargetLoader%2CtempWikitextEditorWidget%2Ctrack%2Cve&skin=vector&version=ouzhb
[HTTP/2 304 Not Modified 16ms]

GET
https://www.mediawiki.org/w/load.php?lang=en&modules=ext.centralNotice.choiceData%2Cdisplay%2CgeoIP%2CkvStore%2CstartUp%7Cext.centralauth.centralautologin%7Cext.eventLogging%2CnavigationTiming%2CwikimediaEvents%7Cext.uls.common%2Cinterface%2Cpreferences%2Cwebfonts%7Cjquery%2Coojs%2Coojs-router%2Csite%7Cjquery.client%2Ccookie%2CtextSelection%7Cjquery.uls.data%7Cmediawiki.String%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2Cexperiments%2CjqueryMsg%2Clanguage%2Cnotify%2Cstorage%2Cuser%2Cutil%7Cmediawiki.editfont.styles%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.ui.icon%7Cmmv.bootstrap%2Chead%7Cmmv.bootstrap.autostart%7Cskins.vector.js%7Cuser.defaults&skin=vector&version=u38e4
[HTTP/2 304 Not Modified 16ms]

Basically we're DDOS'ing ourselves if we're making excessive requests for no reason. I'm not certain if this is just because MediaWiki have some better optimised extensions, or whether we always requested everything separately, but this definitely looks weird to me. -Chieftain Alex

10:56, 29 March 2020 (UTC)

I'm pleased to say that Justin spotted that the wiki had a setting defined, for which the associated behaviour had changed from our previous MW1.30 to 1.33, namely mw:Manual:$wgResourceLoaderMaxQueryLength was previously set to -1 - this resulted in calling single resource modules in MW1.34. The setting has been removed and modules are now loaded together. -Chieftain Alex

19:08, 31 March 2020 (UTC)

Cat hunt is missing its API widget

Hungry cat scavenger hunt used to have a widget which would grey out rows of cats that were already found but it is now gone. --BuffsEverywhere (talk) 23:28, 1 April 2020 (UTC)

Fixed. -Chieftain Alex

23:32, 1 April 2020 (UTC)

STDT styles missing in mobile view

Tables with classes from {{STDT}} have gray backgrounds in the mobile theme. See e.g. the table at the bottom of the Templates page while using the mobile view. Nightsky (talk) 01:18, 9 April 2020 (UTC)

Added (somewhat simplified) styles to Mediawiki:Mobile.css. Test cases here. -Chieftain Alex

15:46, 10 April 2020 (UTC)

Generic JS/resource module errors

Since there are two distinctly different errors here, I'm splitting them up. This section is for Any view (Desktop or Mobile) setting where scripts and modules randomly fail and throw errors into the console.

Food#Filter_parameters do not work after update

The filter parameters on the wiki/food page don't load properly and clicking on the boxes no longer does anything. Purple Squirrel (talk) 13:05, 2 April 2020 (UTC)

Are you using Desktop view or Mobile view mode? If you're using mobile view mode (where the page content appears in a narrower column), this is the same bug as #Event timer on mobile view (bug #2) above. -Chieftain Alex

17:26, 2 April 2020 (UTC)

If you hard reload the page (ctrl + f5) in desktop mode it will work until you navigate away and return. Upon return, it will raise a JavaScript exception:

 Uncaught TypeError: mw.loader.using is not a function at Food:6382 at defer (Food:6313) at Food:6320

and the buttons will not work correctly. A hard reload fixes this again until you navigate away.

The mobile page failed to render the filter box at all, due to #Event timer on mobile view (bug #2). For desktop, this does not appear to be related to that bug, though mediawiki.api.parse and WidgitSeperators are involved. Caddox (talk) 21:22, 2 April 2020 (UTC)

On further review, I was a fool, moved too fast, and am now experiencing inconsistencies between machines in reproducing the bug. Phabricator lists a similar bug that was occurring on a different wiki, though their fix may not work here. Hard reloading should still help those afflicted for the time being. Caddox (talk) 02:33, 3 April 2020 (UTC)

I still think this is the same issue as above with mobile widgets breaking SyntaxError: '' literal not terminated before end of script and parser interfering with the widget. I'd like to find a way of switching widgets OFF in mobile view, since this one isn't particularly painful if it doesn't load.

~~I really do not want to migrate the Filter table widget since it's full of widget smarty syntax parameters.~~ -Chieftain Alex

17:53, 7 April 2020 (UTC)

I did some more investigating on the desktop bug with the items on the filter table not rendering, and it turns out it is a bit stranger than I thought. Firefox loads the page perfectly 100% of the time. Chrome fails to load the filter table when it attempts to load the script from the cache. Legacy Edge (which is Chromium?) and Internet Explorer do whatever the heck they want so that I cannot consistently reproduce them. Chrome attempts to parse the script it got from the cache before the rest of it has been dynamically generated (including the definition of mw.loader.using) so this seems to be (again) another dynamic loading issue. For reference, this fails on Chrome ver 80.0.3987.149 and ver 80.0.3987.163, and succeeded on Firefox Dev version 76.0b1. Extensions do not appear to be an issue. The only difference between the requests on Firefox and Chrome is the version param it asks for from the load.php url. I am not 100% sure this has nothing to do with mobile widgets, but this specific issue I feel is separate, and may in fact be a Chromium or MediaWiki issue. Caddox (talk) 03:36, 8 April 2020 (UTC)

I changed the Filter table widget a bit to not use anything resemling a valid html tag or end tag (be it in js-quotes (like </div> was sometimes) or not) inside the script tag and the parser seems to not complain about it now anymore so the food filtering should work again. (Let me know if it doesn't. It seems to me i does though the more eyes the better.)

It seems like the parser doesn't like the raw tags in there. I also think it only doesn't like the </div> tag in particular, since it usually broke near one, though i can't quite say that for sure since i replaced all tags at once so it might be another one or a combination or actually only the <div>. Nightsky (talk) 18:54, 8 April 2020 (UTC)

Thanks Nightsky. Whatever you did fixed the widget in mobile view so that it renders correctly (solving the bug: 'Extension:Widget scripts breaking with Extension:MobileFrontend' for this widget). Unfortunately, now it suffers from the same issue that the desktop rendering is experiencing on Chrome, and when the script fails to load correctly, the table does not function as it should. Still looks like disk cache issues to me, but I still do not know if its due to MediaWiki bugs or Chrome doing 200 caching rather than waiting for a 304 and parsing the response header fully. Caddox (talk) 19:58, 8 April 2020 (UTC)

Are we describing a "javascript back-forward cache" issue here? i.e. the table works, you navigate forwards to a specific page, then navigate using the browser back button and the javascript doesn't completely load? -Chieftain Alex

21:49, 8 April 2020 (UTC)

Basically. It occurs on back navigation and a soft-refresh (normal f5 press) from the cache. Found a solution? Caddox (talk) 22:41, 8 April 2020 (UTC)

I added mw.loader.using as a dependency to the loop we have, courtesy of Alex, to wait for things so it should also work when the browser tries to execute the script from cache before what's used in it is ready now. As a result it might take a little longer to load now too but it seems to always end up working. (At least it doesn't break for me anymore. Let me know if it does after all.) —The preceding unsigned comment was added by Nightsky (talk) at 23:56, 8 April 2020‎ (UTC).

That solution works for all of my tests. The speed is really only noticeable on a hard reload, and even then my internet is so bad I really cannot tell the difference. Thanks for tinkering with it! Caddox (talk) 01:49, 9 April 2020 (UTC)

You're welcome! And Thank You for reporting it so detailed. Nightsky (talk) 02:54, 9 April 2020 (UTC)

Widget compiled templates folder unwriteable and Images unable to be uploaded

Widget:Game_link Error

For example on page Riftstalker Carapace - Error in widget Game link: unable to write file /var/www/sites/gw2w-en/extensions/Widgets/compiled_templates/wrt5e929b50d51d85_26349572 -84.249.74.90 05:34, 12 April 2020 (UTC)

Legendary Rune, Legendary Sigil, Gift of Runes, Gift of Sigils - Also displaying the same error. --SaiyanOfDarkness

I don't believe this to be a wiki only bug. Certificate for certain resources has expired.

suspicion: Some idiot purged the Widget:Game link, and after the certificate expired, there is no longer the permission to write to that folder, and as a result all pages using that widget are broken. -Chieftain Alex

07:44, 12 April 2020 (UTC)

This issue should be resolved as I believe it was due to an issue local to the web servers. Please let me know if you continue to see this. Justin Lloyd (talk) 09:46, 13 April 2020 (UTC)

Map reward page gives an error

In the page: [1] Error in widget Map bonus rewards: unable to write file /var/www/sites/gw2w-en/extensions/Widgets/compiled_templates/wrt5e92d0a95bf353_91238963 is given -Tinel (talk) 08:40, 12 April 2020 (UTC)

Same error as above. -Chieftain Alex

09:25, 12 April 2020 (UTC)

Same fix as above. :) Justin Lloyd (talk) 09:50, 13 April 2020 (UTC)

Special:Upload empty file

I recently had an issue with the Special:Upload page. How do I know if this issue is due to the March 2020 change or not? I was able to upload images fine yesterday, but I have not been able to upload anything today. Error is: "The file you uploaded seems to be empty. This might be due to a typo in the filename. Please check whether you really want to upload this file." Details here in case maybe this error is a bug which should go on this page? This page seems rather technical, and I am not a technical person. Since this issue only appeared today, I'll see if the error still appears tomorrow; if the changes to the wiki occurred during March, then why is this issue appearing now (if indeed it is an issue at all)? I would appreciate some guidance if anyone has time. AnastashaRomanov (talk) 08:27, 12 April 2020 (UTC)

If the wiki does not behave as you expect, just raise a bug report. What you're describing however is a bug and is highly likely related to the certificates/write issue same as the widget folder. -Chieftain Alex

09:25, 12 April 2020 (UTC)

This may have been related to the disk space issue. I just uploaded a test image and it worked fine, so I think this may be resolved. Please let us know if you continue to see this problem. Justin Lloyd (talk) 09:54, 13 April 2020 (UTC)

Server file permission issues

→ moved from Guild Wars 2 Wiki:Admin noticeboard

I'm getting some errors regarding your file permissions,

Points of Interest
    Point of interest.png Mysterious Pylons —
    Error in widget Game link: unable to write file /var/www/sites/gw2w-en/extensions/Widgets/compiled_templates/wrt5e933dafad2a61_82513087
    Point of interest.png River of Spirits —
    Error in widget Game link: unable to write file /var/www/sites/gw2w-en/extensions/Widgets/compiled_templates/wrt5e933dafc10c45_63972444
    Point of interest.png Abandoned Outpost —
    Error in widget Game link: unable to write file /var/www/sites/gw2w-en/extensions/Widgets/compiled_templates/wrt5e933dafca8f94_06632081
    Point of interest.png Bandit's Rest —
    Error in widget Game link: unable to write file /var/www/sites/gw2w-en/extensions/Widgets/compiled_templates/wrt5e933dafd82fe7_13085179
    Point of interest.png Gorseval's Perch —
    Error in widget Game link: unable to write file /var/www/sites/gw2w-en/extensions/Widgets/compiled_templates/wrt5e933dafe15f55_53514913
    Point of interest.png The Skillet —
    Error in widget Game link: unable to write file /var/www/sites/gw2w-en/extensions/Widgets/compiled_templates/wrt5e933dafed5401_06359024

Landmarks

Spirit Vale page, for example. I've seen similar elsewhere. —The preceding unsigned comment was added by EricLnu (talk • contribs) at 16:14, 12 April 2020‎ (UTC).

Same issue as above. It's using a widget. -Chieftain Alex

16:41, 12 April 2020 (UTC)

This should also be resolved with the disk space fix, per the above related issues. Please let us know if you continue to see this. Justin Lloyd (talk) 09:55, 13 April 2020 (UTC)

Legendary Ley-Line Anomaly Event Timer not working

The Legendary Ley-Line Anomaly Event Timer section gives the following error info:

Error in widget Event timer: unable to write file /var/www/sites/gw2w-en/extensions/Widgets/compiled_templates/wrt5e934a0bc788f2_94630893

-160.2.65.34 15:15, 13 April 2020 (UTC)

Stabilized Prophet Crystal

This error is also appearing on the PC side as well as the mobile, most notably when a single item (with a descriptor box) is opened. Here's what the viewer sees: (in part)

Stabilized Prophet Crystal


Jump to navigation
Jump to search


Stabilized Prophet Crystal
Item type
Crafting material
Material type
Basic material
Disciplines used by
 400
 400
 400
Rarity
Exotic
Value
3 
Game link
Error in widget Game link: unable to write file /var/www/sites/gw2w-en/extensions/Widgets/compiled_templates/wrt5e93d265613f53_07128243
Trading post
7  34  94 
6  44  44 
External links
GW2BLTC
GW2Spidy
GW2TP
API
API

Sorry if this is repetitive but the only record I'm seeing is for the Mobile version of the Wiki. I've tried closing and reopening the Wiki with no effect. User:Undouble 15:06, 13 April 2020‎

Purge the page using the big "purge" button at the top of the page if you see any of these errors. -Chieftain Alex

15:32, 13 April 2020 (UTC)

Error in widget Game link: unable to write file

In this page https://wiki.guildwars2.com/wiki/Piece_of_Candy_Corn The right panel has an error on the Game link section.

The error is:

Error in widget Game link: unable to write file /var/www/sites/gw2w-en/extensions/Widgets/compiled_templates/wrt5e938964baff49_28322773

My guess is that right access to the mentioned folder should be granted. —The preceding unsigned comment was added by JaneEsobiomentale (talk) at 16:17, 13 April 2020‎ (UTC).

Purge the page with the big purge button. Works fine. -Chieftain Alex

16:38, 13 April 2020 (UTC)

Template viewability on mobile

At least some of the notification templates above wiki articles appear to stretch and cut off the text within the template box itself when viewed on mobile. The examples I've encountered so far are 1) the "future content" template (seen e.g. on top of the page for Drizzlewood Coast), and 2) the template used on former ANet employee pages (seen e.g. on top of the page for Mike Zadorojny as that template is part of the "ArenaNet employee infobox" template and appears above the page if the "former" status is set to "yes" in the infobox). Additionally, the "Verbatim" template used for short stories and blog post texts (e.g. The Mordrem Guard) does not adapt to the mobile screen and instead appears as wide as it would be on desktop view, making it difficult to read on mobile due to all the scrolling. --Kossage (talk) 15:05, 14 May 2020 (UTC)

Please provide screenshots with arrows identifying the exact issue. Debugging layout and content issues is much easier that way. -Chieftain Alex

17:00, 14 May 2020 (UTC)

Images taken on Samsung Galaxy J6 with the latest android and firefox updates installed. Uploaded on Imgur. Note: the Drizzlewood Coast (which uses the "future content" template) and Mike Z (which uses the notification template spawned by the infobox's "former = y" variable) articles' templates look alright if the phone is held sideways but they don't look alright if the phone is held in a normal "up" way (as seen in the screenshots), whereas the text in The Mordrem Guard article (which uses the "verbatim" template) stretches beyond the screen regardless of which way the phone is held. Screenshots of the articles with the aforementioned template issues: Drizzlewood Coast, Mike Zadorojny, The Mordrem Guard when held up, The Mordrem Guard when held sideways. Because the issues are clearly visible in the phone screenshots, I assume that no additional arrows are needed for the screenshots in this case. But if really needed, let me know and I can upload images with arrows. I hope this helps. :) --Kossage (talk) 18:40, 14 May 2020 (UTC)

That's really helpful thank you

(1) and (2) are to do with the inline styling we apply to pretty much every boilerplate notice template on the wiki. I'm happy to define some CSS styles in common.css + mobile.css instead. Needs some thought though as this will affect most pages on the wiki.

(3) Template:Verbatim - created a new CSS class "mobileonly" (defined in Mediawiki:Common.css) which is the opposite of "nomobile". The page content will have different inline styles depending on whether viewed on mobile or desktop now (specifically no fixed width).

Cheers! Just checked The Mordrem Guard article and the verbatim template works splendidly now! :) While browsing the pages, I've spotted another problem, however, this time with what I think might be the "gallery widget" where the template spawns a string of code with warnings about SMW galleries etc. right below the last image in any page's gallery on the phone while appearing normal on desktop view. Relevant screenshots from the entire string seen on the Drizzlewood Coast article on the phone: image 01, image 02, image 03, image 04. I hope this helps. --Kossage (talk) 19:53, 14 May 2020 (UTC)

I've been stubborn about the gallery widget. See #Extension:Widget scripts breaking with Extension:MobileFrontend. -Chieftain Alex

20:04, 14 May 2020 (UTC)

Marking this section as resolved, I've added Desktop CSS and Mobile CSS, and modified 16 notice templates. There will probably be a few more notices I've missed, e.g. Delete, which i'll get around to. -Chieftain Alex

10:40, 17 May 2020 (UTC)

Widget:Filter table mw.loader.using undefined function in Chrome only

Reported by Dak, the widget sometimes stops at the mw.loader.using line in Widget:Filter table, this happens particularly in Chrome. screenshot of console (firefox on left, chrome on right). It seems that Chrome is passing the if logic block in the defer function, despite my attempts to make it check the function is defined.

I've put together a copy over at Widget:Test and User:Chieftain Alex/sandbox2.

FWIW it always works fine on the tiny example at the top of "Widget:Test" but almost always fails (still on Chrome mind) on /sandbox2. -Chieftain Alex 18:36, 20 May 2020 (UTC)

It seems chrome caches functions (at least the ones in global scope apperently) accross page refreshes which led to the defer function defined by Widget:Tp total calculate replace the function already defined by Widget:Filter table on Ascended feast. And since the later definition of defer only checks for window.jQuery the method body of the anonymous method passed to the defer method in Widget:Filter table used the other defer method if anything isn't ready on the first call in which case the setTimeout call used the later definition of defer. I've put the code of Widget:Tp total calculate out of global scope so it doesn't redefine the defer method there and impacts Widget:Filter table as is on Ascended feast anymore. Should probably go through all Widgets at one point and see if puting them in (function() {...})() makes sense; to prevent future interference between any. For now, at least things on Ascended feast should work again already though; even in chrome. Nightsky (talk) 13:31, 22 May 2020 (UTC)

I missed your fix from last week - lovely work! -Chieftain Alex

23:32, 26 May 2020 (UTC)

413 Error Trying to Upload Images Bigger Than 1MB

See title. Everything under 1MB seems to be fine. Was working properly a couple of hours ago. talk 18:20, 30 June 2020 (UTC)

Looking into this. I did some maintenance earlier but it shouldn't have affected upload size limits, I don't think. Justin Lloyd (talk) 18:21, 30 June 2020 (UTC)

Thanks for the swift reply! Let me know if you need any more info.

talk 18:25, 30 June 2020 (UTC)

Give it another try, it should work now. Justin Lloyd (talk) 18:34, 30 June 2020 (UTC)

Yep, works again! Thank you very much. :)

talk 18:52, 30 June 2020 (UTC)

Error creating thumbnail

I tried to create File:Skyscale Lost - Eastern Complex.png with — (see history) similar to File:Flying Lesson—Jahai Bluffs.png but I got the following error when I wanted to create Skyscale Lost—Eastern Complex. On Skyscale Flight you can see what the goal of this all is - creating collection items for Skyscale Lost.

Error creating thumbnail: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (c.utf8) convert: unable to open image `/var/www/sites/gw2w-en/images/b/b7/Skyscale_LostEastern_Complex.png': No such file or directory @ error/blob.c/OpenBlob/2701. convert: no images defined `/tmp/transform_c3e73c48244c.png' @ error/convert.c/ConvertImageCommand/3258. Error code: 1

Not sure what the cause of it is, so for the moment I will work around with just spaces and normal "-" for the icons and files. —Kvothe (talk) 11:25, 2 July 2020 (UTC)

I'm looking into this. Justin Lloyd (talk) 11:38, 2 July 2020 (UTC)

I see the actual filename is Skyscale_Lost—Eastern_Complex.png, note the hyphen. Does that make a difference to what you're doing? Justin Lloyd (talk) 11:46, 2 July 2020 (UTC)

The items are named e.g. "Skyscale Lost—Displaced Tower" ingame, so with the hyphen in the file name it would be less work to create. I can work around it with the "|icon = " parameter. Note that none of the items created and icons moved for Skyscale Flight on 14 June 2020 e.g. Flying Lesson—Sandswept Isles File:Flying Lesson—Sandswept Isles.png have this problem.

If it is a new restriction introduced with the maintenance this week (see report above), please let us know what we have to ommit in file names, so that they are able to create thumbnails / alternate sizes. —Kvothe (talk) 11:55, 2 July 2020 (UTC)

It's not a new restriction, I just saw that difference and wasn't sure if that was the basic issue. I'll continue digging to figure out what's causing this. It shouldn't be happening. Btw, how big is the new file you're uploading? Justin Lloyd (talk) 12:00, 2 July 2020 (UTC)

Neither of the images are new, simply moved. File:Skyscale Lost—Displaced Tower.jpg seems to work sometimes now. I just moved File:Skyscale Lost—Skipping Stones.jpg and File:Skyscale Lost—Skipping Stones.png. The png image page works fine as no thumbnail needs to be created, but the jpg does show the error .Skyscale Lost—Skipping Stones shows the thumbnail error. —Kvothe (talk) 12:11, 2 July 2020 (UTC)

Multiple purge/null edits fix it. It seems like the thumbnails are created but the correct path is not able to be saved sometimes. (I moved two new files for Skyscale Lost—Buried Archives which I will not purge/null edit, hope that helps in figuring this out.) —Kvothe (talk) 12:21, 2 July 2020 (UTC)

I do see the image pages are working after I could no longer repro the issue on them but having the one page that can still consistently error is helpful. I'll keep digging, it's definitely strange and so far I'm not seeing any clear indications in system logs of the problem. (FWIW the recent maintenance was migrating the servers from Apache to Nginx, which shouldn't be related to this, but it's possible there is some default setting that was different with Apache than in Nginx. That was the issue with the recent upload size issue, Apache defaulted to 2 MB but Nginx to only 1 MB, despite the PHP 8 MB limit we have set.) Justin Lloyd (talk) 12:29, 2 July 2020 (UTC)

For some reason the failing convert command on that page is still trying to reference the filename without a hyphen, i.e. Skyscale_LostBuried_Archives.png, but even the real filenames on disk are using em-dashes between Lost and Buried, i.e. character code 342 200 224. Justin Lloyd (talk) 12:59, 2 July 2020 (UTC)

I recently finished the other items for Skyscale Lost and had only 3 of the missing 18 items with the error - which fixed itself after 1-2 purges instead of 10+ purges/null edits as a few hours ago. —Kvothe (talk) 18:02, 2 July 2020 (UTC)

Glad to hear the issue is resolved though it sounds strange that it took so many purge requests. It doesn't sound like it was related to the web server changes, but please let us know if any similar issues arise again. Justin Lloyd (talk) 18:10, 2 July 2020 (UTC)

Solved. See next section #Spanish wiki uploading issue. --Tolkyria (talk) 08:21, 25 September 2020 (UTC)

Spanish wiki uploading issue

Myself and several other Spanish wiki editors have noticed that we seem to get issues when uploading files recently that are usually something like this:

"Error creating thumbnail: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (c.utf8) convert: unable to open image `/var/www/sites/gw2w-es/images/d/de/Comerciante_de_recompensa_de_bsqueda_del_tesoro.jpg': No such file or directory @ error/blob.c/OpenBlob/2701. convert: no images defined `/tmp/transform_d2d7001ce854.jpg' @ error/convert.c/ConvertImageCommand/3258. Error code: 1"

I'm guessing it has to do with letters like "á,é,í,ó,ú". It resolves itself eventually, but it's spooked at least one or two people that they broke something. - Do_odleplex 23:24, 29 August 2020 (UTC)

I'm looking into this. Justin Lloyd (talk) 09:47, 31 August 2020 (UTC)

I haven't seen anything in the logs so far. Is this issue reproducible, including on the dev Spanish wiki, or even the French or German wikis if it may be related to at least certain accented characters? Justin Lloyd (talk) 13:39, 1 September 2020 (UTC)

As far as I know it seems to happen with letters that aren't in the standard US alphabet, but I wonder if it's related to the above issue? I just noticed the error message is exactly the same, though I don't seem to get the same issue here. It's very strange. - Do_odleplex 20:48, 4 September 2020 (UTC)

Out of curiosity, are the uploads working as otherwise expected despite the warning message? Are there any missing images/thumbnails for the image uploads that result in the warning? I'm asking based on what this MediaWiki Support Desk topic says. That said, I can try to reproduce this issue if you can point me to a particular image that has thrown that warning so I can test it on the dev ES wiki. Justin Lloyd (talk) 13:30, 8 September 2020 (UTC)

One thing that might help, though I'd be surprised if this is only a recent problem with this wiki, or even the German or French wikis, would be changing the value of $wgShellLocale from its current setting of c.utf-8 to one that is more specific to the wikis' languages. We could test this on the dev wiki. Justin Lloyd (talk) 16:10, 8 September 2020 (UTC)

As I stumbled across this bug again today, I decided to write down my experience with it. It's not a spanish wiki problem only, it also appears here on the english one, see also the bug report above which is basically the same issue.

The wierd part of this bug is the restricted times where it appears. I managed to reproduce it by hitting the "purge" button on top several times on pages containing special characters. After 1-5 purges the thumbnail breaks.

E.g. purging File:Stéphane Lo Presti.jpg several times gaves me:

Error creating thumbnail: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (c.utf8) convert: unable to open image `/var/www/sites/gw2w-en/images/3/32/Stphane_Lo_Presti.jpg': No such file or directory @ error/blob.c/OpenBlob/2701. convert: no images defined `/tmp/transform_d33054ae08a8.jpg' @ error/convert.c/ConvertImageCommand/3258. Error code: 1

Hence, you should be able to reproduce it. Here the bug doesn't last long (a simple page refresh - F5 - and the image is displayed correctly), however moving or uploading the file seems to create this bug for ~10 minutes (at least this was the case in the bug report above).

Directly below the unbugged image it states: Size of this preview: 458 × 599 pixels. Other resolutions: 183 × 240 pixels | 1,144 × 1,496 pixels.

While being bugged, it only states: Other resolution: 1,144 × 1,496 pixels. Furthermore, the 183 × 240 pixels and 458 × 599 pixels files aren't available and will instantly redirect to Main page. On the other hand, the full resolution image is always available, here full resolution

I also managed to create this bug while querying for files with special characters (far more difficult to reproduce, by trying different px sizes to force the image conversation I somehow managed it), e.g. using the following smw wildcard query searching in filespace:

{{#ask: [[File:+]][[~*é*||~*è*]]|?#noimage|?#120px}}

Then the file page itself was okay, only the image in the query result table appeared to be bugged.

Conclusion: this bug seems to appear only while the image is getting converted, it seems that ImageMagick sometimes (?!) fails to parse/receive/pass forward (whatever) the special characters properly. I'm not an wiki expert at all, but maybe this somehow helps. --Tolkyria (talk) 19:35, 22 September 2020 (UTC)

Thank you for that detailed explanation and steps to reproduce, that should be helpful. I'll delve further into this and see if I can repro it in dev and get some more detailed MediaWiki and/or system logs that might shine some light on the underlying issue. Justin Lloyd (talk) 19:44, 22 September 2020 (UTC)

I think I've figured out the issue. The $wgShellLocale> setting has been set to c.utf8 forever, though the default used to be en_US.utf8 until MediaWiki 1.30 when it changed to C.UTF-8 (we're on 1.34 now). So it looks like just commenting out that variable and letting it take its default value seems to do the job on the dev wikis. Are you able to do your own testing on the dev wikis to verify the fix to your satisfaction? Justin Lloyd (talk) 20:15, 23 September 2020 (UTC)

Sounds good! Using the intended default value most likely shouldn't have any negative side effects on our wiki, at least mw:Manual:$wgShellLocale doesn't mention anything. I can't access the dev wiki since I'm missing the login information, but I'm totally fine with your bug fix confirmation. --Tolkyria (talk) 22:08, 23 September 2020 (UTC)

I've pushed out the change to the live wikis. Let me know if you continue to see this issue on any of them. Justin Lloyd (talk) 09:47, 24 September 2020 (UTC)

Thanks! Based on how easy this bug could be reproduced before the fix and that right now I cannot reproduce it at all, I'll mark the sections #Error creating thumbnail and #Spanish wiki uploading issue as

Solved. --Tolkyria (talk) 08:21, 25 September 2020 (UTC)

Mobile design loading on desktop

Encountered an interesting bug when I loaded my wiki bookmark just now while on desktop: instead of the normal layout it displayed the mobile design. Apparently that's happened to other users as well. If relevant: I'm running on firefox, not saving cookies and/or site data; wasn't logged into my account yet. talk 18:06, 4 April 2020 (UTC)

I take it you're sure you didn't follow anyone's provided link with the "&mobileaction=toggle_view_desktop" suffix? How odd. -Chieftain Alex

18:36, 4 April 2020 (UTC)

I disabled all of my add-ons, cleared everything, rebooted firefox and can't reproduce this issue consistently. -Chieftain Alex

19:24, 4 April 2020 (UTC)

Sometimes I can get the issue to occur. The same thing happens on the GW1W (see above screenshot including initial response headers). It seems to only occur for anonymous users. I am wondering if the response for a given page is cached for a user using a mobile device, and then the desktop user visiting soon afterwards receives the wrong theme. -Chieftain Alex

22:53, 4 April 2020 (UTC)

Got a response from another user with the same problem on reddit - see this comment -Chieftain Alex

13:13, 5 April 2020 (UTC)

ArenaNet have made a modification to the MobileFrontend configuration along the lines of mw:Extension:MobileFrontend/Configuring browser auto-detection $wgMFAutodetectMobileView = true;. They'll be watching to see if anything explodes serverwise - let us know here if the bug reoccurs. -Chieftain Alex

16:24, 6 April 2020 (UTC)

Report on GW2 Development Community that they still got served the mobile version on their desktop. Idk how long this setting change will take to have an impact. -Chieftain Alex

16:32, 6 April 2020 (UTC)

I'm marking this as fixed for now - if this is not the case, please report it! -Chieftain Alex

17:53, 7 April 2020 (UTC)

Report this afternoon from User:Inc that the bug is still occurring. https://cdn.discordapp.com/attachments/439163526616055821/697417045628682280/unknown.png . Moving this back to "not fixed". -Chieftain Alex

12:24, 8 April 2020 (UTC)

(Reset indent) ANet sent an email on Friday late afternoon saying they think they have a fix, will be applied on Monday probably. -Chieftain Alex

09:25, 12 April 2020 (UTC)

I haven't seen this bug in ages, assume it's closed, marking resolved. -Chieftain Alex

19:45, 28 September 2020 (UTC)

Not fixed

Extension:Widget scripts breaking with Extension:MobileFrontend

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 Alex 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 Alex

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 Alex

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... --zeeZ

(talk) 17:10, 26 May 2020 (UTC)

JavaScript appears as text on mobile view

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 Alex

21:48, 29 April 2020 (UTC)

Potential solution

(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 Alex

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 Alex

17:28, 8 April 2020 (UTC)

Widget:Jquery test - test page if we're doing any testing of extensions. -Chieftain Alex

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 Alex

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)

So.. i have now removed the HTML tags from and undone the split into a searate script for all scrips i could find that appeared to have been split because of them running into this issue. (Feel free to let me know if i missed any.) And since they don't spill the code onto the page anymore even though they are back where they were when it happened i considder this complete now. And while some of the other widgets contain HTML tags inside of script tags still, i'm unsure weather or not i want to go through them as well or not yet; even though they work fine for the time being - thanks to the abscence of </div> instances - it might not be a bad idea to go through them anyways. First i'll see if i can possibly change [[Widget:Gallery]] and [[Widget:Fullscreen images]] to not have trouble with the lazy loading of images in mobile view though (That's what i think it is that they seem to have problems with at least as they appear to work just fine when using them in mobile page previews.), that is if Chieftain Alex doesn't beat me to doing that anyways; no need for me to see if i can do it then of course. Nightsky (talk) 03:05, 2 October 2020 (UTC)

Cool, I'll have a look at the gallery widgets, but yes it looks like the noscript lazyload element will confuse it. -Chieftain Alex

06:31, 2 October 2020 (UTC)

"Gallery widgets", plural! Why are there even two of them? Take this as a chance to unify and merge them (Probably fullscreen images widget being superior), no need to have them both. We already had such a multi-widget-confusion for one and the same feature once, namely with the map widgets. --Tolkyria (talk) 08:21, 2 October 2020 (UTC)

Guild Wars 2 Wiki:Reporting wiki bugs/archive 10

Not actual bugs

Infobox error

SMW query further results

SVG images do not respect EM sizes

High ratio of Outdated entities to Entities on Special:Statistics

Tables with a caption have a different color

API map tiles not displaying

Scrolling thru articles featuring maps

Wrong game link for Latte Dye

"Grothmar Valley Achievements" Missing data/requirements/information

Outstanding bug in daily fractal achievement

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

Fixed bugs

Achievement Box broken

Creature Nav template and Drops table templates are broken

Map Objective templates

Heart template

Vendor List template

Event timers randomly breaks on Firefox

Mobile view bug

Drop Research charts are broken

Broken event disambig template

Account creation fails and displays an Internal error warning

List of Runes broken

Galleries not working

Searching broken

Waypoint template

Pet skills data is lacking

Internal Error occuring on some wiki pages

Run query: Base ingredients not always working

Gathered From template has some issues

No TP prices

The Release infobox template doesn't format images properly anymore

Expression error: Unexpected > operator on Treasure Hunter

Redirecting to other Wikis

Incomplete NPC members list

API not recovering the correct unlocks?

Mobile browsing - Images adjacent to quotations look bad

Inline icons and prose

Mobile view

Javascript resource modules loading separately instead of in one package

Cat hunt is missing its API widget

STDT styles missing in mobile view

Generic JS/resource module errors

Widget compiled templates folder unwriteable and Images unable to be uploaded

Widget:Game_link Error

Map reward page gives an error

Special:Upload empty file

Server file permission issues

Legendary Ley-Line Anomaly Event Timer not working

Stabilized Prophet Crystal

Error in widget Game link: unable to write file

Template viewability on mobile

Widget:Filter table mw.loader.using undefined function in Chrome only

413 Error Trying to Upload Images Bigger Than 1MB

Error creating thumbnail

Spanish wiki uploading issue

Mobile design loading on desktop

Not fixed

Extension:Widget scripts breaking with Extension:MobileFrontend

Potential solution

Navigation menu

Search