Guild Wars Wiki:Reporting wiki bugs

Please report all bugs found on Guild Wars Wiki here.

Resolved issues

Older

Recent

This page is for reporting bugs that you may encounter on the wiki. This does not cover in-game issues that you may encounter, nor does it cover page contents within individual articles.

If you are experiencing an in-game bug and wish to report it or have issues that require technical assistance, please head to the Guild Wars section of the Guild Wars 2 Player Support website.
If you are experiencing difficulties getting past a specific part of the game, use the "Search" box on the left to find the specific quest, mission, or region that you are finding difficult. You can review any tips on that page, and discuss it on that page's talk page if more help is needed.
If you have a problem with contents of a page, use the associated talk page.

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

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

Key: = Solved, = Unsolved, = Not a bug

Tables of contents on mobile[edit]

There are also no Tables of Content on mobile. - Infinite - talk 14:24, 29 March 2020 (UTC)

Not sure what the requirements for making tables appear on mobile are, but I can see a table of contents on Crystal Desert and on this page too. Your user preferences may affect this. If you have an example page in mind, please provide a link. -Chieftain Alex 08:34, 12 April 2020 (UTC)

In mobile view settings you can turn on auto-expand all sections and while pages become more effective that way, there is no traditional table of contents in place to use (mobile view on mobile device). Because the section headers are collapsed by default and function as a table of contents by themselves, not having a ToC defeats the point of having this setting. I guess it's not a bug as much as it is a designer oversight. I just don't see the point in removing the ToC, but also allowing all sections to be expanded by default. - Infinite - talk 13:43, 12 April 2020 (UTC)

I would upload a screenshot from my phone, but I actually cannot at this time. It gives a file is empty error. Not sure if this is related to the update, though. - Infinite - talk 13:55, 12 April 2020 (UTC)

Link to imgur. There's a bug (documented on the gw2w) where a certificate has expired, preventing write access for many resources (files and widgets). -Chieftain Alex 16:24, 12 April 2020 (UTC)

[1] Difficult to get my point across; expanded by default is active, the infobox is the top of the page, but there is no ToC before the first header.

[2] {{TOCright}} also doesn't work on mobile view, as seen here. - Infinite - talk 20:51, 12 April 2020 (UTC)

Here is what mobile view sees in mobile mode when viewing the Crystal Desert article (cut off partway into it), since you mentioned it earlier: [3] The lack of a ToC is instantly apparent.

This is in stark contrast with mobile view in desktop mode, where the ToC is present: [4]

On the plus side; TOCright does work in the latter case as well (and correctly, too). It's just not working for mobile view in mobile mode. - Infinite - talk 23:43, 14 April 2020 (UTC)

Did you spot that there is a min screen width 720px rule in the CSS sheet which hides the TOC below that width? -Chieftain Alex 23:52, 14 April 2020 (UTC)

I've been looking through all the sheets for a while now, but I couldn't find it. Though also, my screen's resolution is far wider than 720px (1080px). It's why I'm so confused. Does the mobile view mobile mode have a set max-width as well? What are the benefits of hiding a ToC below a certain width; does it not fit on smaller sizes? Would it not also be more necessary to have a ToC on such sizes, given the fact that they can display much less content at once? - Infinite - talk 07:08, 15 April 2020 (UTC)

Collapsible parameters[edit]

Collapsible and expandable parameters do not work. - Infinite - talk 14:24, 29 March 2020 (UTC)

Unable to find any bugs in the behaviour on desktop, with the classes mw-collapsible, mw-collapsible mw-collapsed, collapsed nor expanded.

If you do find any bugs, check your javascript console first - the collapsible table scripts may be prevented from loading by any other javascript bugs, and I'm not ruling out a bug with the clock for example.

However, if you mean for Mobile view, we don't actually load the collapsible modules as they're not considered mobile-friendly. Imagine touch scrolling through an article and slapping the collapse button? -Chieftain Alex 08:34, 12 April 2020 (UTC)

Yeah, all my reports were mobile view specifically. A header (the top level anyway) now functions in the same way as the collapsible and expandable parameters, but the actual click-to-expand/collapse buttons do not show up. I noticed this in my sandbox, but I do recall there are main space articles utilising these parameters. It should be an easy fix without having to alter anything in the software. Just give these sections their own header. - Infinite - talk 13:22, 12 April 2020 (UTC)

