Guild Wars 2 Wiki:Reporting wiki bugs

From Guild Wars 2 Wiki
Jump to navigationJump to search
Please report all bugs found on Guild Wars 2 Wiki here.

This page is NOT for reporting game bugs, those should be reported at the official forums.



This page is used to report bugs with the wiki, this does NOT cover in-game issues.

  • If you are experiencing an in-game bug or issue that requires technical support, check the Guild Wars 2 official forums.
  • If you are experiencing difficulties getting past a specific part of the game, please use the "Search" box on the left to find the specific quest, mission, or region that you are finding difficult. You can review any tips on that page, and discuss it on corresponding talk page if more help is desired.
  • If you have a problem with contents of a wiki page, use the associated talk page.

Please review existing bug reports before creating a new one, these will be listed below. If you add a bug not related to the wiki (such as a bug in the game itself), the report may be removed with no actions taken.

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

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

Yes Semantic query: Printout skips data[edit]

See /archive 12#Semantic query: Printout skips data for full description.

Long term issue. Awaits https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/5036 which didn't make it into the release of SMW 4.0.0.

Mitigated by edits such as this one. -Chieftain AlexUser Chieftain Alex sig.png 12:47, 11 September 2022 (UTC)

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

See /archive 12#Mobile theme when viewed on desktop - not loading custom css at all for full description.

Considered mitigated through javascript in Mobile.js, Common.js, and Minerva.js. -Chieftain AlexUser Chieftain Alex sig.png 12:47, 11 September 2022 (UTC)

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

Sometimes occurs when:

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

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

It also affects expandable tables, which uses MediaWiki:CollapsibleTables.js, by not collapsing them on page load. This includes the template Spoilers that to be honest should never fail.
Could this be a browser-related bug, namely only affecting Firefox? I'm not using Chrome that much and can't remember if it occured there for me, but right now I couldn't reproduce it. --Tolkyria (talk) 22:04, 1 November 2021 (UTC)
Like with almost everything i can only guess but if it's in any way related to jquery not loading then the only thing i could find about that back when i looked for why that might be was mw:ResourceLoader/Migration guide (users)#jQuery and mw:JQuery#ResourceLoader, which looking at Guild Wars 2 Wiki:Changelog could be possible (since there's a lower version than 1.17 listed), but i wouldn't know how to tell if it's both a thing and or if it's even related or not. Nightsky (talk) 07:09, 2 November 2021 (UTC)
I also get this issue a lot (in Firefox only, and never when the developer console is open). The script is running before the DOM is fully parsed, so I think it might be fixable by changing <script> to <script defer> in Widget:Game link (edit: at least for chat links, I didn't look at how collapsible tables are set-up) - Fam (talk) 22:14, 18 February 2022 (UTC)
You don't happen to have the "Disable Cache"-check box on the "Network"-tab checked, do you? That would be the only thing that i would suspect that might cause it to not occur anymore with the dev console open at least.
I'm afraid but going by the warning on this page it would seem that your suggested change would have no effect.
If the problem's that scripts are running before the DOM's fully parsed though then something like this should do the trick.
And; am i understanding this right that this means that the chat codes still act up/remain blank sometimes? Nightsky (talk) 17:59, 20 February 2022 (UTC)
Apologies, my bug report above lacked diligence. Chat codes are loading correctly, and I have not seen any issues with chat codes. The problem I am actually having is similar but distinct: In about 1/8 page views -- in Firefox only -- where the page contains trading post prices, the prices will fail to load (instead they will just say 'Loading...' indefinitely) and the "addMastHead: "#column-one" not found." message will appear in the console, and no request to the official API will be made. I assume (but cannot verify) it fails to load because .gw2-tpprice does not exist in the DOM when the code is run (so DOMContentLoaded may help). Fam (talk) 20:11, 25 February 2022 (UTC)
Ah, i see. That is a very possible theory. I wonder if one of the admins could exchange (since the former seems to be present still) the try catch in Mediawiki:Common.js for the above so the effect can be observed? Nightsky (talk) 18:28, 26 February 2022 (UTC)
Implemented the example here. -Chieftain AlexUser Chieftain Alex sig.png 22:27, 26 February 2022 (UTC)
Still seems borked. -Chieftain AlexUser Chieftain Alex sig.png 22:31, 26 February 2022 (UTC)
(Reset indent) I noticed today the wrapper script in common.js was only expecting a "loaded" state (and inherently assumed the only other state was "complete"). I found in the javascript reference docs that there's another state ("interactive"). I've applied a tweak, this may cause the clock etc to work more often (this is probably unrelated to the root cause of this particular issue, but it will help stop people reporting incorrect issues). -Chieftain AlexUser Chieftain Alex sig.png 19:25, 4 September 2022 (UTC)
Still appears to occur in MW 1.38. -Chieftain AlexUser Chieftain Alex sig.png 12:47, 11 September 2022 (UTC)
Does this also occur on the test wiki? If so, would it be possible to test there if it would go away when the skin's there replaced by one from a fresh install? Nightsky (talk) 18:00, 10 October 2022 (UTC)
based on the timestamp of my edit above, which was prior to the live wiki being updated, yes this occurs intermittently on the dev wiki. I believe when the dev wiki is set up, that everything is installed from scratch + then the page table + user database is copied over. -Chieftain AlexUser Chieftain Alex sig.png 18:33, 10 October 2022 (UTC)
Oh. I would have guessed it would be an applied backup. But it does make sense that it would be that way for testing new MW releases. To bad it also doesn't load propperly there then. Nightsky (talk) 16:59, 11 October 2022 (UTC)

Yes Pages previously parsed are reverting to printing their SMW wikicode[edit]

I'm finding instances where pages are:

1) initially printing their smw wikicode e.g. the text {{#set:Has context=Trait}}.
2) after the first purge, they are parsed correctly, and the page appearance returns to normal. Properties may or may not be set correctly on the Special:Browse subpage.
3) returning to the same page a few days later, the page has reverted to the first statet.

