Guild Wars 2 Wiki:Reporting wiki bugs/archive 12

Not actual bugs

Bugs related to API being unavailable from 28th February for 48 hours

Pre-emptive topic to capture any widgets/API is broken complaints. The API has been taken down for 48 hours around EoD release. -Chieftain Alex 17:35, 27 February 2022 (UTC)

srcset attribute missing for images on mobile devices

Following discussion on Discord (issue initially mentioned by User:Mattt), it appears that there is a phabricator ticket which details how the srcset tags are stripped out by mw:Extension:MobileFrontEnd for mobile viewers. On high resolution devices, this has the effect of rendering images as slightly blurry. Paraphrasing the phabricator wall of text; srcset attributes historically resulted in images being downloaded twice from the server - this was fixed in browsers years ago - however the mediawiki mobile code still removes the tags which exist on desktops as a kind of "optimisation" which is no longer required.

Examining the extension source, there is a parameter named $wgMFStripResponsiveImages which (if you search for "StripResponsive" in the extension source) seems to switch off the removal of srcset. I suggest we add the following to localsettings.php:

## Extension:MobileFrontEnd - workaround for https://phabricator.wikimedia.org/T293303
$wgMFStripResponsiveImages = false;

-Chieftain Alex 15:20, 5 August 2022 (UTC)

To confirm the results of when this was applied to a test wiki, the extra images in the srcset attributes are correctly added when this variable is set (change not currently deployed to this wiki). -Chieftain Alex 17:41, 11 August 2022 (UTC)

Note: this will be applied at the same time as the Monday 1.38 upgrade. -Chieftain Alex 08:34, 10 September 2022 (UTC)

Not an actual bug, part of the baked in extension behaviour. Documented in GW2W:TECH request. -Chieftain Alex 12:47, 11 September 2022 (UTC)

Resolved

Forbidden 403

We had a wiki security upgrade this morning. If you receive "Forbidden 403" error on page preview or saving (or any other time really) please add the pages to the list below so we can resolve them. —Kvothe (talk) 13:35, 9 February 2022 (UTC)

• 1 Guild Wars 2 Wiki:Reporting wiki bugs
• 1 Hidden chest (Bastion of the Penitent)
• 1 Hero's Canton
• 1 Widget:Which profession
• 1 searching style="
• 1 Guild Wars 2 Wiki:Projects/Shared Model Project/I - sections Imp and Insects on preview
• 1 Guild Wars 2 Wiki:Projects/Shared Model Project/Other Groups editing page and sections "Aetherblades" and "Order of the Crystal Bloom" works; the other sections return the error on preview
• 1 Category:Pages with ignored display titles category members can not be deleted
• 1 Discord embeds - resolved

Can i somehow add all API requests made with a User-Agent that is not like "a normal browser"-probably to this list? If so, please considder them added, because while i'm only using a few parts of the API it might be that all of them would be blocked if i were to try to use any other but this seems to be what is interfearing with my bot workings as it is. Or, alternatively, since removing the security upgrade again would probably be anywhere from unwise to impossible to do; what's the prefered way to work around this? Also, side note: Did this bring a vary: Treat-as-Untrusted header value to sucessfull requests? Or was it there before already and i only didn't notice? (Also, technically i'm getting a "403 Forbidden" (which technically is incorrect too as there's somemore html to it too of course (and also headers and all that comes with http)), so the number and the text the other way around, but i guess it's verry likely the same thing.) Nightsky (talk) 15:51, 11 February 2022 (UTC)

Nightsky, I could use some more details to help me determine how best to tune the recent security changes to allow for your bots to work. For starters, the user-agent string and, if possible, a source IP address for your bot would help me find out what's blocking the requests. If you don't want to post it here, you should able to email me directly using the "Email this user" link on the nav bar from my user page. Justin Lloyd (talk) 16:03, 11 February 2022 (UTC)

Nightsky, I got your email. I do see that some of the requests get through but some are blocked as non-browser user-agents. I do see the Java UA string being blocked by a bot control rule and another "python-requests" UA being blocked for the same reason. I'm trying to figure out how to handle this in a manageable way, so for example I could create a list of your bots' IPs and allow those through, but if those can change, that wouldn't work long-term. I'm still digging and thinking, though. If you were to customize your UA strings in some standard way, that would be one approach. Justin Lloyd (talk) 17:53, 11 February 2022 (UTC)

Oh, the python UA, while being one of my scripts running periodically (Hourly, in this case.), is unrelated to the bot, so can be ignored for the purposes of allowing the bot. (I might just change that one; or maybe even stop it alltogether. Will have to think about it.)

The IP list wouldn't work all to well then indeed as my IP usually changes at least once a day and i've simply been runing the bot off of my pc so far.

I can probably come up with a standard way for the UAs.

Alternatively i could see to implement the workaround i've found everywhere. While i don't know if that'd be the prefered action?, it at least seems like it could make things work again. Nightsky (talk) 20:03, 11 February 2022 (UTC)

Is your workaround reasonable to you or do you feel it's unnecessarily complicated? I've continued to review the logs and the specific rule that's blocking some of your bots' requests and I can't see a clear way to just allow yours without allowing lots of potentially malicious bots as well. Certainly providing a string in your bots' UA header that is easy on which to filter would be an ideal solution from my perspective. That said, I'm happy to continue working with you on this to a mutually satisfactory resolution. Feel free to continue using this thread to discuss the issue and/or email me directly as before, as I keep a close eye on both. Justin Lloyd (talk) 21:08, 11 February 2022 (UTC)

Hi ! Aralicia here, caretaker of the discord bot for discord.gg/guildwars2. The python UA might come from my own bot, as it queries the wiki on demand, in most case by doing an opensearch with a keyword given by the user.

If I'm understanding correctly, the new security filter is based on User-Agents ? Does it means that if my bot were to immitate a browser's UA, it would be able to go access the api without issues ? Or would you prefer for it to produce a unique UA that you can allow in ? Aralicia (talk) 11:31, 12 February 2022 (UTC)

The workaround is rather uncomplicated. It's more that i'm not sure if it's the best way to handle this; as it feels like circumventing the "security", in a way; so i figured i'd ask what the prefered way would be.

Well if we're going for something that works mutually; while i can do so should it end up being necessary, i'd rather not want to include a fixed part in the UAs if possible. To that end i've had an idea. While so far my bot wasn't logged in as such while performing the requests, simply as this normally isn't necessarry for reading from the API; how would allowing for login with bot passwords and using them as a means to allow bots to read/write/useTheApi do? (It would seem like this could make for a simple way to filter out bad actors at least.)

While i'm guessing we'll probably have to wait untill monday for a response; what i can maybe add in the meantime would be as follows: At least to me it seems unlikely that the first mention of the python UA above refered to yours, as i've included IP addresses alongside the UA (i, not thinking of the python script while working out the bot, had included only the Java UA of the component that was immediately running into the problem in the mail) and would think that they were used to filter out my requests only. Based on this, while i can't confirm it myself in any way, the first mention is likely to refer to my requests (That is one once every hour.) only. Nightsky (talk) 18:02, 12 February 2022 (UTC)

Hi, Aralicia: The new filter is a web application firewall, which allows monitoring and filtering of web requests on a wide-range of conditions, including IP addresses, HTTP headers, etc. The User Agent header is simply a convenient attribute, though it's obviously not a 100% solution since it's easily "spoofed" as well. However, I'm just not seeing any other consistent and manageable way to allow these legitimate wiki bots through the specific set of rules whose heuristics are designed to allow for valid bots (e.g. search engines) while attempting to prevent malicious bots. If I come up with any other ideas, I will certainly reach out to you. Thank you for your message! Justin Lloyd (talk) 12:25, 14 February 2022 (UTC)