Outdated thumbnail on The Missing Corpses[edit]

The upper infobox thumbnail shows a previous verison of the map (File:Missing Corpses.jpg). I tried emptying my browser cache and checked in different browsers (Waterfox and Chrome) and the issue is present in both, so I presume it's not on my end. -- kazerniel (talk) 22:33, 2 May 2020 (UTC)

I encountered the same issue. Gave it a kick and it now works fine for me. Try clearing your cache one more time if it still shows incorrectly. Greener (talk) 00:50, 3 May 2020 (UTC)

Now it works, strange. Yesterday I cleared the cache several times without effect. -- kazerniel (talk) 11:45, 3 May 2020 (UTC)

Discussion pages on mobile[edit]

Checked out the wiki on my mobile for a change. I don't seem to be able to access the discussion pages of articles though. Steve1 (talk) 11:17, 9 May 2020 (UTC)

Discussion page link is at the bottom of every page. Working fine I think. -Chieftain Alex 22:47, 9 May 2020 (UTC)

I see the page history at the bottom, followed by disclaimer. No discussion page. Iphone with newest OS installed. Steve1 (talk) 09:30, 10 May 2020 (UTC)

Tell me what page you're visiting and I'll see if I can reproduce your report. -Chieftain Alex 09:52, 10 May 2020 (UTC)

Death leveling Steve1 (talk) 10:02, 10 May 2020 (UTC)

screenshot of Death leveling - what? -Chieftain Alex 10:26, 10 May 2020 (UTC)

RL calling, I'll post a pic later. It's not there. Steve1 (talk) 10:38, 10 May 2020 (UTC)

https://imgur.com/a/E5BGEm8 dat Steve1 (talk) 13:56, 10 May 2020 (UTC)

Thanks for bearing with me. If I sign out or use a private window I get exactly the same as you do.

There is an open phabricator issue T54165 for exactly this problem. It has been open since 2015 and they've done nothing! I'll see if I can figure out why this happens and if $wgMinervaTalkAtTop is actually a solution we should implement on all five wikis. -Chieftain Alex 17:20, 10 May 2020 (UTC)

Option 1:

If we added $wgMinervaTalkAtTop['base'] = true; to localSettings.php it would add a tab row with two buttons in it to the top of each page: screenshot.

Option 2:

The alternative would be to edit SkinMinerva.php in wiki\skins\MinervaNeue\includes\skins. This would result in the discussion button appearing for anon users just like logged in users currently receive it. Line 742 looks like

if ( !$this->getUserPageHelper()->isUserPage() && $this->getPermissions()->isTalkAllowed() && $talkAtBottom ) {

and all that needs to be done is remove the $this->getPermissions()->isTalkAllowed() && bit, i.e.

if ( !$this->getUserPageHelper()->isUserPage() && $talkAtBottom ) {

Option 1 would be easiest for ArenaNet and is acceptable in my opinion. -Chieftain Alex 17:47, 10 May 2020 (UTC)

Cheers Alex. I know how frustrating bug hunting can be. Steve1 (talk) 18:33, 10 May 2020 (UTC)

Justin has updated the localSettings file such that the talk page button appears underneath the page title for anons and logged in users, so I'm marking this as resolved. -Chieftain Alex 17:22, 12 May 2020 (UTC)

Confirmed. Kudos to Justin, whoever he may be. ;) Steve1 (talk) 20:19, 13 May 2020 (UTC)

Justin is the official ArenaNet IT guy for the wiki. -Chieftain Alex 14:43, 17 May 2020 (UTC)

2 bugs[edit]

Gallery of Spawning Power items starts with a bunch of bows. The categories of the bows seem fine. Other galleries might be affected.

"Tango Down!" is not showing the skill icon . It's working on Corporal Bane's skill page or Going Commando.

Bugs spotted by Falconeye. Steve1 (talk) 10:57, 17 May 2020 (UTC)

The gallery issues were actually caused by Falconeye (not just "spotted" by) adding an incorrect DPL query to the Spawning Power / Divine Favor gallery pages. The only relevant flatbow was also missing from the Flatbow category in the first case. -Chieftain Alex 14:38, 17 May 2020 (UTC)

LOL - and *facepalm*. Cheers, Steve1 (talk) 14:42, 17 May 2020 (UTC)

The second bug was also caused by Falconeye.

Leaving parameters empty is poor practice. That being said I've updated the infobox to be more resilient against people being careless with the "id" parameter. Chieftain Alex 14:42, 17 May 2020 (UTC)

Categories on mobile not showing[edit]

At the bottom of the page, categories don't show up. Example: Take Alex' screenshot on death leveling from a few days ago. The two categories are missing. Steve1 (talk) 11:03, 17 May 2020 (UTC)

Categories are considered metadata that isn't worth showing on mobile. This is a design choice. -Chieftain Alex 14:30, 17 May 2020 (UTC)

Image upload form helper: MediaWiki:UploadForm.js[edit]

It appears (based on this upload) that the file upload script "Image upload form helper" loaded through MediaWiki:Common.js doesn't prevent people from uploading files without license tags ("anymore"? I'm not sure if it ever did prevent uploads without licenses on this wiki.)