At a rough guess, the cache (which I think is 24 hours) is being invalidated and the new version of the page is queued up - I think normally this is fine, and the wiki would catch up and seemlessly recalculate the page output, but perhaps the queue is so damn long it doesn't seem to redo the page at the moment. I'm wondering can we temporarily turn up the duration that individual pages are cached for (say from 24 hours to 2 weeks).

Alternatively it could be that there's a short term storage method which is working but a long term storage which is insufficient, or it could be this again. -Chieftain AlexUser Chieftain Alex sig.png 16:17, 24 September 2022 (UTC)

I wonder if this is another server interfearing. Or something similar to this anyways. Either way, it lends itself to a similar script for finding pages that didn't parse, as those are not only missing a NewPP Limit Report line along the lines of [SMW] In‐text annotation parser time: 0.002 seconds and have a cache key indicating that their the canonical version (Which i'd guess is shown as a backup to the date versions due it apperently failing at the apperently existing SMW parser hook already?), but are also missing something that can be tested for with js.

The script:

var r = mw.config.get("wgPageParseReport");
if (r.smw) {
	// The current page is looking normal.
	// Look for another page.
	document.querySelector("#n-randompage a").click();
} else {
	// The branch it should not get into.
	console.log(r);
	// Things that seem common accross all affected pages.
	console.assert(!r.smw, r.smw);
}
Though this only works for locating pages that weren't parsed in the first place. This does not work to locate pages that indicate that they were parsed, but that do not set their properties regardeless; such as is the case with the Rare Collections page at the moment. Nightsky (talk) 17:25, 24 September 2022 (UTC)
Added abusefilter rule to prevent template/property namespace edits to try and minimise broken pages. See community portal post. -Chieftain AlexUser Chieftain Alex sig.png 19:49, 11 October 2022 (UTC)
Rule mentioned above is switched off/deleted. For the time being I believe this change was successful, as in spite of editing/purging a huge number of pages today, I haven't seen this error once. -Chieftain AlexUser Chieftain Alex sig.png 00:09, 30 November 2022 (UTC)

Unparsed pages after null edit[edit]

User Kvothe Unparsed page.jpg