Thanks for answering Justin Lloyd ! As Nightsky mentionned in his response to me, would being connected (to the wiki) bypass the security ? In that case, a solution could simply be to have dedicated accounts for the bots, so they can be both allowed in, and individually tracked when making their queries. I'm sorry if this idea doesn't work, I must admit that while I have experience with webdev, I never really looked into MediaWiki. Aralicia (talk) 13:59, 14 February 2022 (UTC)

Aralicia, I am aware that there are bots with accounts, so if changing your bot to work in that same fashion is feasible and appropriate, then I think that may work fine. Please feel free to set that up and see if it works and let me know how it goes and whether it requires any further work on my side. Justin Lloyd (talk) 14:55, 14 February 2022 (UTC)

Nightsky, as in my response to Aralicia, right now the User Agent string is the only way I'm seeing to recognize and allow your bot through the firewall. That said, I am continuing to review the firewall's documentation to see if there are features I can leverage for a better approach. However, I do have a related question, but I'm going to email you separately about it. Justin Lloyd (talk) 12:25, 14 February 2022 (UTC)

A slight note with regards to the bots with accounts above: If Aralicia were to change their bot, that wouldn't make it work, since, in order to login as a bot, one has to make it to the login APIs; which are behind the firewall.

Only solution i could see that could make it work that way would be to completely disable the firewall for the login APIs and have them deal with logins and then use the resulting login information (the cookies, probably) to allow access to the other APIs. Which i'm not sure the firewall could even do as it would require keeping track of the state. (And also thought would have indirectly been no-ed already, for lack of inclusion/mention in response.)

Partially unrelated: It feels unusuall to have multiple "threads" at the same level of indentation instead of it always increasing (even if that means "threads" intermingle each other). Nightsky (talk) 20:29, 14 February 2022 (UTC)

Sorry for the bad indentation. Let me keep digging into the WAF and see what I can come up with regarding your suggestion. Justin Lloyd (talk) 20:42, 14 February 2022 (UTC)

Oh no worries. It's not bad; only unusual for this wiki.

Using discord to hash things out sounds good; apart from me not liking discord; though i'd be willing to join it again (i'm not even in the channel at the moment, which i can say here, even though i'm not sure which is meant, as i'm not using it at all at the moment, so it applies to all channels), if only for a short while, in order to do this. I'll have to see about doing that though; but i might see to figure it out some time later.

Then again, idealy the solution would not require secrecy of the mechanism involved, so discussing it here should work too. That would also allow to document it here on the wiki somewhere, so it's not obscure to most everyone, once we decided on something that would work. The current "solution", at least to me, would seem like it would satisfy that criteria; as does the above proposed UA solution. (This is assuming the string provided in the UA is something that is unguessable/secret to others. Which i assume the random (like generated once, not random every time) value that i would have put would have facilitated.) So, can't we discuss it here? Nightsky (talk) 18:40, 15 February 2022 (UTC)

You're absolutely welcome to discuss it here in the wiki, I wasn't looking to control the conversation or anything, rather just me erring on the side of caution with my initial idea. Justin Lloyd (talk) 18:54, 15 February 2022 (UTC)

In that case, I'll post again what I sent previously by mail :

Personally, I think that, should we use a custom header, it should have at least two elements :

- An identifier, whose only purpose would be for a human to be able to easily identify the (supposed) source of the call.

- A token that serves a similar use as the token in a bearer autenthication. This would allow, in case the header content gets compromised, to be able to keep the identity string while generating a new token.

So we'd get a header that could like something like "X-CustomHeaderName: MyBot/590623f039ef6e251ed535213901886d", where "MyBot" is the bot's identifier and the string after the / is the token.

On Justin's side, he'd only have to whitelist a identity+token value for each bot that needs to be whitelisted, and if something goes wrong, can simply remove the entry that causes issues, and whitelist a new one after talking with the bot owner.

On our side, we'd have to send that identity+token couple with each query, and take care to not put those somewhere everyone can see them (in my case, since the code is publicly available on github, I'd probably store them as env variables).

What do you think ? Aralicia (talk) 22:08, 15 February 2022 (UTC)