A quick examination of UploadForm.js suggests it is looking at the correct node ids - i.e. they haven't been renamed. The script certainly loads because the radio buttons are there. -Chieftain Alex 10:11, 24 May 2020 (UTC)

I don't recall this wiki ever forcing the user to add licensing tags. Adding the tags was one of my main uses of poke's GWWT. I was happily surprised to see the gw2w force the licenses. Greener (talk) 13:42, 25 May 2020 (UTC)

You're probably right that this wiki didn't ever prevent no-license images, but I think it might be worth doing; off the top of my head I can't think of any images for this wiki that would intentionally without a license. Most of the images will be screenshots.

It would be easy enough to do, just need to add a rule to check if the license box is blank in terms of templates / categories, and that the License setting radio is on the first checkbox. -Chieftain Alex 18:43, 25 May 2020 (UTC)

Images without a license tag are not without a license. They are licensed under the GFDL together with all the other content we have. We only ever used explicit license tags for files that were explicitly not licensed under the GFDL, most notably because they were owned by ArenaNet. Those are the images we need to tag. For all the other ones, we assume that they are released under the GFDL instead. And we do have quite a lot of those, e.g. all of our tango icons. So imo, the current behavior is still correct. poke | talk 22:32, 30 May 2020 (UTC)

Domain issues[edit]

→ moved from Guild Wars Wiki:Admin noticeboard

For some reason, starting today a few hours ago, the wiki has been constantly redirecting me to the german GW2 wiki. Any ideas what's causing this? Jeree95 (talk) 11:50, 24 June 2020 (UTC)

Same. Several times while trying to edit my user page, but also during search. And while previewing or saveing changes on this edit.--Ruine

Eternelle 11:52, 24 June 2020 (UTC)

Same same. I thought it was me being stupid, which is usually the case. German wiki, huh? Poke - what have you done? — snograt

12:13, 24 June 2020 (UTC)

das ist nicht gut. horrible | contribs 12:36, 24 June 2020 (UTC)