Seems purges, null edits and pages entering the MediaWiki job queue do sometimes not parse their page content before being cached (by PHP). Resulting in broken page appearance (see image), SMW properties and subobjects not being created (and previously created SMW data to be marked as outdated). Which also causes empty queries on other pages (Category:Pages with empty semantic mediawiki query results). The section above "Empty or incomplete SMW queries" mentions how to fix these pages. But when templates are edited the pages transcluding/using said template are put in the MediaWiki job queue for background updating. Which causes those pages to loose previously stored/restored data as the entries are marked as outdated but new data is not created because the page is not parsed correctly.

Manual purges and null edits are made in a limited number and do not seem to cause unparsed pages. Using a bot (null edits) or the editing widget "Purge (secondary data)" creates unparsed pages reliably. (Editing widget can be run a second time with just "Purge" to fix page appearance.)

We are currently investigating this issue. —Kvothe (talk) 12:10, 28 September 2022 (UTC)

This morning the page for Glob of Ectoplasm appeared broken (like the screenshot). Yesterday I repaired this page by added missing content by purging (twice) linked pages (for example the page of the Skritt trader that sells Provisioner Tokens for Glob of Ectoplasm). At the end the page looked fine. Today it didn't. I just purged the page twice and it looks fine again, but this makes me wonder if it makes sense to repair pages if they are broken the next day. The usability of the wiki is really hurt by this issue. Rose Solane (talk) 09:53, 5 October 2022 (UTC)
Almost every page seems to have this problem now. Purging the page (once) solves the issue for a page, but purging every page you want to look at is really annoying. Rose Solane (talk) 12:38, 5 October 2022 (UTC)
If you're using Chrome, go to https://wiki.guildwars2.com/ and then enable Developer's Tools by pressing F12. Hold the refresh button, then select "Empty Cache and Hard Reload". That should clear this site's cache. The preceding unsigned comment was added by 136.158.11.241 (talk) at 07:13, 9 October 2022‎ (UTC).
This is still bugged as of now, when will you fix the wiki?! The preceding unsigned comment was added by 87.11.34.111 (talk) at 23:15, 17 October 2022‎ (UTC).
We understand your frustration as we're all experiencing it, too. Unfortunately, we've not been able to find the exact cause of the problem, which means we cannot give an estimate for when it will be fixed. Greener (talk) 23:19, 17 October 2022 (UTC)
I'm not sure we - without backend access - can figure out what exactly's the cause of this (Not to even mention fixing it; without any way to alter the code/systems that may be at fault.), given this seems likely to be a backend problem. And the only ones with backend access being ArenaNet. (As far as i'm aware at least. (Certainly would make sense with them being the ones hosting/providing the wikis infrastructure at least. (And them having introduced the /wiki command.)))
That mentioned, could the sitenotice possibly be changed to "ArenaNet are investigating the ongoing issues." or something simillar; since we can't exactly do a lot (aside from poking them even more about it, i suppose)? Might help with people asking us, instead of ArenaNet, to fix the wiki too. (Which would be great if that could happen by the way ArenaNet. At the very least another update (See here for the first one (on the wiki).) on the situation would be great. (Not that anyone of them is likely to read that here, but i'm frustrated by the situation too regardeless.)) Nightsky (talk) 15:33, 18 October 2022 (UTC)
There's been another update from ArenaNet/Stéphane (on the wiki) here. (See the last message in the there linked to "Template errors"-section.)
Should the sitenotice maybe be updated to link to there directly too?
Also, maybe so it includes a mention of the notice being used for ongoing, if infrequent, updates (Or relaying them, as applicable; i suppose.); so hiding it would not be reccomended too, provided that's the case, which i'd assume it is? Nightsky (talk) 15:14, 1 November 2022 (UTC)

Unbound magic currency page is broken[edit]

Unbound magic currency page is broken

Unbound Magic

Looks like some sort of formatting issue.

Volatile Magic

Looks also to have a similar formatting issue. The preceding unsigned comment was added by 84.68.38.225 (talk) at 22:12, 22 October 2022‎ (UTC).

They're fine now, so it was a parsing issue, same as extensively noted above and in the site notice. -Chieftain AlexUser Chieftain Alex sig.png 08:29, 23 October 2022 (UTC)

No Empty or incomplete SMW queries[edit]

Description
Problem
  • The recent SMW upgrade to version 4.0.2 reset the whole database and therefore the queries asking for those properties may be empty. Hence you might see something like: "This item is not contained in any container." or "No results for sold by."