For what it's worth, it's not exactly word for word the text that i can see in the mail that made it to me. (I'll leave a SHA-512 hash of the message that made it to me in a comment (see source) here: .)

Sounds good to me. And, for what it's worth, it's similar to one of my suggestions too; except i had suggested two headers, one for the <bot name> (Which seems to be synonymus to your "identity"-term.) and another for <a, unguessable to other parties, value> (Which i would have termed key or ID, but which otherwise seems to be synonymus to your "token"-term).

Additionally, let me list the alternatives i had also suggested (similarly previously only in a mail to Justin), if in a less alaborate way than now, for completeness and evaluation by everyone here too:

1. I was thinking maybe it would be possible to use TOTPs in requests, derived from the key (so as to not have to include the key in requests) instead of sending the key itself; though i don't know how that would have worked out with the 30 sec window, and it would also not be trusting the connection to the wiki, which i suppose is technically void due to TLS.
2. Additionally maybe it would be possible to use API keys or subtokens in a way. Though this would require the firewall to interact with the API. For that it could allow for allowing users based on their accounts and have them generate API keys or subtokens in a specific way (e.g. with a specific name) for use in requests then and what not. Though this seems like it might just be more complicated than a bearer like approach too and pretty much void as such. Or not, i don't know, depends on which components one trusts really, and i simply wanted to include it here too, even if it's maybe useless.

All in all, i can agree on using a concatenated form of <identifier>/<token> as above. Altough i'd (as, while i can't quite tell since it's rather vague, you may have implied to me in the mail already) propose we use the existing Authorization header, instead of a custom one; and make up a custom scheme, possibly designated "GW2W", and use that with the concatenated value for a combined result of, to use the example above, "Authorization: GW2W MyBot/590623f039ef6e251ed535213901886d", and use that in requests. The first request could then additionally possibly additionally contain a separate value in an additional header (Maybe "X-Nonce"?) that could then be replicated here (possibly including the time and or other details of the request to narrow things down, although, depending on how easy it would be to pick out the request from that, it might not be necessarry), after first having performed a request, which Justin could then look for and allow for the associated Authorization header to pass; with the header essentially acting as Authentification via the wiki for both transparency and in lieu of requiring mail. Thoughts on this? Nightsky (talk) 15:11, 16 February 2022 (UTC)

Sounds like you two are coming up with something incompatible with conventional bot tools like AWB? -Chieftain Alex 17:31, 16 February 2022 (UTC)

I'll admit i have not looked into it, so i don't know. (Part of me was also thinking it might be allowed through as it's semi automatic, if not used automatically at least which i think is possible to in some way. (Then again didn't look into it the bot to much and can't test it.))

But we could surely make that four people (Justin's been involved in this discussion too already and it's a public discussion too after all too.) coming up with a solution, if you don't mind helping out? Since you're using it, as far as i'm aware at least, you'll likely know best what it can or can't do out of us (I can only say that this holds true for me, can't really speak for anyone else of course.) after all. Nightsky (talk) 18:25, 16 February 2022 (UTC)

I indeed reworded and expanded on some part of the mail as I pasted it here. The core of the idea stayed the same, though.

I do agree that I'd rather use a custom method with the Authorization token, however I'm uncertain that it would be compatible with the firewall or host, as its a header with predetermined behavior. If possible, I'd prefer it; if not, a X header would do the tric.

I'm not sure about using the an additional header. While it would help with security, it would/could complicate things, and I'm not sure how much control Justin has on the process. If you want authentication, a bot could always use the normal login process after going through the firewall; so I'm not sure that Authentication and Authorization needs to be done at the same time.

Concerning AWB : Is it currently blocked by the firewall ? Because if it isn't, there's no reason for concern. The current discussion is not to add extra restrictions on the current firewall; but giving a way in for selected bots that are currently blocked out.

Aralicia (talk) 09:05, 17 February 2022 (UTC)

It seems to be indeed. I wanted to make clear though that it's not word for word exactly the same, since it wasn't explicitly specified but could have been read/understood that way; and no one but me could have told otherwise, so i felt like i had to make it clear.

Your probably right. The whole WWW-Authenticate header interaction could be a problem. But i can't tell.

The additional header i only suggested for use once for establishing the token. Justin will have to be able to tell what to allow through in some way. And while we could say we simply mail him the token (or the identity/token pair) to allow; this would instead see us include the additional header with some unguessable value in a request, alongside the Authorization header in the format as discussed above. Then, once the request has been performed, we would replicate the value of the additional header here, which would alow Justin to look for the first (should there be multiple) occurence of that specified value and would authenthicate the associated Authorization header; without the need for the header to occur in any other place (e.g. mail) than where it is intended to occur. This only requires trust in the TLS connection, which the bots would use either way, and not also in mail; further removing the need for mail, so that anyone else who may want to use a bot in the future would not need to set one on the wiki. And the wiki APIs, while being behind a firewall now, are still public. That's a MediaWiki thing; and while there may be a switch for making all of those require being logged in, it'd be behind the firewall already and thus probably wouldn't exactly help to prevent it from getting hammered, if with failing requests, which would seem like something the firewall is meant to deal with. Nightsky (talk) 15:45, 17 February 2022 (UTC)

I see. I didn't understand that the second header was there to allow us to inform Justin in a public setting without revealing the auth token. That's a good idea, then. How should the headers be named ? X-Authorization for the authorization token and X-Auth-Request for the additional header ? Aralicia (talk) 18:19, 17 February 2022 (UTC)

I'd go for X-Authentication in place of X-Auth-Request, since Auth could be ambigously expanded as both Authorization or Authentication and the Request part for me would be the copy on the wiki, but can agree with X-Authorization and wouldn't mind X-Authentication-Request either.

Should the X-Authorization header include the "GW2W" scheme part as well then or do we want to only use the identity/token pair; since it's a custom header already anyways? Nightsky (talk) 20:41, 17 February 2022 (UTC)

The X-Authorization header's value technically doesn't need to follow any pattern, but it could be recommended to use a GW2W id/token pattern. Based on our discussion, I wrote a quick draft of documentation Here. Does it seems ok to you ? Feel free to change wording and formating, I must say I'm not really proficient in wiki-writing. Aralicia (talk) 22:26, 17 February 2022 (UTC)

Isn't a draft maybe a little ahead of things at the moment? There's still the open question of if AWB works or not; for neither of which outcome there has been a clear indication of so far. If not, we'd have to account for it as well. Something i don't know of how it could be done as i don't know what all it can do; but from what i could see (or rather could not see) in the AWB user manual, there seems to be no way to specify custom request headers, which would make at least the current way impossible.

Alex, you don't happen to be available to check if AWB gets blocked by the firewall or not and let us know of the result? And, in case it does get blocked, do you maybe happen to have any ideas on how it could be made to be allowed through the firewall? Nightsky (talk) 17:42, 18 February 2022 (UTC)

wiki returning a 403 error upon booting AWB with gw2wiki as the default. Currently we will be unable to operate our legitimate bots. -Chieftain Alex 17:18, 19 February 2022 (UTC)

Want to say that Guild Wars 2 Wiki:Projects/Shared Model Project/I still gives the 403 error. EDIT: And W apparently too. I suspect more of the Shared Model Project pages have the error. ~Sime 23:58, 19 February 2022 (UTC)

Thank you Alex!

Well, so.. i know that i don't have an idea on how to let AWB through; so the only options i'm now seeing then would be to

1. implement the above method as a way for bots to make it for the time being and add an additional way for AWB once someone came up with one (optionally phasing out the then existing method)
2. wait for someone to come up with a mechanism that also allows AWB to pass and then implement that
3. not have bot edits anymore

but other than that i'm out of ideas on this. Nightsky (talk) 17:59, 20 February 2022 (UTC)

Sounds like it, yes. What do you recon we should be doing User:Justin Lloyd ? Aralicia (talk) 16:07, 21 February 2022 (UTC)

(Reset indent) I just noticed that automatic discord embeds are blocked too. —Kvothe (talk) 16:30, 21 February 2022 (UTC)

Is the benefit from this change quantifiable? It sounds like a significant inconvenience at the moment, can we consider the effects of reverting it? -Chieftain Alex 22:19, 21 February 2022 (UTC)

Users with a bot please check if they are working now. All but two bot rules have been changed from "block" to "count". Discord embeds work again which is promising. —Kvothe (talk) 13:30, 22 February 2022 (UTC)

If there are still any bots being blocked, in order to help me search my log data for your bots' requests, please provide as much of the following information about the bots' requests as you are able: the bot's source IP address(es), examples of the requested URLs (or URL patterns if there are potentially a lot), and the bot's User-Agent string. If you have information to provide but don't want to post it here for any reason, you can email me directly from the wiki. Justin Lloyd (talk) 17:26, 22 February 2022 (UTC)

Mine seems to be working fine again. (Though technically i did have a few requests get blocked. However those i only used for testing - and assume they may have been caused by a "malformed" UA i discovered - so shouldn't pose a problem to the bots workings.) Nightsky (talk) 17:53, 22 February 2022 (UTC)

I can confirm I can once again login with AWB. Thank you. -Chieftain Alex 18:57, 22 February 2022 (UTC)

Thanks for those confirmations. I've also made some adjustments that should have resolved the above listed issues with the "Shared Model Project" and category deletion issues. Can you confirm whether those are resolved? Justin Lloyd (talk) 19:11, 22 February 2022 (UTC)

Can confirm Shared Model Project pages do work. DJemba (talk) 19:15, 22 February 2022 (UTC)

With this being the last business day before EoD launch, I'd just like to ask if there are any further known bot-related issues? Justin Lloyd (talk) 16:01, 25 February 2022 (UTC)

In the current state all issues are resolved. —Kvothe (talk) 18:49, 25 February 2022 (UTC)

Sorry for the late answer Justin Lloyd, but my own bot (Tybalt bot for discord.gg/guildwars2) seems to still be receiving 403 forbidden errors when querying the opensearch. Aralicia (talk) 08:02, 26 February 2022 (UTC)

(Reset indent) I am a bit late to the party but I am having a 403 error through my website for the mediawiki. I run https://mymeanderingmind.com/GW2W_Easy_Mode/view_new_entries.php which is basically a quick template site for new wiki pages, and I query the mediawiki to check if page exists, if so what icon (if any) is set.

running ifconfig on my host (a server run by Linode) yields: inet 173.230.144.81

My current (php) script which queries it is a rather simplistic curl call with no specific user agent set. Looking around it seems possible to setup more or less any one I need if that's the desired solution. -Darqam 21:17, 27 February 2022 (UTC)

Aralicia, Darqam: I'm investigating your reports and I'll let you know as soon as I have more information. Justin Lloyd (talk) 11:33, 28 February 2022 (UTC)

Darqam, I believe your script is being blocked because it does not have a User-Agent header set. If you can, try adding such a header to your HTTP requests and see if that unblocks you. Justin Lloyd (talk) 13:00, 28 February 2022 (UTC)

Alright, setting user agent was indeed the key, I just wasn't sure if that slight kind of spoofing was wanted or not. For reference I set it to a good old `'Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0'` (first random one I found online). If preferred I can update it to something more user-real, but if not it will stay as is. Thanks! -Darqam 14:24, 28 February 2022 (UTC)

I do see your script's successful requests in the WAF log. FWIW, I even see when you'd just had your UA string set to "c" (as a test I presume), so if you'd like, you should be able to set the string to something more descriptive and useful (e.g. with a script name/function, version, etc.) and it should still work, so feel free to tinker with it as you like. Justin Lloyd (talk) 14:44, 28 February 2022 (UTC)

Aralicia, I haven't been able to find log entries that I could tell were your bot. Can you provide any further details about your bot that might help, like if you hvae a custom user-agent string, or a fixed source IP address, or perhaps any URLs your bot would regularly request and some approximate time frames? Justin Lloyd (talk) 12:48, 1 March 2022 (UTC)

Justin Lloyd The bot runs with the following ip : 51.255.67.18 I believe it is a static one.

During my testing, I've had it query the following URL : https://wiki.guildwars2.com/api.php?limit=11&redirects=resolve&format=json&search=eternity&action=opensearch There should be half a dozen attempts today.

Finally, it should have the User-Agent "TybaltBot/v2", although I'm not certain the code works.

So far, even when using trying to a normal browser's User-Agent, it just recieves a "403 Forbidden" from the wiki. Aralicia (talk) 13:43, 1 March 2022 (UTC)

Aralicia, I do see your bot being blocked in the WAF. For some reason, my previous searches on Tybalt weren't finding it but now they are, as is that IP address. For now, I've adjust the rules to allow TybaltBot through, as tying the check to your IP could be problematic if you need to change it in the future. Let me know if you're still seeing any problems with your bot getting through. Justin Lloyd (talk) 14:51, 1 March 2022 (UTC)

Justin Lloyd I just checked, and the request get through correctly ! Thank you very much. I will keep sending TybaltBot as part of the User Agent for future versions, so no more issue should occur. Aralicia (talk) 18:10, 1 March 2022 (UTC)

File uploads receive extra whitespace before selected licensing templates

Reported on Discord by Doodleplex.

If you upload a file, and in Special:Upload you type out the License template in the summary box, then it uploads fine and the wiki source is as expected. Example:

== License ==
{{ArenaNet image|screenshot}}

If you upload a file, and in Special:Upload you select a licensing template from the dropdown list, then an extra newline is inserted before it. Example:

<!-- extra newline -->
== License ==
{{ArenaNet image|screenshot}}

-Chieftain Alex 17:32, 2 April 2020 (UTC)

My upload created

== Summary ==
== Licensing ==
{{ArenaNet image|icon|Effect icons}}

I put == Licensing == {{ArenaNet image|icon|Effect icons}} into the upload summary field. Something might be wrong with mw:Manual:$wgUploadDialog --Tolkyria (talk) 12:15, 4 April 2020 (UTC)

Same issue exists on the Spanish wiki too. - Do_odleplex 23:26, 29 August 2020 (UTC)

Confirmed still exists in MW 1.36. -Chieftain Alex 22:31, 22 October 2021 (UTC)

Fixed with MW 1.38. -Chieftain Alex 12:47, 11 September 2022 (UTC)

Opening gallery image scrolls to top of the page upon exit

Attemping to open any image which opens in the MediaViewer gallery extension window succeeds, but upon closing the window, the scroll position is reset to the top of the page.

There is a phabricator issue which seems identical, however that issue is closed/resolved, and the issue persists in spite of us probably using the latest extension version (side note, version number not identified on Special:Version). -Chieftain Alex 17:09, 15 July 2022 (UTC)

Alex, so far my brief testing is only showing this happening on Firefox, though it might infrequently happen on Chrome-based browsers as the Phabricator issue discusses, but I haven't seen that happen, yet. It also seems to be okay so far on Safari, FWIW. The Phabricator issue also looks like it was closed with the patch that was being developed at the time having been abandoned. I don't have a solution at the moment, but I just wanted to comment on the issue. Perhaps our planned upgrade to MediaWiki 1.38 within the next few months will help. Justin Lloyd (talk) 17:43, 15 July 2022 (UTC)

workaround proposal (to be refined to firefox only at some level, probably by checking the browser string). -Chieftain Alex 23:01, 7 August 2022 (UTC)

Since you're using $ already, you may want to considder something like $.client.profile().name === "firefox" instead of the browser string. Nightsky (talk) 00:48, 9 August 2022 (UTC)

I've kind of used jquery without thinking (as usual), nothing in there really needs it - the common/monobook site js pages are however littered with it. Matt made a suggestion on discord that I should also stick a debounce delay in there between responding to keydown/wheel events. -Chieftain Alex 04:57, 9 August 2022 (UTC)

Second working version without jquery

Third but broken version with debounce - can't see why it doesn't fire.

Turns out i suck at debounce. -Chieftain Alex 20:06, 9 August 2022 (UTC)

Missed the "px" suffix off the top value lol. Anyway implemented.

Also for my future reference, trying to pass a default parameter value in the function header threw an ES6 parsing error. -Chieftain Alex 21:43, 10 August 2022 (UTC)

Justin has demonstrated that this bug stops happening in MW 1.38, so this workaround will be in place for a few months until the next upgrade. -Chieftain Alex 20:39, 11 August 2022 (UTC)

It just started happening to me today. ~Sime 02:44, 14 August 2022 (UTC)

Could be the js didn't load on the page you were looking at, similar to all other front end scripts on the wiki. (#Page requires a refresh to properly load javascript) -Chieftain Alex 07:37, 14 August 2022 (UTC)

It has happened on every single page I opened (be it a story page, outfit preview, weapon pages --and I tried many pages to test it), so idk. ~Sime 14:32, 14 August 2022 (UTC)

Ok so give me some information to go on please; browser, specific page, are you logged in, what wiki skin are you using. -Chieftain Alex 14:54, 14 August 2022 (UTC)

Browser: Google Chrome, Specific page: Many as I said, including Jormag, Boticca, Kasmeer Meade, Shiro's Legacy Outfit, Legendary weapon, Dye, Exordium, Map, Guild panel, Squad ..., yes I am logged in, skin is the MonoBook default. ~Sime 14:59, 14 August 2022 (UTC)

oh cool then, so the bug applies to chrome too: I can just remove the browser specific checks. -86.131.94.22 16:49, 14 August 2022 (UTC)

The bug reappeared yesterday again: same browser (Google Chrome), I am logged in, MonoBook default. ~Sime 22:56, 9 September 2022 (UTC)

Probably JS didn't load.

If you can wait until Tuesday, I've been informed the MW 1.38 upgrade will correct this and we can remove the JS workaround. -Chieftain Alex 08:33, 10 September 2022 (UTC)

Marking as resolved with MW 1.38. -Chieftain Alex 12:47, 11 September 2022 (UTC)

Forbidden 403

Karasu was (sporadically) unable to access the wiki yesterday.

Its suggested this has been fixed. To record what's been done on the back end, one of the firewall rules has been removed/revised (was preventing one of the AWS data centres from working). -Chieftain Alex 16:38, 1 September 2022 (UTC)

Page requires a refresh to properly load javascript

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 Alex 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 Alex 22:27, 26 February 2022 (UTC)

Still seems borked. -Chieftain Alex 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 Alex 19:25, 4 September 2022 (UTC)

Still appears to occur in MW 1.38. -Chieftain Alex 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 Alex 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)

(Reset indent) I've commented up the common and monobook javascript sheets today (tweaked some stuff too). If anyone experiences one of these bugs, please press F12 to open your console, press the print screen key, and upload a screenshot of the error log with some description of what didn't load on the page. -Chieftain Alex 18:32, 1 December 2022 (UTC)

Tested 100 pages in a row and didn't find a single broken page, feeling quite positive about this so far. -Chieftain Alex 18:44, 1 December 2022 (UTC)

Marking as resolved for the moment. -Chieftain Alex 17:41, 3 December 2022 (UTC)

Pages previously parsed are reverting to printing their SMW wikicode

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 Alex 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 Alex 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 Alex 00:09, 30 November 2022 (UTC)

Unparsed pages after null edit

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

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 Alex 08:29, 23 October 2022 (UTC)

Still bugged

Semantic query: Printout skips data

Background: I'm using a semantic query to find out which items are currently available for Black Lion Claim Tickets and for how many. In this test query on Special:Ask you can see that I try to read Has item cost.Has item value, but the column is empty for many rows. However, the combined field Has item cost always contains a proper value. This can especially be seen in the JSON version of the request - Has item cost's child property "Has item value" is correctly set, but the direct access to gives an empty result. This broke with the recent maintenance.

I don't know if other, similar, queries are broken of if this is specific to the claim ticket vendors. 79.237.181.45 11:43, 2 April 2021 (UTC)

Agree looks like a bug, somewhat odd that it appears to work fine for inline #show queries using subsets of the same data, but both #ask and Special:Ask result in the same missing data

For my later reference:

Hidden JSON

* {{#show: Black Lion Claim Ticket#vendor10 | ?Has item cost.Has item value }} <!-- should both be 1, and works fine -->
* {{#show: Black Lion Claim Ticket#vendor11 | ?Has item cost.Has item value }} <!-- should both be 1, and works fine -->

{{#ask: [[Has vendor::Black Lion Claim Ticket]] [[Has item cost.Has item currency::Black Lion Claim Ticket]] [[Is historical::false]]
 |?Has item cost.Has item value=Has item value
 |?Has item cost
 |?Sells item.Has game id=Has game id
 |?Sells item
 |format=broadtable
 |limit=250
 |offset=0
 |link=all
 |sort=
 |order=asc
 |headers=show
 |searchlabel=... further results
 |class=sortable wikitable smwtable
}}<!-- should return valid numerical results for each item, but even on the individual items which work fine above, one shows 1 and one is blank/unset -->

JSON:

    "Black Lion Claim Ticket#vendor10": {
      "printouts": {
        "Has item value": [1], <!-- OK -->
 ...
      },
      "fulltext": "Black Lion Claim Ticket#vendor10",
...
    },
    "Black Lion Claim Ticket#vendor11": {
      "printouts": {
        "Has item value": [], <!-- why is this blank -->
...
      },
      "fulltext": "Black Lion Claim Ticket#vendor11",
...
    }

-Chieftain Alex 13:40, 2 April 2021 (UTC)

Reported on discord- same bug will affect templates including Template:World boss table (ref). I'm concerned that this might be cached results on the browse page versus live results on the ask query... there's a risk if people went around purging recipe and achievement pages etc that we may not get the data working at all. -Chieftain Alex 14:42, 2 April 2021 (UTC)

Hi, we made a change this morning that could affect this bug. Could you please check again to see if it's happening? --Stephane Lo Presti talk 15:09, 7 April 2021 (UTC)

Still getting this error on the various ask printouts. -Chieftain Alex 16:30, 7 April 2021 (UTC)

The linked query still has empty cells. I noticed an interesting behaviour while testing the Ask page for the bug above, though. I added "Sells item.Has game id" as sort option. I still get the same number of results, 144, but without any empty cells. 79.237.181.45 07:22, 13 April 2021 (UTC)

I don't know if this helps, but here is the diff between the query without the specified sort option and the query with it. Justin Lloyd (talk) 20:27, 5 May 2021 (UTC)

In case anyone is wondering what the full queries are here are a few Special:Ask links producing likely the same queries for anyone interested: withouth sorting and with sorting. Nightsky (talk) 00:52, 6 May 2021 (UTC)

Interestingly, performing the same query for the vendor Gem Store and the item currency Gem with this sort-trick doesn't work, some property chain values are not returned. Not to mention that this trick isn't practical at all, namely first the sort method might not make any sense in the current context and second using sort properties restricts the result to pages/subobjects that have this property set while one is also interested in pages without this property (i.e. it basically adds [[<sort property>::+]] to the query, internally it appears as the additional INNER JOIN in the format=debug, as described by the two editors above).

So most likely in the process of obtaining the results (the order how the results are obtained) and sorting them, some subobject's property chain values are lost (one can also use the order = rand and experience that a result has the property chain value and after querying again it doesn't return a value). I guess that this is either caused by an incorrect smw dev edit between SMW 3.1.6 and SMW 3.2.2 or probably by a changed default configuration parameter. Offtopic, but SMW always had problems with property chains, for example when using them in sort combined with simple properties, e.g. sort = <property1>.<property2>, <property> internally rearranged the sort properties into sort = <property>, <property1>.<property2> (first sorting by all property chains of length 1 and then of length 2), completely ruining the intended sort order (probably the SMW devs aren't aware of such complicated query constructions). So in my opinion it's quite likely that this may be SMW bug, the question then however is how to fix it as several crucial templates on this wiki heavily rely on property chains.

I'm not sure if this would make any difference but what about changing the subobject names from e.g. #<subobject>1 to #<subobject>001 by using {{#padleft:<number>|3}}? Then the subobjects would be sorted 001, 002, 003, ..., 010, ... rather than 1, 10, 2, 3,... (which somehow always appears in this bug context). To be honest, I don't expect much from it. --91.114.175.21 12:41, 6 May 2021 (UTC)

Someone posted this at github.com/SemanticMediaWiki/SemanticMediaWiki/issues/4988, let's see what the smw devs will say. --178.191.19.52 16:46, 7 May 2021 (UTC)

That was me. :) Justin Lloyd (talk) 16:52, 7 May 2021 (UTC)

Sorry, no it wasn't, thought you were referring to a post I made to the SMW users list. Justin Lloyd (talk) 16:53, 7 May 2021 (UTC)

The more attention this gets, the better; also it's "good" to see that it affects also other wikis and not only related to this one. --178.191.19.52 18:38, 7 May 2021 (UTC)

Today, I have set up an issue page on the sandbox SMW to actually demonstrate the issue 4988, it's now labelled as bug and not longer as a question. Furthermore, I also tried the world boss table (see directly below) in a simplified version on the sandbox SMW, exactly the same bugged result. --Tolkyria (talk) 22:47, 19 May 2021 (UTC)

Looks like they've made some progress on this one + have identified the commit that killed it. -Chieftain Alex 22:26, 1 August 2021 (UTC)

Fix identified under this pull request, awaits deployment and then inclusion in a SMW release. -Chieftain Alex 22:07, 1 November 2021 (UTC)

World Boss Table: No Boss Names

Went to see when a boss was up and the small event table at the top of https://wiki.guildwars2.com/wiki/World_boss is not showing the names of the bosses. This edit page also no longer has the buttons to add signature etc. —The preceding unsigned comment was added by Justaplayer (talk) at 12:40, 8 April 2021‎ (UTC).

For what it's worth: The buttons still appear fine for me at least. Though i wouldn't be surprised if this page specifically has any problems as it's showing me the content of the page in the log in link (that shows up while not logged in) at the top of the diff preview again. Hasn't done that for a long time before now though so will probably go away again at one point or another again like last time or not; what do i know i guess. Nightsky (talk) 17:46, 8 April 2021 (UTC)

Yes this is related to missing printouts. -Chieftain Alex 18:31, 8 April 2021 (UTC)

Tried blanking the data subpage, re-adding the content (events, then timers) and purging between, but no dice. -Chieftain Alex 16:40, 22 April 2021 (UTC)

I rewrote the world boss template to use #show instead of property chains (very ugly way to code it, I don't recommend it unless necessary). In my opinion the wiki user experience should not suffer, especially on such a prominent page, with no fix in sight. Here I would argue that leaving it bugged won't fix it faster, only frustrate the wiki users. --178.191.19.52 18:38, 7 May 2021 (UTC)

Gem Store missing prices

Was told it is the same problem, so adding here so we don't forget. Many items listed on Gem Store#List of currently available Gem Store items don't have any price listed (although they have it on the Data subpage correctly), only the gem icon is there. ~Sime 11:50, 5 May 2021 (UTC)

This seems to be fixed now. Did someone apply any change or did it fix itself? --Stephane Lo Presti talk 18:49, 5 May 2021 (UTC)

Property chains of the type record can be either obtain with ?<record property>.<record field N> (bugged) or ?<record property>|+index=N (currently not bugged, at least right now it's working), see also smw:Help:Type Record/Searching a record. While this special case was fixed by using an alternative notation, any non-record related property chain can't be rewritten in a similar way, e.g. World Bosses above. --91.115.172.68 20:43, 5 May 2021 (UTC)

Template:Damage traits table

The property chain ?Is for skill.Is in trait line.Has canonical name in the Template:Damage traits table (see also this Special:#ask) leaving skill fact subobject, entering the trait line page and finally trying to get its canonical name fails to return a result sometimes, see also this suboptimal intermediate fix. --Version history (talk) 22:47, 11 May 2021 (UTC)

Mobile theme when viewed on desktop - not loading custom css at all

Compare the appearance of https://wiki.guildwars2.com/wiki/Achievement?useformat=mobile with https://wiki.guildwars2.com/wiki/Achievement?useformat=desktop . The table under the Category section previously loaded themes from MediaWiki:Minerva.css. It appears this is no longer the case. I cannot therefore see a way of styling the Minerva skin for desktop users.

Note that it appears Mobile.css is however served correctly for mobile devices.

Additionally I am sometimes seeing "document.body" is null being thrown in the javascript console (apparently from https://wiki.guildwars2.com/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=minerva&target=mobile) -Chieftain Alex 17:41, 26 May 2021 (UTC)

For what it's worth https://wiki.guildwars2.com/wiki/Achievement?useskin=minerva seems to work fine. If i use the "Mobile view" toggle at the bottom it shows up fine too. Where do you have the useformat link from if i may ask? (The useskin link from me here is from the preferences. (I recently included it in my common.js; adding to the sidebar to the left a category with preview links for all skins but the current (mw.config.get("skin");) one.)) Nightsky (talk) 02:20, 27 May 2021 (UTC)

"?useformat=mobile" is the parameter string recommended on the extension page for previewing the minerva skin, so I copied that.

"mobile view" button at the bottom still does not load any of the custom table css for me. I've also got a bunch of verifications from other folks on the discord with screenshots.

I'm also not receiving the table css with ?useskin=minerva.

In case it isn't apparent, the table being blue is the sign I'm using that stuff is working or not. -Chieftain Alex 06:57, 27 May 2021 (UTC)

Ok what the hell, I made an edit to a page in mobile view, and the blue header is loading again for all three options... and then I visited another page, and it's gone again, but I am receiving this JS error:

Exception in module-execute in module skins.minerva.scripts:     load.php:2:530
TypeError: document.body is null    load.php:2:567
   > jQuery 4
    runScript https://wiki.guildwars2.com/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=minerva:13
    cssHandle https://wiki.guildwars2.com/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=minerva:14
    flushCssBuffer https://wiki.guildwars2.com/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=minerva:5

-Chieftain Alex 07:01, 27 May 2021 (UTC)

For me the table was blue with both "useformat=desktop" and "useskin=minerva" as well as with the "Mobile view" toggle and not blue with "useformat=mobile". While now it's also not blue with the "Mobile view" toggle anymore. But i don't have any errors in the console, so i'm afraid but i'm not sure i can help you here. Nightsky (talk) 17:36, 27 May 2021 (UTC)

(Reset indent) Nightsky, Chieftain Alex: Is this still an issue? Justin Lloyd (talk) 20:44, 25 June 2021 (UTC)

Still failing to render any wiki css for me if I operate from a desktop after clicking on mobile mode, so yes. -Chieftain Alex 22:33, 25 June 2021 (UTC)

If I browse anonymously in a new session without logging in, the theme loads. -Chieftain Alex 22:35, 25 June 2021 (UTC)

I can report that i had the "document.body is null" error occur now too (almost (the only difference being the language being en-gb and there being an additional &target=mobile at the end.) the same as for Alex above as well as another one simultaneously with the only difference being jQuery 9 instead of 4.), altough only on first load.

Same for me with loading fine with the toggle at the bottom while logged out but not when logged in. While when logged out mw.loader.moduleRegistry.site contains Mobile.css in and css array in style, it doesn't when logged in, while it probably should have it then too (since it does have it while logged in on wikipedia too). Nightsky (talk) 15:22, 26 June 2021 (UTC)

Confirmed still occurs as of November (post mw update). -Chieftain Alex 09:59, 18 November 2021 (UTC)

Still occurring, but I notice that if I run the following

$('head').append(
'<link rel="stylesheet" href="/load.php?lang=en&modules=site.styles&only=styles&skin=minerva"/>'
);

Then it seems to resolve it for that instance. Amusingly the requested CSS module contains absolutely nothing apart from a CSS comment. -Chieftain Alex 19:31, 25 April 2022 (UTC)

I'm guessing this means that the required CSS files have **really** loaded, but that the browser needs a kick to reload the css (in this case by loading a blank stylesheet). I tried swapping the above for a simple style tag with the same content in, but this doesn't seem to work. -Chieftain Alex 19:39, 25 April 2022 (UTC)

I had a closer look, seems the content of the requested webpage either seems to vary (not blank atm) or is somehow user dependent. -Chieftain Alex 19:43, 25 April 2022 (UTC)

(Reset indent)

I've made the above image using the test wiki to explore when this bug occurs. There are several phabricator issues which touch on related problems:

• https://phabricator.wikimedia.org/T265566 - useformat=mobile does not make proper CSS/JS changes
• https://phabricator.wikimedia.org/T248416 - [EPIC] Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles
• https://phabricator.wikimedia.org/T270603 - Module site.styles generates different output depending on mobile cookie, if $wgMFSiteStylesRenderBlocking = true;

I think I can write a javascript workaround which will add in the missing stylesheets in each instance. -Chieftain Alex 22:20, 9 September 2022 (UTC)

I believe this is now mitigated by my latest series of edits to the JS - refer to the above image to see what's wrong (light red stuff fails to load, red stuff loads when it should not). -Chieftain Alex 22:55, 10 September 2022 (UTC)

Added further documentation on User:Chieftain Alex/MediaWiki#CSS and JS. Marked as mitigated. -Chieftain Alex 09:01, 11 September 2022 (UTC)

I had a notification email this morning as https://phabricator.wikimedia.org/T270603 has now had a set of working patches added to it. I remain hopeful this will eventually be fixed. -Chieftain Alex 05:46, 24 April 2023 (UTC)

Issue has now been closed. I guess it will be added into a release in the future now. -Chieftain Alex 21:32, 3 May 2023 (UTC)

(2024 note) - this gets implemented with MW 1.41 -Chieftain Alex 10:48, 13 April 2024 (UTC)

Empty or incomplete SMW queries

Description

• Most pages on this wiki are powered by smw:Semantic Mediawiki which allows to store data in smw:properties which then can be asked for with smw:inline queries.

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)

Gallery view of weapon skins in a collection only shows some of the available pictures

If you go to Beastslayer weapon skins the gallery currently only shows 6 images of skins. The weapon skins table has all the appropriate links in it, just the gallery isn't complete.

Desert King weapon skins has the same issue, as do a number of other skins collections pages. Siliron (talk) 21:57, 26 September 2022 (UTC)

Same wiki issues as normal right now, the properties are not set and the pages need to be purged. The plan is to run more scripts to try and solve these issues in a few hours so please wait till tomorrow and we'll see the progress. Also you can join the wiki discord where we are going over active updates and info. --Dak393 (talk) 22:32, 26 September 2022 (UTC)

API widgets broken on Open Skies achievements pages

1) See example: https://wiki.guildwars2.com/wiki/Open_Skies:_Desert_Highlands

2) Widget table displays a warning: "The API widget is unavailable for this achievement (it may not be whitelisted in the API)."

3) Table entries display a secondary warning: "This collectible is not stored in the related parameter "collection" from the Template:Achievement table row. Please make sure to use the same collectible here, for example the skin instead of the equipment item in order to allow the API check."

4) Issue currently impacts entire family of Griffin unlock achievements pages

Jessicas rabbit (talk) 03:40, 25 September 2022 (UTC)

Properties are not set and not saving on pages, this is known and the biggest issue with pages in general. All the issues you described were caused by Rare Collections not saving properties though checking again now that has resolved itself. What needs to be done now is the other pages just need to be purged and save the properties. I've done a couple now but if you wanted you could look through and purge the data sources. --Dak393 (talk) 04:26, 25 September 2022 (UTC)

I fixed the Rare Collections page by blanking and readding the content to force the backend to create the properties. --BuffsEverywhere (talk) 04:30, 25 September 2022 (UTC)

Purged all of the Rare Collections, so all are working now. DJemba (talk) 09:46, 25 September 2022 (UTC)

Containers for items not showing

For instance if you go here Grandmaster Leatherworker's Mark , there is no container listet which contains the mark. But at least this container Box of Grandmaster Marks contains them. Irkm Desmet (talk) 09:32, 27 September 2022 (UTC)

Thank you for letting us know. This has now been fixed, and we hope it stays that way. Greener (talk) 18:46, 27 September 2022 (UTC)

This is still issue for many items and it also affects gathered from e.g. Soul Pastry Ley Line Crystal which are contained in Bag of Trick-or-Treat Bags and gathered from Crystallized Supply Cache respectively.

Queries not working?

There's supposed to be a list of timegated recipies on Crafting#Time gating but it says "These items include: No recipes found that match the constraints of the query." URL is from an old reddit post and the anchor seems to have changed: https://www.reddit.com/r/Guildwars2/comments/2dp4vc/wiki_list_of_time_gated_recipes/

This page has punctuation error : Barbed Thorn

The Barbed Thorn page has been given purge to hopefully keep it fixed. I've partially updated the time-gated list from memory; the recipe subobjects have not all been created (we're trying to find out why). Greener (talk) 18:46, 27 September 2022 (UTC)

Item References

Seems that even if the update ended succesfully the item Pile of Liquified Goo (Pile of Liquified Goo) still have some problem in the code. NaramSin (talk) 20:42, 27 September 2022 (UTC)

The main parts of the update have completed. "Successful" is becoming more of an argumentative term. The page should look better for now; thanks for pointing it out. Greener (talk) 20:23, 27 September 2022 (UTC)

Expression error: Unrecognized punctuation character

I just found a wiki page that doesn't show correctly after the recent big wiki update. It's showing a lot of unprocessed delimiters. The one error that seems to stand out is the one from the subject. Since I don't really understand the code or how to fix it, I'm posting it here as per the current information popup on the top of every site: Black Lion Weapons Voucher

It seems to have sorted itself out, or someone came by and purged the page. Thanks for flagging it for us. Greener (talk) 22:12, 27 September 2022 (UTC)

It's same for atleast wvw legendary armor Mistforged Triumphant Hero's Masque

It's also the same for: Zephyrite Supply Box

Missing acquisition sources for some LWS3 items

After the recent update, several items no longer show vendors that sell them, or the list of vendors is incomplete. For example:

• Druid Runestone Fragment — no vendors at all;
• Bundle of Jade Shards — only 1 vendor out of 3;
• Bundle of Petrified Wood — 2 vendors out of 5;
• Petrified Wood Node — no vendors.

Petrified Wood also doesn't show that it can be gathered from Petrified Stump. Same with Jade Shards. But I don't know if this is an issue with templates or if it was just never added to the wiki.

I'm not sure if it's limited to LWS3 items, but those are the ones I've noticed so far.

I think I took care of a bunch. Looks like hunting down the vendor, purging their page's cache, and then purging the item's page populates the sold by. There's a lot of these sort, and I tried addressing a bunch of the LWS3 vendors and wiki-walked my way to fixing a bunch of Gem Store items. Chaonaut (talk) 19:21, 28 September 2022 (UTC)

We might as well get organized. I went ahead and "?action=purge" every vendor NPC in Siren's Landing and all pages I could find relevant to [[[Relic_Collector]] Kenji_03 02:09, 5 October 2022 (UTC)

Ascended Breathers

Looks like the template used for all Ascended Breathers still has issues, whether crafted like: Zojja's Metal Breather or bought from Slooshoo like Wegloop's Air Mask. Lady Elyssa.2469 09:50, 28 September 2022 (UTC)

Strike that, did a purge and all good. Lady Elyssa.2469 09:56, 28 September 2022 (UTC)

Personal Story not loading/highlighting from API correctly

When using the API settings on Personal story, some but not all of the personal story parts are highlighting when provided with an API. For example, a char character who completed Chapter 2 shows both part 2 Stoking the Flame and part 4 Sins of the Father as complete, but the quest in-between A Fork in the Road does not highlight. 22:31, 27 September 2022 (UTC)

Probably chapter ids not being set. —Kvothe (talk) 12:10, 28 September 2022 (UTC)

I tried the purge method on one of the entries that wasn't highlighting for me, and that worked. I went ahead and manually purged all the pages that weren't highlighting for me, as well as all the story parts I haven't done, so this ought to be working now. Chaonaut (talk) 13:39, 28 September 2022 (UTC)

Weaponsmith/Novice recipes

Nourishments and Back items still show "No recipes found that match the constraints of the query.". Previously the Sigils section was also showing that, however,after I purged the page twice the Sigils section now shows Minor Sigil of Destroyer Slaying. I think there were more sigils and there was also a nourishment, but I'm pretty sure there is a Novice weaponsmith backpack, so something's still wrong on this page. —The preceding unsigned comment was added by 89.64.83.234 (talk) at 14:25, 2 October 2022‎ (UTC).

Yep, just checked in-game. Simple Weaponsmith's Backpack is a novice weaponsmith recipe. I went to the page Simple Weaponsmith's Backpack on your wiki, it was garbled. I purged it and then purged Weaponsmith/Novice recipes. Finally this recipe shows in Weaponsmith/Novice recipes. Unfortunately, in these circumstances, it is not even clear what is needed to be purged - pages like Weaponsmith/Novice recipes are supposed to list the very pages that need to be purged to be displayed there! Might I suggest that you run a bot that just purges all your articles? 89.64.84.39 14:46, 4 October 2022 (UTC)

That's been done, we've run scripts, we've purged by hand, we've run bots, we've done back end updates... The issue is that already purged pages are reverting and breaking again after some time. That needs to be solved before any real progress can be made. --Dak393 (talk) 15:43, 4 October 2022 (UTC)

Missing pages for database items - Destroyer Weapons

Destroyer Weapon Crate is missing a lot of entries. Of the 19 choices, only 7 have links to real pages. The others ask me to create the page. Purge of the main page didn't help. Not sure how to purge a "new" page. —The preceding unsigned comment was added by Kharly (talk) at 20:41, 2 October 2022‎ (UTC).

Only needed a purge of the actual weapon pages since those pages already exist. —Kvothe (talk) 22:27, 2 October 2022 (UTC)

Why has the purging not been done automatically as part of the software update process?

It's weeks after the MediaWiki software update and there are still broken pages. I (as user) has been happily pressing purge on any broken page I came across, but why have the system administrators not made sure this was done automatically with or after the software update and leave the wiki like this. And if this is technically impossible, wouldn't it been better to stay on the previous version of the wiki software? Also: https://en-forum.guildwars2.com/topic/121452-whats-up-with-the-wiki/ Aranimda (talk) 18:56, 12 October 2022 (UTC)

It usually is done (and I only assume it was done/was intended to be done this time too). But the pages keep breaking again, that is the big issue. DJemba (talk) 18:59, 12 October 2022 (UTC)

Widget counter bug

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 Alex 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 Alex 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 Alex 22:24, 30 November 2022 (UTC)

Thanks! In order to avoid duplicate code calls: couldn't we check for the first instance on wiki level, for example using some kind of #var check? Would this be too expensive?

Other widgets that comes into my mind which could potentially be affected by large-scale edits are game mode buttons (the counter eq 1 check should have been removed already) and account achievements. --Tolkyria (talk) 18:54, 1 December 2022 (UTC)

The minified js ended up being pretty small without any repeat checks on the game link widget - there's a few different link templates which call the same one, seems easier to leave this one as it currently is.

Using #var checks will work on anything which doesn't need any placeholder elements to be added by the widget + so should be considered, however most widgets have html placeholders (we could though move the placeholder html into the template in some instances).

I've added a topic to Category talk:Widgets to track our progress on removing smarty counter instances, and created a topic on Template talk:Wardrobe to consider removing one widget entirely. (fwiw game mode buttons was rewritten a long time ago to remove its counters) -Chieftain Alex 23:12, 1 December 2022 (UTC)

Marking as mitigated; all widgets have been reviewed to reduce counter usage (replaced with javascript equivalent where required). Also updated the help docs. -Chieftain Alex 17:41, 3 December 2022 (UTC)

Other

Special:Search occasionally does not redirect when searching for a single chatlink

Reported on discord by BuffsEverywhere and Sime:

When performing a /wiki [chatlink] search from ingame, occasionally MediaWiki:ChatLinkSearch.js does not redirect to the target page.

The chatlink is extracted and the page is displayed below the search bar, indicating that the JS is working, but apparently it is not then redirecting.

I have asked for confirmation that they actually close their browser between gaming sessions + that they haven't searched for the same page twice in the same session - currently the script is written to deliberately prevent redirect on second search, to allow use of the browser back button. -Chieftain Alex 20:44, 24 November 2021 (UTC)

There wasn't anything besides the chat code part of the search either i presume? Since that would prevent a redirect from occuring as well; even if it were only spacing, as per the regex. Also, do there happen to be any surviving search queries for which this occured? If not, it might help collecting them going forward? Nightsky (talk) 21:29, 29 November 2021 (UTC)

Didn't get further information on this, haven't heard of it for the last year, archiving. -Chieftain Alex 21:49, 10 August 2022 (UTC)

Image cache bug

Icon cache bug

File:Hearty Sugar Rib.png - version displayed in infoboxes (40px) displays an old version with a gold border. Tried replacing the file with a new one of a different size, moving the old file, purging, refreshing, nothing seems to change it. Might need a kick on the backend for this file? -Chieftain Alex 13:25, 3 April 2021 (UTC)

Image / thumbnail generation seems to work only sporadically. —Kvothe (talk) 10:05, 5 April 2021 (UTC)

This one appears to be okay now, as far as I can tell, but I did a backend cache purge just to be sure. Can you confirm? Justin Lloyd (talk) 11:21, 8 April 2021 (UTC)

There's no border, for me at least, now anymore. Nightsky (talk) 17:46, 8 April 2021 (UTC)

Purge! Purge them all!

Ive tried to upload a new version for File:Skritt (white fur).jpg. That works fine but I cant see the updated version on any other pages. Wanted to purge the page cache but cant even open the purge page normaly. After Ive finaly got there and hit the purge button, it took a min to purge yet I still see the old version of the image. --DiegoDeLaHouska (talk) 17:43, 7 April 2021 (UTC)

The new version shows up fine for me. This might be your browser cache playing tricks on you. Try Ctrl+F5 on a page that should show the new screenshot. Nightsky (talk) 18:08, 7 April 2021 (UTC)

Nope . Still can see the old image at Chittukk. --DiegoDeLaHouska (talk) 19:08, 7 April 2021 (UTC)

Ah, yes. My bad. I swapped the images; thinking the new one was the old and the old one the new because it loaded the old one instead of the new one in the place of the large preview. Nightsky (talk) 19:15, 7 April 2021 (UTC)

I've manually purged the image from the web servers' Varnish caches and all of the pages that link to the image seem to be correct now. Let me know if you find further instances of this kind of problem and I'll dig deeper. There were changes to the caching configuration, partially related to cookies, with this latest version upgrade, so it's possible there may be unforeseen side effects that I'd need to investigate. Justin Lloyd (talk) 11:14, 8 April 2021 (UTC)

Another one apparently

Mastery Point (Heart of Thorns).png should show up as https://render.guildwars2.com/file/596E3442F5582FC64EED1DA5ABD69D1D427614F7/962063.png now but it to me appears to be stuck on the previous version still. The filesize of the new version seems to be correct at least, so there's that. Nightsky (talk) 17:44, 25 April 2021 (UTC)

Regenerate (fern hound).png should be https://render.guildwars2.com/file/3CD0D15B0C0E9CB7BD6709E773DFB2FCFEC25823/103609.png now too. And the images i uploaded before that that differed in size also seem to still show the old size in places. Nightsky (talk) 17:53, 25 April 2021 (UTC)

This is probably a caching issue which affects all images uploaded, continuing to show the previous version before eventually showing the new version. It can be manually circumvented to some degree by requesting a version from the wiki that isn't cached. Requesing a slightly smaller image usually does the trick. Compare e.g. [[File:Forbidden white.png]] and [[File:Forbidden white.png|19x19px]]. (These will look the same given some time but untill then they'll look different even though they are the same file if of being rendered at slightly different sizes.) This will work for looking at images to see if they are uploaded propperly but it's no option to go through all pages the image is used on and change the sizes slightly in order to get it to show up. So it's not usefull in that regard. Nightsky (talk) 21:12, 13 September 2021 (UTC)