Indeed. I want my recent changes, not Letzte Änderungen. It smells like a server-side issue (he says, pretending he knows what he's talking about.) — snograt

12:39, 24 June 2020 (UTC)

I’m innocent. I also don’t know what you are talking about. Is the issue still around? poke | talk 15:06, 24 June 2020 (UTC)

Catching up with messages, it appears that ANet is already on it (or is already done). poke | talk 15:08, 24 June 2020 (UTC)

It seems to be ok now. The wiki was totally unusable for a while there. — snograt

15:09, 24 June 2020 (UTC)

It lasted for something like 3 hours. Despite the URL looking normal, it was attempting to pull pages from the german wiki, meaning every link clicked would lead to the german "this page has no content..." Also, it SEEMED to be looking at the german GW2 wiki. Most bizarre. — snograt

15:17, 24 June 2020 (UTC)

I was told that this should be fixed now. Apparently, there was some infrastructure change and a missing configuration involved. Let me know if there appears to be any issue left. poke | talk 15:27, 24 June 2020 (UTC)

Issue deleting a file[edit]

When attempting to delete File:Ascalon child f.jpg, I get a message stating, "Error deleting file: An unknown error occurred in storage backend "local-backend"." No other info is given. Greener (talk) 01:05, 20 July 2020 (UTC)

I'll look into this. Justin Lloyd (talk) 15:49, 20 July 2020 (UTC)

Greener, I see the deletion attempts in the server log and no indications so far of an error. How many times did you try? Have you tried since then? Justin Lloyd (talk) 16:08, 20 July 2020 (UTC)

I believe 3 times previously, and I just attempted now with no success. Greener (talk) 16:33, 20 July 2020 (UTC)

Looking at https://phabricator.wikimedia.org/T244567, can you see if first null editing the file and then trying the delete helps? And can you delete anything other files, even a test upload? Justin Lloyd (talk) 16:42, 20 July 2020 (UTC)

Uploading and deleting other files is fine. Null editing and deleting did not work. One oddity / red herring is that one of the thumbnails for File:Ascalon child f.jpg is not showing. I can be more aggressive and see if uploading over the image and then deleting would kick anything. Let me know. Greener (talk) 17:04, 20 July 2020 (UTC)

The overwrite idea seems worth it. The file seems okay but perhaps there is some kind of corruption with the file and/or database info. Justin Lloyd (talk) 17:15, 20 July 2020 (UTC)

Same error after overwrite. I looked at the other examples given, https://commons.wikimedia.org/wiki/File:IFriend.png and https://id.wikipedia.org/wiki/Berkas:Kementerian_Lingkungan_Hidup.svg , and they also seem to be missing a thumbnail in their histories. The missing image on ours is also missing an id#, so it can't be referenced by a revert or delete:

compared to these reverts and deletions that work:

--The preceding unsigned comment was added by Greener (talk) at 17:25, 20 July 2020‎ (UTC).

Looking at the database, the image id number for the missing entry is identical to the one right below it (20100713135214) and the image hash value is identical to that previous version as well. The duplicate/missing entry does point to the previous entry as its parent and the next one points to the duplicate. I wonder if deleting the parent revision would delete both. Not exactly sure of the SQL command it would execute, so I don't know if both the good and missing revisions would get deleted. I can try to get some MW expert help to find out if there's a better way to try to resolve this. Justin Lloyd (talk) 17:58, 20 July 2020 (UTC)

Deleted the parent version, 20100713135214, and the blank thumbnail still remains. Tried to subsequently delete the whole file set, and I received the same initial error message. I'll bring back the parent version so that it's visible again to anyone else that wants to play with it. Thanks for looking into this! Greener (talk) 18:36, 20 July 2020 (UTC)

I'll have to keep digging. No responses yet from the two MW channels I've pinged on this kind of problem. Justin Lloyd (talk) 20:22, 20 July 2020 (UTC)

The issue appears to be an bad entry in the database for the image's file history. I have a possible approach to fixing it that I am investigating and will test in dev if it's a feasible solution. Justin Lloyd (talk) 11:05, 29 July 2020 (UTC)

(reset indentation) I've tested the fix in the dev wiki and it seems to work, a simple deletion of the bad row in one of the database tables. Since this would be a manual change to the live database, I want to ensure we're in agreement on proceeding with this procedure. Please let me know at your convenience how you'd like to proceed with resolving this issue. Justin Lloyd (talk) 16:55, 29 July 2020 (UTC)

Hey Justin, once again I'm sorry for the late response. As per my email to you, I support the attempt to delete the bad row from the database. If it works, then we have a new tool in our toolbox. If it doesn't, then we'll see if anyone else has some suggestions ;) . Greener (talk) 20:32, 19 August 2020 (UTC)

I've deleted the bad row and the page history no longer shows the invalid entry. Feel free to attempt the page deletion again at your convenience. Justin Lloyd (talk) 20:46, 19 August 2020 (UTC)

And we have success! Justin, thank you for digging so deep into this, especially for doing the extra backing up on the dev wiki and reaching out to others. Very much appreciated! Greener (talk) 20:51, 19 August 2020 (UTC)

Glad to be of service, that's why I'm here! Thank you for bringing this odd issue to my attention in the first place. Justin Lloyd (talk) 20:53, 19 August 2020 (UTC)

RecentChanges[edit]

I'm not sure whether or not this is a bug, but Special:RecentChanges is once again including the user creation log. (I think they were originally removed as a part of this topic) horrible | contribs 23:06, 30 March 2021 (UTC)

I disabled poke's RecentChangesLogFilter extension as part of this major upgrade after discussing it with him regarding compatibility issues with MediaWiki's RecentChanges filter tool. Given that MediaWiki generally collapses multiple recent log entries of the same type, such as user creations, the issue didn't seem as significant as it was in the past, though poke does think it's still useful in the long run and has plans to update the extension to work with the filter tools. That said, if it's a big enough concern, I can re-enable it if necessary, let me know what you think. Justin Lloyd (talk) 10:40, 31 March 2021 (UTC)

On iPhones, both the UCL and the Block Log do not collapse,so they fill up quite a bit of space. IMO, the BL is even worse than the UCL. So if poke's filter gets reactivated, we might think about adding the BL to it as well. On second thought, the BL probably is more important than the UCL though ... Steve1 (talk) 17:02, 31 March 2021 (UTC)

As a note, if you want to remove logs entirely when you look at RC, you can do that yourself with the filter options. https://wiki.guildwars.com/wiki/Special:RecentChanges?hidelog=1 - Tanetris (talk) 18:28, 31 March 2021 (UTC)

That removes all Logged Actions - I'd prefer a better/finer granularity. Steve1 (talk) 12:51, 1 April 2021 (UTC)

I don't have any issues either way, just figured it was worth noting in the event it mattered; I'm a creature of habit and still use the legacy recent changes, where the difference was immediately apparent. horrible | contribs 23:17, 31 March 2021 (UTC)

When I evaluated disabling the extension altogether, there weren’t really many daily account creations anymore. So I was thinking that we maybe won’t need the extension any more. We can monitor the situation for a few more days and if the registrations keep coming, we can see if we can bring the extension back. As it stands, the extension will still filter the user creations (so we could just reactivate it) but the UI for disabling the filter won’t work. I’ll see that I can get this fixed soon though, so maybe we can bring the extension back again. poke | talk 11:06, 3 April 2021 (UTC)

MobileDiff[edit]

Different issue: On an iPhone, when "previewing" a change, the change was colour coded: red for something removed, green for something added. This isn't the case any more, which makes it more difficult to preview changes on a mobile. If this could be re-enabled, that would be fine. Isn't an issue on my laptop. Steve1 (talk) 17:02, 31 March 2021 (UTC)

I didn't specifically make any changes regarding the mobile skin, so that was either a change inherent in the skin's version upgrade or there was a custom CSS change related to it. I can look into the MobileFrontend extension and the associated MinervaNeue skin changelogs to see if there is any indication that it was an intentional change in either of those. Justin Lloyd (talk) 19:44, 31 March 2021 (UTC)

The change diff that appears when previewing/comparing edits seems be different on desktop site too; it now uses a larger monospace font. horrible | contribs 23:17, 31 March 2021 (UTC)

New iPhone point: reviewing this https://wiki.guildwars.com/index.php?title=Guild_Wars_Wiki:Reporting_wiki_bugs&curid=148291&diff=2671349&oldid=2671348 shows up on mobile like this:

Line 153: Line 153:

Justin's post (I disabled ...)

Justin's post again

my post (On iPhones, both ...)

my post again

+

Tan's edit underlined

my post (Different issue ...)

and my post again.

Se we get a double posting in the prev there. Steve1 (talk) 12:51, 1 April 2021 (UTC)

Looks like a problem with Special:MobileDiff, because this looks horrendous on both mobile and desktop. horrible | contribs 13:00, 1 April 2021 (UTC)

Image uploading tag missing[edit]

The radio buttons to automatically tag uploads with {{User image}}. {{screenshot}}, and {{ArenaNet image}} are missing from the Special:Upload page. horrible | contribs 15:11, 1 April 2021 (UTC)

DPL issues[edit]

uncached DPL queries seem slower than they used to be by a significant amount? If there are any load time statistics on the back end, it might be worth looking into.
at least one change: the dash symbol seems to have gained functionality/had a change in the logic that determines its functionality.

horrible | contribs 02:10, 2 April 2021 (UTC)

Re-enabling admin ability to edit Guild namespace[edit]

Presumably with the latest update, the ability for admins to edit the Guild and Guild talk namespaces has been removed. This right had previously been set-up as per :Requests for technical administration/Restrict editing of Guild and Guild talk namespaces, and previously titled editGuild and editGuild_talk. Greener (talk) 17:18, 6 April 2021 (UTC)

That is strange as there were no changes made to group permissions with this upgrade. I don't see editGuild and editGuild_talk in the current list of group permissions for the wikis, though I do see the similar editArenaNet and editArenaNet_talk enabled for several groups. I will add the editGuild and editGuild_talk privileges into the configuration (testing in dev first) to restore this ability to the appropriate groups. Justin Lloyd (talk) 17:42, 7 April 2021 (UTC)

I've deployed the update to restore these privileges. Please confirm they're working for you at your convenience. Justin Lloyd (talk) 19:54, 7 April 2021 (UTC)

Works now, thanks! Greener (talk) 20:22, 7 April 2021 (UTC)

Image caching stuck again[edit]

Tried clearing my browser cache, tried clearing server cache by using this address, neither seem to have fixed it. -- kazerniel (talk | contribs) 18:02, 10 April 2021 (UTC)

I just tried clearing it with the force purge method you linked, and it updated for me. horrible | contribs 18:28, 10 April 2021 (UTC)

Then idk what's up on my end, tried many times in both Firefox and Chromium, Ctrl+F5 or Ctrl+Shift+R, neither changes the image. (ETA: the thumbnail in the file history is correct, but the large image isn't, and when I click through to the main file it isn't either.) -- kazerniel (talk | contribs) 19:52, 10 April 2021 (UTC)

Actually, looking again, it is still cached as the old one. That's odd. horrible | contribs 19:59, 10 April 2021 (UTC)

Tried to upload another image, but it does the same :/ (File:The_Last_Day_Dawns_map.jpg) The only place where the correct image shows up is the file history thumbnail. -- kazerniel (talk | contribs) 13:20, 11 April 2021 (UTC)

Still happening for me, except occasionally the first time you load an updated image. I loaded File:Button sig.png on a new computer and it showed the chance correctly; I force-refreshed the page and it then erroneously showed the original image in both. File:Silver Edge description.jpg always shows the old version for me regardless. horrible | contribs 16:44, 14 April 2021 (UTC)

Given how the images User:Kazerniel linked up above both seem to have since been resolved, I think this is an issue of caches not allowing any sort of manual clear. horrible | contribs 16:46, 14 April 2021 (UTC)

That seems to be the case. My images appear fixed for me too, but the other two images are the old version. -- kazerniel (talk | contribs) 17:08, 14 April 2021 (UTC)

Skill infobox spans the whole width of pages[edit]

When viewing any skill page (on Chromium 90.0), the infobox does not have a fixed width. I anticipate that it relates to the class (not defined in the template, but rather in the css), but it could be something else. It also occurs on mobile view. Other infoboxes are not affected as far as I can tell. Since I am not currently able to get onto desktop and get stuck in in an attempt to fix it, I decided to report it here to get the ball rolling at least. - Infinite - talk 14:40, 3 May 2021 (UTC)

I just checked Heal Area on Chrome v. 90.0.4430.93 and I'm not seeing a problem (nor in Firefox v. 88.0). AFAIK I'm using the default css, do you use a custom one maybe? Just a guess, maybe I'm way off base. --Rainith (talk) 21:13, 3 May 2021 (UTC)

I have since worked out that this is an interaction between an anti-tracker plug-in and the site itself. It's still curious as to why it only seems to affect the skill infoboxes, but it's relatively safe to conclude that it's not something on the wiki's end. Desktop browsers are all fine like your own. - Infinite - talk 21:34, 3 May 2021 (UTC)

Search error if dash is followed by space[edit]

"Database error

A database query error has occurred. This may indicate a bug in the software.

[c6f2160442fc1cdd2711c235] 2021-05-08 16:37:18: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"" -- kazerniel (talk | contribs) 16:39, 8 May 2021 (UTC)

This appears to happen with seemingly any search that starts with a hyphen, either by itself or with anything other than an alphanumeric character after it, indicating some kind of SQL input sanitization issue. I've also tested it against the version of MediaWiki running prior to the March 30 upgrade, which was 1.34, so this isn't a new issue but possibly a bug that's been around for some time. I've also been checking against some other MediaWiki wikis (though none as relatively new as ours except Wikipedia) and couldn't reproduce the problem on them, so it may be a bug with newer versions of MediaWiki, which I'll report and see if it goes anywhere. Justin Lloyd (talk) 11:59, 10 May 2021 (UTC)

It turns out this is actually a known problem, dating back to MediaWiki 1.32 and reported back in April 2019. It's even broader as the error can happen when searching on a title that includes a hyphen but excluding quote marks, e.g. chat - episode should return results but instead errors the same way. As such, there's no current fix but I'll track the bug and hopefully it will be resolved before too much longer. Justin Lloyd (talk) 12:11, 10 May 2021 (UTC)

Spectral agony skill infobox[edit]

See Attack speed at the bottom skill table. I think the Spectral Agony infobox broke.--Ruine Eternelle 10:44, 17 May 2021 (UTC)

One of the recent updates made it so using - (dash) in front of a template causes issues when that template is included in other templates (like as the result of a dpl query). This also occurred with Radiation Surge here. I changed - to - which will resolve this issue. horrible | contribs 18:33, 17 May 2021 (UTC)

Extremely slow page loads[edit]

It seems like in the past week or so the wiki's been even slower than it's usually been following the April 30th updates. I've even experienced a few connection timeouts, which hasn't happened before. This is only occurring on the wiki, which makes me think the issue may not be on my end. horrible | contribs 00:55, 28 July 2021 (UTC)

As part of a series of planned updates, we're going to be bringing the wiki down for a small amount of time in a few hours. One of the goals of these updates is to minimize such connection issues. Today specifically, the wikis got slammed after the latest gw2 announcements, so any recent slowdowns may be attributed to that. Greener (talk) 02:28, 28 July 2021 (UTC)

Just going to chime in that I've noticed this happening in the past week or so, regardless of where it may stem from. Soldier198-2 (talk) 21:04, 28 July 2021 (UTC)

Loading times are a horror today. Can't say anything about the past few days, but that's not how it used to be. Steve1 (talk) 21:16, 28 July 2021 (UTC)

If anything, things got worse. Loading times approach infinite. Including error 503 (Backend fetch failed) on my mobile and just right now when trying to save changes. Steve1 (talk) 18:18, 4 August 2021 (UTC)

Loading times are very slow today. Occasional "Bad Gateway" error. 86.138.8.138 19:50, 4 August 2021 (UTC)

I'm definitely noticing that as well. Good news may be that it looks like it's hitting the gw2w as well, so it's been flagged. Sorry all! I know that this is very frustrating. Greener (talk) 21:24, 4 August 2021 (UTC)

Issue had been gone for the past 10 days. Today it has resurfaced. :( Steve1 (talk) 19:23, 17 August 2021 (UTC)

I do see that the GW2 EN wiki is slow due to a very heavy load created by some recent template edits that are hitting the database hard, but I'm not sure why the GW1 wiki is slow. I'm looking into it. Justin Lloyd (talk) 19:32, 17 August 2021 (UTC)

This wiki (as well as the DE, FR, and ES GW2 wikis) is affected by the load created by the GW2 EN wiki since the web servers themselves are impacted by the GW2 EN database load. I've made an adjustment that should help and this is an ongoing issue that I'm continuing to investigate. Justin Lloyd (talk) 19:48, 17 August 2021 (UTC)

Are the culprit template(s) in low enough quantity to list out, or is this an issue with a lot of templates? I'm kinda hoping it's simply a matter of optimization, since it's a shame to see one wiki impacting the others so heavily. horrible | contribs 22:59, 17 August 2021 (UTC)

The more pages that ultimately use a template, the more jobs get created for the wiki to process. A good example is the Skill infobox template. Edits to that one alone can cause thousands to tens of thousands of jobs to be created that can take many hours for the job queue manager to fully work through (and jobs can create other jobs so it can drag for quite some time). It's fine that this happens, and I'm looking for ways to better tune the job queue manager, so right now I'm just pointing out the rough mechanics of how it works. Justin Lloyd (talk) 23:31, 17 August 2021 (UTC)

Database errors when using DPL w/ regex[edit]

Hi - I'm trying to filter DPL request results with regex, but I'm running into several issues:

Using a single lookahead or lookbehind causes the Database to report an error.
Using an OR pipe (¦) within ~~a lookahead/behind~~ any group causes the query to return unfiltered rather than erroring.

I've put examples up here if that helps. horrible 13:51, 20 May 2023 (UTC)