How to fix it
  • This can be fixed by using the Purge button on the top (only visible to logged-in wiki editors) or by adding ?action=purge in the address bar.
    • First, make sure that the properties on the wanted pages are stored correctly by purging the pages. Therefore, go to the pages that should be shown in query (obviously for large queries this is a non-trivial task, sometimes Special:WhatLinksHere can help).
    • Second, purge the page with the query.
    • In most cases this should fix it, if not feel free to report it here.
Example
  • Let's say we are on the page Mithril Ore and the section Contained in isn't showing the container Large Loot Bag.
  • First, we go to the page Large Loot Bag and hit the purge button to properly set the SMW properties.
  • Second, we go back to the page Mithril Ore and again use the purge button.
Notes
  • Sometimes SMW queries are self-referencing and relying on properties of their own page, then one has to purge twice.
  • Alternatively, one can also use a mw:Null edit to purge the page (simply click edit and then save changes without performing any edit, note that you won't show up in the page history) or even combine a purge and a null edit to be sure that the properties and queries are working as intended.

I combined all SMW related bug reports in this section. --Tolkyria (talk) 09:11, 28 September 2022 (UTC)

Perhaps it may be a good idea to add to the message on every page that "If you experience problems, purge the page (twice max) to see if that solves the problem. If not, please report it ander Article Feedback" or something alike. I keep running into pages that fixed themselves after a purge. Disconnect (talk) 02:05, 30 September 2022 (UTC)
While this is the way to fix these problems, we do not currently recommend it openly to not waste anyones time since pages can "break" again due to the issues detailed in the next section ("Unparsed pages after null edit"). —Kvothe (talk) 22:27, 2 October 2022 (UTC)
Note this is probably still an ongoing issue, but I've archived many of the repetitive bug reports to Guild Wars 2 Wiki:Reporting wiki bugs/archive_12#Empty or incomplete SMW queries (not useful to display them all here).
Please however continue to create topics with === heading text === to report further bugs. -Chieftain AlexUser Chieftain Alex sig.png 00:16, 30 November 2022 (UTC)

No "|+order=" not sorting as expected[edit]

When looking at the currency for table on Imperial Favor, the sorting seems to sort the "250 Research Note" & "125 Imperial Favor" and "300 Research Note" & "150 Imperial Favor" entries in the order as just listed here, instead of the other way around, as'd be expected given the |+order=asc found in the {{vendor query table}}.
I can give the following queries/tables as more minimal examples (compared to the aforementioned template):

Has item cost
200 (Imperial Favor)
200 (Imperial Favor)
200 (Imperial Favor)
200 (Imperial Favor)
20000 (Imperial Favor)
500 (Imperial Favor)
1000 (Research Note), 2500 (Imperial Favor)
1000 (Research Note), 2500 (Imperial Favor)
1000 (Research Note), 2500 (Imperial Favor)
1000 (Research Note), 2500 (Imperial Favor)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
75 (Imperial Favor), 150 (Research Note)
250 (Research Note), 125 (Imperial Favor)
300 (Research Note), 150 (Imperial Favor)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
75 (Imperial Favor), 150 (Research Note)
250 (Research Note), 125 (Imperial Favor)
300 (Research Note), 150 (Imperial Favor)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
75 (Imperial Favor), 150 (Research Note)
250 (Research Note), 125 (Imperial Favor)
300 (Research Note), 150 (Imperial Favor)
Has item cost
200 (Imperial Favor)
200 (Imperial Favor)
200 (Imperial Favor)
200 (Imperial Favor)
20000 (Imperial Favor)
500 (Imperial Favor)
2500 (Imperial Favor), 1000 (Research Note)
2500 (Imperial Favor), 1000 (Research Note)
2500 (Imperial Favor), 1000 (Research Note)
2500 (Imperial Favor), 1000 (Research Note)
100 (Research Note), 50 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
150 (Research Note), 75 (Imperial Favor)
125 (Imperial Favor), 250 (Research Note)
150 (Imperial Favor), 300 (Research Note)
100 (Research Note), 50 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
150 (Research Note), 75 (Imperial Favor)
125 (Imperial Favor), 250 (Research Note)
150 (Imperial Favor), 300 (Research Note)
100 (Research Note), 50 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
150 (Research Note), 75 (Imperial Favor)
125 (Imperial Favor), 250 (Research Note)
150 (Imperial Favor), 300 (Research Note)
Has item cost
200 (Imperial Favor)
200 (Imperial Favor)
200 (Imperial Favor)
200 (Imperial Favor)
20000 (Imperial Favor)
500 (Imperial Favor)
2500 (Imperial Favor), 1000 (Research Note)
2500 (Imperial Favor), 1000 (Research Note)
2500 (Imperial Favor), 1000 (Research Note)
2500 (Imperial Favor), 1000 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
75 (Imperial Favor), 150 (Research Note)
125 (Imperial Favor), 250 (Research Note)
150 (Imperial Favor), 300 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
75 (Imperial Favor), 150 (Research Note)
125 (Imperial Favor), 250 (Research Note)
150 (Imperial Favor), 300 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
75 (Imperial Favor), 150 (Research Note)
125 (Imperial Favor), 250 (Research Note)
150 (Imperial Favor), 300 (Research Note)

The first table should have the costs sorted ascendingly by amount (i.e. as should also be the case in the table on the linked page). The further two tables are included for reference, where the costs should be sorted descendingly by amount and are unsorted respectively.
I'm guessing that this is a SMW bug. Nightsky (talk) 14:23, 22 October 2022 (UTC)

Can you clarify what you think the |+order= parameter is supposed to do? Is it supposed to sort the records returned within a single table row? -Chieftain AlexUser Chieftain Alex sig.png 08:35, 23 October 2022 (UTC)
I think it's supposed to sort the individual instances assigned to a property. (So, yes, it should sort the records returned within a single table row in the tables above. (For tables with more columns it'd of course be within a cell instead of row then.))
As a more elaborate example; considder e.g. the following assignment:
{{#subobject: example
| Has item cost = 250;Research Note+125;Imperial Favor |+sep=+
}}
This'll set "Has item cost" to two instances of the record; "250 (Research Note)" & "125 (Imperial Favor)".
Now if asked for this to be sorted in the output, it should sort these instances as specified. Considder e.g. the following query:
{{#ask: [[{{FULLPAGENAME}}#example]]
| ?Has item cost |+order=asc
}}
This should then yield "125 (Imperial Favor)" & "250 (Research Note)", in this order; sorting first by the first property in the record in ascending order and then by subsequent ones if neccessarry (though i don't think there exists a way to specifiy the sort order for record properties other than the first, so it sorting by subsequent ones may not be the case; although it does appear to work that way (See e.g. Legendary Insight#Currency for, Gift of Prowess#Sold by and Gift of Compassion#Sold by; which do seem to order ties in the first property by the next.)).
The weird thing is that it doesn't even seem to be sorting alphabetically, as otherwise 250 & 125 and 300 & 150 wouldn't always be the other way around as 1000 & 2500.
Another weird thing is that the table with the unordered records above appears to have them ordered by the second property of the record, Imperial Favor & Research Note, in that order; though i suppose that may be coincidence with them all being assigned in that order in the "vendor table row"-template on the vendor page. Nightsky (talk) 14:46, 23 October 2022 (UTC)
Did yoy see my test at User:Chieftain Alex/sandbox? -Chieftain AlexUser Chieftain Alex sig.png 15:22, 23 October 2022 (UTC)
I don't really look at pages in the user namespace unless being pointed at or pinged there, so i did not; untill reading your messages at least (which are more descriptive of the test than your message here if i may add).
I'm afraid your test still leaves 2500 & 1000 in an undesirable order, though it does seem to do fine with 125 & 250 and 150 & 300 (as well as all the pairs of different digit length); so it's certainly an improvement.
Also, since you made me check the documentation, i found that there's also n-asc and n-desc, which do seem to work as a workaround. See also the following tables:
Has item cost
200 (Imperial Favor)
200 (Imperial Favor)
200 (Imperial Favor)
200 (Imperial Favor)
20000 (Imperial Favor)
500 (Imperial Favor)
1000 (Research Note), 2500 (Imperial Favor)
1000 (Research Note), 2500 (Imperial Favor)
1000 (Research Note), 2500 (Imperial Favor)
1000 (Research Note), 2500 (Imperial Favor)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
75 (Imperial Favor), 150 (Research Note)
125 (Imperial Favor), 250 (Research Note)
150 (Imperial Favor), 300 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
75 (Imperial Favor), 150 (Research Note)
125 (Imperial Favor), 250 (Research Note)
150 (Imperial Favor), 300 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
50 (Imperial Favor), 100 (Research Note)
75 (Imperial Favor), 150 (Research Note)
125 (Imperial Favor), 250 (Research Note)
150 (Imperial Favor), 300 (Research Note)
Has item cost
200 (Imperial Favor)
200 (Imperial Favor)
200 (Imperial Favor)
200 (Imperial Favor)
20000 (Imperial Favor)
500 (Imperial Favor)
2500 (Imperial Favor), 1000 (Research Note)
2500 (Imperial Favor), 1000 (Research Note)
2500 (Imperial Favor), 1000 (Research Note)
2500 (Imperial Favor), 1000 (Research Note)
100 (Research Note), 50 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
150 (Research Note), 75 (Imperial Favor)
250 (Research Note), 125 (Imperial Favor)
300 (Research Note), 150 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
150 (Research Note), 75 (Imperial Favor)
250 (Research Note), 125 (Imperial Favor)
300 (Research Note), 150 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
100 (Research Note), 50 (Imperial Favor)
150 (Research Note), 75 (Imperial Favor)
250 (Research Note), 125 (Imperial Favor)
300 (Research Note), 150 (Imperial Favor)
Nightsky (talk) 17:22, 23 October 2022 (UTC)
I think the goal should be sorting alphabetically by the name of the cost item, not the cost amount. That way the cost column will be consistently ordered throughout the entire vendor table. So I think Alex's solution is ideal. --BuffsEverywhere (talk) 18:19, 23 October 2022 (UTC)
To be honest, that's nothing really new. SMW records are extremely unhandy to use, one can neither return them in plain format with the suffix # (e.g. plain number format for currencies, that's why we had #replace/dplreplace for some time to get rid of thousand seperator, later switched to text property), nor use the suffix |+order properly (applies to first record field only), nor use something like |+limit or |+offset (there it get's extremely strange, at least the last time I tried it). Furthermore, although text properties are sorted numerically due to Guild Wars 2 Wiki talk:Requests for technical administration#Sorting pages with numbers, this doesn't apply to record fields when using |+order=asc (|+order=n-asc works though). Hence one can't also use numerical comparison operators on record fields (such as > greater equal, >> greater, < and <<), these are still using string comparisons which returns numerical nonsense results.
Alex solution isn't sorting alphabetically, it's just displaying how it is stored in the vendor table row. The only way to sort it alphabetically would be to swap the properties of Has item cost to Has item currency, Has item value (which at this point would be insane to do) to get the currency in the first position and then use |+order=asc.
Also sorting numerically by the currency value makes no sense, for example try, it returns a different currency order for different items:
{{#ask: [[Sells item.Has armor set::Triumphant Hero's armor (light)]]
| ?Sells item
| ?Has vendor
| ?Has item cost|+order=n-asc
| class = wikitable sortable mw-collapsible mw-collapsed
| format = table
| mainlabel = -
}}
So I think right now the best is to leave it as it is and use the original subobject order which relies on the wiki input. --Tolkyria (talk) 18:51, 23 October 2022 (UTC)
I'd have managed to suggest reversing the order of the properties in the record and point out that Alex's table is like sorting the unsorted table above by clicking on it's header, albeit lacking the subobject column, but that'd have been about it; so i'm glad that you pitched in with all the additional information.
One thing i'll have to contest though is that the results are returned in the order they were set, as i don't think that's guaranteed to be the case. (Hence me using coincidence above, since i think it is one. (Which is unfortunate; would have certainly be a simpler solution than reversing the properties of the record.)) To give an example; it has been pointed out that the currency order in this table was a jumbled mess (before the order was specified), even though they all were set in the same order on the vendor pages or the templates thereon, as applicable. See e.g. the following query, where the first entry has the currencies the other way around as they are specified, at least at present:
SubobjectHas item cost
Portable Magnetite Shard Exchange/Bastion of the Penitent#vendor5250000 (Coin), 25 (Legendary Insight)
Portable Magnetite Shard Exchange/Salvation Pass#vendor6025 (Legendary Insight), 50000 (Coin)
Portable Magnetite Shard Exchange/Spirit Vale#vendor5325 (Legendary Insight), 50000 (Coin)
Portable Magnetite Shard Exchange/Stronghold of the Faithful#vendor5725 (Legendary Insight), 50000 (Coin)
Scholar Glenna (Bastion of the Penitent)#vendor9125 (Legendary Insight), 50000 (Coin)
Scholar Glenna (Salvation Pass)#vendor9925 (Legendary Insight), 50000 (Coin)
Scholar Glenna (Spirit Vale)#vendor9225 (Legendary Insight), 50000 (Coin)
Scholar Glenna (Stronghold of the Faithful)#vendor9625 (Legendary Insight), 50000 (Coin)
And, yes, n-asc wouldn't make sense everywhere, but it'd have been something easily possible; though i'd prefer sorting by name first as well. I agree that it'd not be a good time to do it now though, given the still fragile state of the wiki. I'm rooting for ArenaNet to figure out and fix what's wrong in the near future. Nightsky (talk) 15:01, 24 October 2022 (UTC)
Actually, i think it was this table instead. So the following query applies more:
SubobjectHas item cost
Portable Magnetite Shard Exchange/Bastion of the Penitent#vendor5250000 (Coin), 25 (Legendary Insight)
Portable Magnetite Shard Exchange/Salvation Pass#vendor6025 (Legendary Insight), 50000 (Coin)
Portable Magnetite Shard Exchange/Spirit Vale#vendor5325 (Legendary Insight), 50000 (Coin)
Portable Magnetite Shard Exchange/Stronghold of the Faithful#vendor5725 (Legendary Insight), 50000 (Coin)
Qadim's Portable Magnetite Shard Exchange/Exchanges#vendor325 (Legendary Insight), 1 (Eldritch Scroll), 50 (Obsidian Shard), 1 (Cube of Stabilized Dark Energy)
Qadim's Portable Magnetite Shard Exchange/Exchanges#vendor4150 (Legendary Insight), 1 (Gift of Complex Emotions), 1 (Gift of Desert Mastery), 6 (Ball of Dark Energy)
Scholar Glenna (Bastion of the Penitent)#vendor325 (Legendary Insight), 1 (Eldritch Scroll), 50 (Obsidian Shard), 1 (Cube of Stabilized Dark Energy)
Scholar Glenna (Bastion of the Penitent)#vendor4150 (Legendary Insight), 1 (Gift of Complex Emotions), 1 (Gift of Desert Mastery), 6 (Ball of Dark Energy)
Scholar Glenna (Bastion of the Penitent)#vendor9125 (Legendary Insight), 50000 (Coin)
Scholar Glenna (Hall of Chains)#vendor325 (Legendary Insight), 1 (Eldritch Scroll), 50 (Obsidian Shard), 1 (Cube of Stabilized Dark Energy)
Scholar Glenna (Hall of Chains)#vendor4150 (Legendary Insight), 1 (Gift of Complex Emotions), 1 (Gift of Desert Mastery), 6 (Ball of Dark Energy)
Scholar Glenna (Mythwright Gambit)#vendor325 (Legendary Insight), 1 (Eldritch Scroll), 50 (Obsidian Shard), 1 (Cube of Stabilized Dark Energy)
Scholar Glenna (Mythwright Gambit)#vendor4150 (Legendary Insight), 1 (Gift of Complex Emotions), 1 (Gift of Desert Mastery), 6 (Ball of Dark Energy)
Scholar Glenna (Salvation Pass)#vendor325 (Legendary Insight), 1 (Eldritch Scroll), 50 (Obsidian Shard), 1 (Cube of Stabilized Dark Energy)
Scholar Glenna (Salvation Pass)#vendor4150 (Legendary Insight), 1 (Gift of Complex Emotions), 1 (Gift of Desert Mastery), 6 (Ball of Dark Energy)
Scholar Glenna (Salvation Pass)#vendor9925 (Legendary Insight), 50000 (Coin)
Scholar Glenna (Spirit Vale)#vendor325 (Legendary Insight), 1 (Eldritch Scroll), 50 (Obsidian Shard), 1 (Cube of Stabilized Dark Energy)
Scholar Glenna (Spirit Vale)#vendor4150 (Legendary Insight), 1 (Gift of Complex Emotions), 1 (Gift of Desert Mastery), 6 (Ball of Dark Energy)
Scholar Glenna (Spirit Vale)#vendor9225 (Legendary Insight), 50000 (Coin)
Scholar Glenna (Stronghold of the Faithful)#vendor325 (Legendary Insight), 1 (Eldritch Scroll), 50 (Obsidian Shard), 1 (Cube of Stabilized Dark Energy)
Scholar Glenna (Stronghold of the Faithful)#vendor4150 (Legendary Insight), 1 (Gift of Complex Emotions), 1 (Gift of Desert Mastery), 6 (Ball of Dark Energy)
Scholar Glenna (Stronghold of the Faithful)#vendor9625 (Legendary Insight), 50000 (Coin)
Sorry about that. I think i got the tables mixed up. Nightsky (talk) 16:19, 24 October 2022 (UTC)
Fair, you got me there, I wasn't precise enough. I hope this one is correct: if you don't specify a property printout |+order, then multiple property values are returned in the internally specified order. For some reason the internal order may not rely on the specified wiki order. The internal order can be viewed when using Browse properties and navigating to the subobject by clicking the eye icon. However, I have no clue how this happened in your example with Portable Magnetite Shard Exchange/Bastion of the Penitent#vendor52, even checking the history yields no reasonable result how this could have happened.
A different approach, that at least could be reproduced, to mess up the property order (haven't tested it today, I hope it still applies):
  • Set the property values A, B and C to one property. In general the property would store "A, B and C" for this property.
  • Remove property value A, then in general the property would store "B and C".
  • Readd property value A, since B and C are already set, they are ignored and the property would store "B, C and A".
This might partially explain currency order mismatches, however, I'm not sure if this still holds after a complete SMW database reset.
--Tolkyria (talk) 17:50, 24 October 2022 (UTC)
All i can tell you for sure on that is that i don't have a counter example to it.
I've no clue how it could have happened there either. I have a wild theory though, in that it may sort them by some hash of the values, that for whatever reason may include the subobject name, that just happens to make them sort the other way only on that page. Also another one, in that it might be that way due to one of the currency pages not being known to SMW at one point, due to it sometimes seeming to forget at the moment, at that having stuck with that one page.
If that works to have them scrambled then that makes it seem like there are some tests SMW does to determine already existing property values, not recreating them, likely having them retain insertion order; then just returning them in that order later. Nightsky (talk) 18:59, 24 October 2022 (UTC)

No Widget bug[edit]

I guess the widget counter variables that should prevent duplicate widget code caluclations are now incremented globally again rather than locally, which causes some trouble when loading widgets (namely execute the widget code only if the counter is equal to 1 in order to prevent duplicate code calls; globally incrementing the counter results in larger-than-1-counters even for the first call on the page and thus the code execution is skipped).

For example one can find <span class="gamelink" id="gamelink-311" data-type="item" data-id="98091" title="98091"></span> where the intended id actually should be id="gamelink-1". Thus I assume after large-scale template edits widgets like game link probably won't work until the page got purged again.

See also Guild Wars 2 Wiki:Reporting wiki bugs/archive 11#Widgets stop working. --Tolkyria (talk) 20:59, 29 November 2022 (UTC)

Thanks for the report, I've added some tracking javascript to my personal js to see if I can spot occurrences where this happens. -Chieftain AlexUser Chieftain Alex sig.png 21:27, 29 November 2022 (UTC)
Greener asked me to go and purge the pages which were using the recipe template which didn't have categories/semantic properties (109 pages). After I did the "secondary data purge", I noticed that almost all of the affected pages were triggering the bug you described, so I took a screenshot. -Chieftain AlexUser Chieftain Alex sig.png 23:39, 29 November 2022 (UTC)
Widget:Game link rewritten - no more global functions; each chat link will now embed the script code but it can't really be helped. I think this will make the chat links work in most instances. -Chieftain AlexUser Chieftain Alex sig.png 22:24, 30 November 2022 (UTC)