Haven't seen this in a while, if it occurs with MW 1.38, report it again. -Chieftain Alex 12:47, 11 September 2022 (UTC)

Caching appears to not work

It seems that when viewing any page, then refreshing/reloading it (Note: Not purging.), the cache timestamp changes even if done before the time the pages are set to be cached for; indicating it might not work propperly. Try e.g. the following code on any page, refresh/reload it, then try it again.

var r = mw.config.get("wgPageParseReport");
console.log(r.cachereport.timestamp, r.cachereport.ttl);

The date will be different even if this is done when less than the seconds indicated have passed. At least it is always different for me. Nightsky (talk) 18:20, 21 October 2021 (UTC)

On the plus side, time based templates should never be wrong due to caching this way; at least imidiatelly following a page reload. (E.g. 05:00:00 TT.) Though pages semingly always being reparsed doesn't paint an all to well picture of server load.

And while technically better fitting under the Mw Indicator Smw Entity Examiner heading, which weirdly seems archived even though it's not realy fixed, i wonder if that fix, if it's even in place which i can't tell as it got never answered so i have to speculate even more, is possibly responsible for the slowness of bot edits. Nightsky (talk) 07:09, 2 November 2021 (UTC)

Still seems to read a new timestamp every f5 (without clearing the cache on server side). -Chieftain Alex 18:55, 18 March 2022 (UTC)

Haven't seen this in a while, report again if occurs with MW 1.38. -Chieftain Alex 12:47, 11 September 2022 (UTC)