Guild Wars 2 Wiki:Reporting wiki bugs/archive 7

From Guild Wars 2 Wiki
Jump to: navigation, search

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

Yes Pages with apostrophe in title cause "too many redirects" error in Chrome

After trying to search for "Hero's Canton", I discovered that any page with an apostrophe in the title/URL causes Chrome to fail to load, citing a "too many redirects" error. I'm not a wiki or Chrome expert so I don't know why, but given that similar pages on Wikipedia load correctly, I'm inclined to suspect it's a problem with something this wiki is doing. NikkoJT (talk) 19:30, 16 March 2016 (UTC)

This doesn't appear to be just Chrome, as IE and Safari also exhibit the issue. I'm investigating. Justin Lloyd (talk) 19:48, 16 March 2016 (UTC)
And Firefox too, just to cover all bases. Also the bottom part of the page seems to be buggy too, I have to tab through the page and hit enter on the upload button to be able to upload images now because the button itself doesn't work. =( - Doodleplex 20:23, 16 March 2016 (UTC)
The upload button works in our test environment so at least it wouldn't appear to be a MediaWiki-specific bug. I'll investigate that as well. Thank you for pointing it out. Justin Lloyd (talk) 20:32, 16 March 2016 (UTC)
I would guess that its probably related to the "fix" implemented to work around "+" signs? (+10 Agony Infusion doesn't work either). -Chieftain AlexUser Chieftain Alex sig.png 20:46, 16 March 2016 (UTC)
I found a related issue in Phabricator ( so I applied a two-line fix to GlobalFunctions.php (lines 433 and 444 in the code at that link) and the affected pages appear to work now. Let me know if you see any further issues regarding this. Justin Lloyd (talk) 20:52, 16 March 2016 (UTC)
Just noticed your comment about plus signs as well. I'll see if a similar fix helps in our test environment. Justin Lloyd (talk) 20:57, 16 March 2016 (UTC)
Actually plus signs seem dangerous, though I have another place I can look regarding that. Justin Lloyd (talk) 21:00, 16 March 2016 (UTC)
Might also be related to why the link option in #ask (Example), which generates a link to Special:Ask, doesn't work at all now.--Relyk ~ talk < 21:17, 16 March 2016 (UTC)
For reference sake, Justin says via email that he has fixed the plus sign bug on all language wikis. -Chieftain AlexUser Chieftain Alex sig.png 17:25, 18 March 2016 (UTC)
Is the problem with #ask something related to a server software (e.g. Semantic MediaWiki) or content (i.e. that you guys can change)? -Stephane Lo Presti talk 22:06, 18 March 2016 (UTC)
The issue seems more like MediaWiki not liking the special characters in the URL generated by SMW. It's not a significant concern. The only thing I've used it for is links to query examples. Special:Ask itself uses an alternative way of forming the URL that works perfectly fine. The other site I checked had no problem handling the URL link generated by SMW.--Relyk ~ talk < 01:30, 19 March 2016 (UTC)

No Ampersands

(Reset indent) Hello, pages with ampersand also have this issue (fr:Chercheuse senior de PR&T Takka), thanks --IruleManik (talk) 08:38, 29 March 2016 (UTC)

I've fixed the ampersand issue. Justin Lloyd (talk) 21:45, 29 March 2016 (UTC)
Apparently pressing "edit" or "history" on these pages takes you to half the page title. e.g. go to Assist PR&T Esoterics with ooze research + press "edit" at the top :( -Chieftain AlexUser Chieftain Alex sig.png 19:07, 3 August 2016 (UTC)
I reported the issue in the wrong place ([1]). All pages with ampersand:
  titlematch = %&%
  columns = 3
  format = ,\n* [[%PAGE%]],,
The preceding unsigned comment was added by BryghtShadow (talkcontribs) at 03:47, 20 August 2016‎ (UTC). Edit: Forgot to sign. --BryghtShadow (talk) 03:49, 20 August 2016 (UTC)
Apparently it worked at one time because Talk:PR&T Esoterics exists but I can't comment on that or edit PR&T Esoterics to kill some extra space at the top of the page. Perhaps pages with it should be moved, replacing the ampersand with "and" and putting a note on the top of the page about technical difficulties instead? - Doodleplex 22:52, 30 September 2016 (UTC)
Ok, so workaround for that, if you click edit you go to a new page, fine. Now go into the URL and change it like so: "" to "". Notice the manual change of "&" to "%26". Note this is by no means a fix to the problem, but simple a way to work around the issue until it is solved. -Darqam (talk) 23:04, 30 September 2016 (UTC)
NOOOOOPE, don't do that. You'll create a new page. -Darqam (talk) 23:06, 30 September 2016 (UTC)
Yeah I tried that. =< (edit) I see Alex is having fun with the PR page, good thing we don't need that as an acronym for anything lol. (edit #2) Apparently leaving feedback works cleanly. 0.o - Doodleplex 23:08, 30 September 2016 (UTC)
Doodle, it used to work. Every other wiki on the face of the planet apart from GW1W manages to have ampersands correctly encoded. Example: w:A&W Root Beer. Afaik from a quick google search the issue is probably related to our URL shortener rules. -Chieftain AlexUser Chieftain Alex sig.png 23:14, 30 September 2016 (UTC)
Seems like the problem must exist elsewhere. This entry here posted just about 2 months ago apparently offers a solution. -Darqam (talk) 23:15, 30 September 2016 (UTC)
This problem is actually a result of our wikis running behind Microsoft IIS/ARR load balancers (along with other critical stuff so we can't make global configuration changes), and IIS/ARR likes to handle with URL-encoding in a way interferes with URLs with special characters that MediaWiki permits. We do have a long-term plan for dealing with this, but that's a little ways off. Justin Lloyd (talk) 18:36, 5 October 2016 (UTC)
(Reset indent) Just FYI, I'm testing a bit of javascript at the moment that seems to do the trick.
// Encode wiki links that might break, e.g. ampersands.
function encodeWikiElements(selector, attribute) {
  $(selector).each(function (i, element){
    var m = $(this).attr(attribute).match(/^(\/index\.php\?title=)(.*?)(&action=.*)$/);
    if ((m) && ( $(this).attr(attribute).search('%') === -1) ) { $(this).attr(attribute, m[1] + encodeURIComponent(m[2]) + m[3]); }
encodeWikiElements('a[href]','href'); // Changes links, e.g. to view history pages
encodeWikiElements('form[action]','action'); // Changes forms, e.g. to submit edits
I fail to believe we can't apply that serverside in the mediawiki files somewhere. -Chieftain AlexUser Chieftain Alex sig.png 21:15, 18 November 2016 (UTC)
Hey Alex, we're busy with a few things now but I'll keep it on my list of things to check after the maintenance. Thanks for looking into it --Stephane Lo Presti talk 21:44, 18 November 2016 (UTC)

No File Upload Bug

Went to upload a better version of [[:File:Euryale.jpg]] and got:

  • Could not read or write file "mwstore://local-backend/local-public/c/c3/Euryale.jpg" due to insufficient permissions or missing directories/containers.
  • Could not store file "/tmp/php2rXVH2" at "mwstore://local-backend/local-public/c/c3/Euryale.jpg".

Uploaded a picture of another NPC before and after that one, so it seems to just be this file. - Doodleplex 05:55, 17 August 2016 (UTC)

Should be fine now. I deleted it, and then pulled it back from the dead, and it seemed to work. However, the image is not appearing on the article, which I'm hoping is just a cache bug for now. —Ventriloquist 10:28, 17 August 2016 (UTC)

No 502 and 503 errors

Please report any 502 or 503 errors encountered whilst editing or using pages here, and include the date+time of the page attempted too.

  • I'd like to say that over the past 2 days I've been editing, creating new pages, and moving file a whole lot and have had no 503 or 502 at all. Seems like the problem might be fixed? *crosses fingers* -Darqam 19:48, 22 November 2016 (UTC)
    • It's not fixed, I've had 502 almost every time I moved a file in the past couple of days. It still moves it, but it takes ages and shows me '502' instead of 'move successful'. -Azurem (talk) 20:40, 22 November 2016 (UTC)

Pages with percent in title for SMW special pages

Using 30% Magic Find Bonus as example.

I believe that's all the percent related issues with SMW's special pages. --BryghtShadow (talk) 05:08, 20 August 2016 (UTC)

No Protection reason not given

Pages which have been protected no longer show the reason for the protection when you view the source code. You're told "You do not have permission to edit this page, for the following reason:" but nothing else follows. Granted I may be crazy and the wiki never did provide the reason; it's been ages since I would have checked. This issue is also true on the GW1W. G R E E N E R 17:35, 28 September 2016 (UTC)

Can you provide some examples, please? —Ventriloquist 20:31, 28 September 2016 (UTC)
example (obviously you need to view the source whilst logged out or using a private browsing instance. - 21:19, 28 September 2016 (UTC)
Hot Pink Dye doesn't have one. The page history makes it self-explanatory though. The other pages on [2] show the reason as expected.--Relyk ~ talk < 01:12, 29 September 2016 (UTC)
Uh after removing the protection and then readding it, I'm still not seeing a reason given. Caveat: only when logged out. -Chieftain AlexUser Chieftain Alex sig.png 06:47, 29 September 2016 (UTC)
"06:46, 29 September 2016 Chieftain Alex (Talk | contribs) protected "Hot Pink Dye"‎ ‎[edit=autoconfirmed] (indefinite)‎[move=autoconfirmed] (indefinite) (Excessive spamming: Apologies for the lack of reason last time being confusing.) (hist) View full log" Is what I see on the hot pink dye page when editing now. Seems good? -Darqam (talk) 14:02, 29 September 2016 (UTC)
I'm still only seeing "You do not have permission to edit this page, for the following reason:" sans reason, even on those other pages. Using Firefox and Chrome, and via Monobook. I am viewing that while logged out. G R E E N E R 16:11, 29 September 2016 (UTC)
Yup. --Chieftain AlexUser Chieftain Alex sig.png 18:19, 29 September 2016 (UTC)
Would the problem be from the "view source" portion of it then? Since it seems like the "edit" page shows it fine. -Darqam (talk) 18:24, 29 September 2016 (UTC) - basically it omits the useful information as to precisely why the page was protected (which is stupid). I suppose we could write some javascript to insert it. -Chieftain AlexUser Chieftain Alex sig.png 19:07, 29 September 2016 (UTC)
Yeah. It was brought to my attention after I protected a page for the third time in a rather snide way. A contributor pointed out that I couldn't get frustrated with people for not understanding a message they weren't receiving. G R E E N E R 20:04, 29 September 2016 (UTC)
It's the same behavior as Wikipedia, so looks designed that way. That's very unhelpful behavior by Mediawiki...--Relyk ~ talk < 20:18, 29 September 2016 (UTC)
// Display protection log information for users who cannot edit protected pages
function anonymousQueryProtectionLog () {
    if ( mw.config.get('wgAction') === 'edit' && document.getElementsByClassName('permissions-errors')[0] != null ) {
        // Helper function to display times and dates correctly
        function padzero (s) {  return (s < 10 ? '0' : '') + s; }

        // Query the wiki API to fetch the protection log details
        var qstr = '/api.php?action=query&format=json&list=logevents&letype=protect&letitle='+encodeURIComponent(mw.config.get('wgPageName'))+'&lelimit=1i&leprop=title|user|timestamp|parsedcomment|details';
            var data = querydata.query.logevents[0];

            // Pages protected prior to 2015 don't return a timestamp or user.
            // Give up because there isn't any useful data available.
            if (!('timestamp' in data)) {
                console.log('Page was protected prior to 2015.');
            var comment = ''; if (data.parsedcomment !== '') { comment = '<span class="comment">('+data.parsedcomment+')</span>'; }
            var details = data.params[0], ptype = 'semi-protected', pexplain = 'registered users';
            if (details.match(/^[edit=sysop]/i)) { ptype = 'protected';  pexplain = 'users with administrator privileges'; }

            // Convert the given mediawiki timestamp string 'YYYY-MM-DDThh-mm-ssZ' into something we can use
            var timestamp = data.timestamp;
            var date = new Date(timestamp.substr(0,4), timestamp.substr(5,2), timestamp.substr(8,2), timestamp.substr(11,2), timestamp.substr(14,2), timestamp.substr(17,2));
            var datestring = padzero(date.getUTCHours()) + ":" + padzero(date.getUTCMinutes()) + ", " + padzero(date.getUTCDate()) + " " + mw.config.get('wgMonthNames')[date.getUTCMonth()] + " " + date.getUTCFullYear();

            // Generate a box identical the default mediawiki protection log message for logged in users
            var boxString = '<div class="mw-warning-with-logexcerpt mw-content-ltr" dir="ltr" lang="en">'
                             +'<b>Warning:</b> This page has been <b><a href="/wiki/Special:ProtectedPages" title="Special:ProtectedPages">'+ptype+'</a></b>, so that only '+pexplain+' can edit it.\n'
                             +'<li class="mw-logline-protect">'+datestring+' <a href="/wiki/User:'+encodeURIComponent(data.user)+'" title="User:'+data.user+'" class="mw-userlink">'+data.user+'</a> <span class="mw-usertoollinks">(<a href="/wiki/User_talk:'+encodeURIComponent(data.user)+'" title="User talk:'+data.user+'">Talk</a> | <a href="/wiki/Special:Contributions/'+encodeURIComponent(data.user)+'" title="Special:Contributions/'+data.user+'">contribs</a>)</span> protected "<a href="/wiki/'+encodeURIComponent(data.title)+'" title="'+data.title+'">'+data.title+'</a>" '+details+' '+comment+' <span class="mw-logevent-actionlink">(<a href="/index.php?title='+encodeURIComponent(data.title)+'&action=history" title="'+data.title+'">hist</a>)</span> </li>\n'
                            +'<a href="/index.php?title=Special:Log&page='+encodeURIComponent(data.title)+'&type=protect" title="Special:Log">View full log</a>'
^That's my proposal. It'd probably go in the bottom of the common.js. --Chieftain AlexUser Chieftain Alex sig.png 21:44, 29 September 2016 (UTC)
Out of curiosity, is 2015 a hard cut-off for a reason? Or will it be a cut-off which slowly moves forward as the wiki forgets things? (I noticed such an oddity with the abuselog API). G R E E N E R 16:30, 30 September 2016 (UTC)
I figure the internal table that stores the list of all protected pages used on Special:ProtectedPages was introduced circa 2015, you can see the timestamp/user are blank for the earlier ones. Abuselog used to be limited to a few months of data before that was changed. -Chieftain AlexUser Chieftain Alex sig.png 21:55, 30 September 2016 (UTC)

Is there any way I can convince you to do a trial run of that code on the gw1w at some point? I'll pay you in ToT bags ; ) G R E E N E R 19:07, 22 October 2016 (UTC)

Paste it straight on to gw1:MediaWiki:Common.js. -Chieftain AlexUser Chieftain Alex sig.png 19:39, 22 October 2016 (UTC)
Looks great, thanks Alex! Farming ToT bags for you now. G R E E N E R 20:05, 22 October 2016 (UTC)

Steam.png not showing up.

File:Steam.png is not displaying at the moment. Tyndel (talk) 02:30, 9 November 2016 (UTC)

Looks fine to me. Did you refresh everything(page, null edit, internet cache, etc.)? - Doodleplex 02:42, 9 November 2016 (UTC)
Yeah I did all that. Maybe it goes away by itself soon. Tyndel (talk) 02:45, 9 November 2016 (UTC)
Is there a certain page it's now showing up on for you or is it all pages that use it's image? Because if it's a user page, that might be due to user code and not the file. - Doodleplex 02:54, 9 November 2016 (UTC)
Not showing up anywhere except for here. Infoboxes and tables it's just a blank square. Tyndel (talk) 02:57, 9 November 2016 (UTC)
I just checked Firefox, IE and Chrome, and it shows up for me, so it's probably just an odd bug that should resolve itself. - Doodleplex 03:17, 9 November 2016 (UTC)
Lol, I'm having the same issue. Yeah I'd just give it time. Same thing has happened before, and waiting it out has always fixed it for me. -Darqam 04:11, 9 November 2016 (UTC)

Drop rate research gives out errors in table

Pile of Silky Sand drop rate table has Expression error: Unrecognized punctuation character ",".% displayed in the main page. Also the percentages should be looked at... --WormholeGo ahead and talk. ≈ 01:38, 20 November 2016 (UTC)

I've revised the Drop rate result table chart template, basically I set all the drop rate tables to be manual totals, so they are no longer using percentages. I guess the .percentage sign error has gone too. -Chieftain AlexUser Chieftain Alex sig.png 02:04, 20 November 2016 (UTC)
|Nope, still there. I should point out, that I'm using Finnish settings on my PC, which likes to differentiate decimals with a ',' and not a '.' . Also, whilst posting this I happened upon another bug. Trying to link the "Nope, still there" link, the link takes in 'too much' and if you use a space, the vertical mark shows up... --WormholeGo ahead and talk. ≈ 16:07, 20 November 2016 (UTC)
Quick note on the link "issue". full urls only need a space and the you type the word like this, where as internal links take 2 brackets and need the "|" delimiter like this. Also, if you are using comma delimiters, could you not simply change them to periods for the purpose of submission?-Darqam 16:37, 20 November 2016 (UTC)
Understood, my bad on the link. But there's no user entered commas or periods in the data. Chieftain Alex fixed it and works fine now. --WormholeGo ahead and talk. ≈ 18:28, 20 November 2016 (UTC)
Hmm okay catering for commas in numbers should be fixable using {{formatnum: }}, and indeed the comma errors have gone away for me now when viewing with "uselang=fi" in the address bar. For some reason the maths breaks down (the /100 doesn't look like it is functional), although it works fine when viewed in English. -Chieftain AlexUser Chieftain Alex sig.png 18:07, 20 November 2016 (UTC)
Fixed I think. Good ol hash sign after SMW queries. -Chieftain AlexUser Chieftain Alex sig.png 18:23, 20 November 2016 (UTC)
Works now, thanks! Kinda weird this didn't come up sooner... Commas are widely used in other European countries. --WormholeGo ahead and talk. ≈ 18:28, 20 November 2016 (UTC)
Well the spanish, french and german wikis use their own templates, so that's a chunk of Europe dealt with. -Chieftain AlexUser Chieftain Alex sig.png 18:54, 20 November 2016 (UTC)

Database error

"A database query error has occurred. This may indicate a bug in the software." Got this when trying to move "Despina Katyn" to "Despina Katelyn". Might have been because Darqam was trying to do it at the same time, I don't know. - Doodleplex 18:48, 21 November 2016 (UTC)

I got some really funny errors as well doing this, have seen it before with using move at the same time as someone else. Would blame it on that for now. -Darqam 18:52, 21 November 2016 (UTC)

Yes Images are Breaking

In all of the chaos of uploading new stuff from the the new area/new weapon and armor pictures, lots of icons getting moved to drop "skin" from the name, or just being moved in general, I'm seeing lots "Error creating thumbnail: Unable to save thumbnail to destination". Fused weapon skins, "File:Kaiser Snake Rifle.jpg", and "File:Kaiser Snake Staff.jpg"(actually I think most of the Kaiser weapons, or the ones I've come across) as well as File:Flame Out (1).png, File:Flame Out (3).png, and File:Flame Out (4).png. I also had some issues with images that I updated not showing up correctly until over 48 hours later, and I checked these images on two separate computers/internet connections no where near each other to confirm it wasn't on my end. - Doodleplex 19:44, 22 November 2016 (UTC)

With a prompt from Daniel on the german wiki, Justin went in and deleted a bunch of folders on the server which had the wrong folder owner (no permission to create thumbnails). -Chieftain AlexUser Chieftain Alex sig.png 00:35, 16 March 2017 (UTC)

Yes File Size

Already mentioned it on Reddit but figured reposting here won't hurt either. This might not be a bug and more unintentional change, but the max file size before was 8 MB, now it's 2 MB. 2 MB might be a bit of a problem in regards to maps, as most zone maps start at 2 MB and go up. - Doodleplex 04:10, 1 December 2016 (UTC)

This appears to have been a change in the default PHP settings since we went from 5.3 to 7.0. I've increased the maximum upload size, can you confirm whether it's working? Not sure if I need to restart PHP or if a reload suffices? :) Justin Lloyd (talk) 04:38, 1 December 2016 (UTC)
It says it's back to 8 MB. Lovely, thanks! - Doodleplex 04:45, 1 December 2016 (UTC)

Bugs related to the wiki maintenance

Hi guys, please leave found bugs post-wiki maintenance in this section. --Chieftain AlexUser Chieftain Alex sig.png 07:34, 1 December 2016 (UTC)

Yes Event timers (Widget:Event timer)
World bosses not showing at times expected. Probably related to SMW time/date -Chieftain AlexUser Chieftain Alex sig.png 07:34, 1 December 2016 (UTC)
Fixed. (SMW wiki API output format changed for values using timestamps - pretty rarely used format so shouldn't occur elsewhere). -Chieftain AlexUser Chieftain Alex sig.png 19:01, 1 December 2016 (UTC)
No Personal JS - importScript
This is not a bug, and this function has now been removed from the core. Let me know on my talk page if you need help updating it. -Chieftain AlexUser Chieftain Alex sig.png 07:34, 1 December 2016 (UTC)
We could actually provide that function in MediaWiki:Common.js to maintain compatibility with existing code.. if people would want that. poke | talk 07:58, 1 December 2016 (UTC)
Should probably look like this: function importScript(page) { mw.loader.load('/index.php?action=raw&ctype=text/javascript&title=' + encodeURIComponent(page)); } poke | talk 08:02, 1 December 2016 (UTC)
Using F12->consol in firefox, I'm seeing quite a few reference errors coming from 'load.php' towards this function. Is it used in internal files? -Darqam 13:30, 1 December 2016 (UTC)
@poke; I don't think many people use custom cs in the first place, so it shouldn't be too arduous to update each user script as they are reported. -Chieftain AlexUser Chieftain Alex sig.png 18:06, 1 December 2016 (UTC)
@darqam; sometimes I get a console error with "$.client is undefined" when visiting special:RecentChanges, but mostly I don't. I don't know what causes this, but it could be that I have the "Group changes by page in recent changes and watchlist" box ticked in my preferences. It happens in monobook/vector. Otherwise i've not seen any other messages in the console yet. -Chieftain AlexUser Chieftain Alex sig.png 18:08, 1 December 2016 (UTC)
Yes MediaWiki:InterwikiSearchRedirect.js
The search box html ids changed between versions. This has now been resolved and partially fixes the console bug on recentchanges I mentioned above. -Chieftain AlexUser Chieftain Alex sig.png 18:17, 1 December 2016 (UTC)
Yes SMW vendor table html tag not closing

Tables are acting funny on some pages see here. -Drago 02:55, 2 December 2016 (UTC)

The issue seems to come from "{{vendor table|vendor=Bartender_(norn)|item=Observational Zymology Manual}}". Notably the cost section. Commenting out this line seems to make things work ok. -Darqam 03:04, 2 December 2016 (UTC)
edit: Issue seems to stem from vendor table template, both actually cause issues but only in the last entry of the table. -Darqam 03:05, 2 December 2016 (UTC)
That’s fixed now. There was some error with the SWM query of the vendor table that caused an SMW error to be rendered at the end of the line, causing the closing table tag not to be on its own line which causes it not to be handled, so that table never got closed.
Can someone of the SMW pros look at my change here and tell me if that change is okay, or if those default values are actually needed for something? poke | talk 07:04, 2 December 2016 (UTC)
Nice spot on the error tag. I wouldn't have thought that the "default" >0 queries would have been reached. I've added another query provision in the line above which should apply if the min/max/currency isn't set (so just using {{vendor table}} now will show all vendor results for all currencies. I am surprised however that SMW still doesn't offer the option to move the "further results..." to a new line though :( (table ends still fall over) -Chieftain AlexUser Chieftain Alex sig.png 07:34, 2 December 2016 (UTC)
Yeah, using the currency record for default was a terrible idea trying not to hack in a default value.--Relyk ~ talk < 10:15, 2 December 2016 (UTC)
Yes AWB and Pywikibot connection issues
As of the maintenance, it is impossible to connect to and via AWB and pywikibot. A start of the conversation was started here. The issue seems to be present for the en and es wiki (but not the fr and de wiki for some reason). An image of the error is given here (image from Chieftain Alex). -Darqam 18:44, 5 December 2016 (UTC)
Hi Darqam (and Alex), it seems to be an issue related to an app, so at this point we'll be waiting for you to give us more technical information. We can help once you know more about what needs to be done (if anything) on the servers' end. It's the first time I heard about AWB, is this something worth sharing more widely with wiki editors? Thanks --Stephane Lo Presti talk 19:49, 5 December 2016 (UTC)
I can't give you technical stuff, but AWB is Auto Wiki Browser, a program we use to do lots of repetitive edits quickly and without killing recent change log. It's a very handy, very useful tool. - Doodleplex 19:55, 5 December 2016 (UTC)
Maybe Justin could start by telling us if there are any differences in the setup of the different language wikis? (EN GW1, EN GW2, ES GW2 all stopped working - FR GW2 and DE GW2 all work okay). -Chieftain AlexUser Chieftain Alex sig.png 20:29, 5 December 2016 (UTC)
Alex, there aren't any significant differences between the wikis other than GW1 doesn't use SMW. I do notice, however, that FR and DE use vector as their default skins while the other three use monobook. Is that a possible culprit? Justin Lloyd (talk) 20:38, 5 December 2016 (UTC)
Seems unlikely to be honest - as far as I know the robot scripts connect using the mediawiki API without touching the skins/appearance of the wikis. Given that all the wikis use the same version I would have thought they'd behave in the same way. I thought it was related to the mediawiki update changing the API format, but if that was the case, the german/french wikis would be broken too. -Chieftain AlexUser Chieftain Alex sig.png 20:48, 5 December 2016 (UTC)
Right. There are some minor config variable differences between the wikis based on community requests and a couple of extensions, but otherwise they all run identical versions of MediaWiki and extensions (basically the content directories are identical except for LocalSettings.php). Justin Lloyd (talk) 20:55, 5 December 2016 (UTC)
Puzzling. My trial and error nature would be tempted to disable all the extensions on the stage and see if we can connect to that. -Chieftain AlexUser Chieftain Alex sig.png 21:11, 5 December 2016 (UTC)
Actually wait, I recall a really old thread where including any whitespace at the top of a php file caused it to break AWB functions. Maybe its that? (edit: link) -Chieftain AlexUser Chieftain Alex sig.png 21:14, 5 December 2016 (UTC)
I just checked to be sure, none of the wikis' LocalSettings.php files have whitespace before <? and none of the have ?> at the end at all, which is how it's been forever, so I'm guessing that it's not the whitespace issue. Are you able to replicate the AWB issue against the stage wikis to match the behavior of the live ones? Justin Lloyd (talk) 21:19, 5 December 2016 (UTC)
Yes, stage wikis currently give the same error as live ones (DE/FR = okay, EN1/EN/ES = failed). -Chieftain AlexUser Chieftain Alex sig.png 21:20, 5 December 2016 (UTC)
So I found the issue with AWB, and already opened a proper issue about it. You can find a fixed exe here which should work fine until we fixed the issue on our end.
The issue is that there is a namespace mismatch that causes the configuration phase to break with AWB. I assume (not sure yet) that pywikibot has a similar problem. I’ve already emailed Justin to check that. poke | talk 21:49, 5 December 2016 (UTC)
Nice find on a probable solution. I can't actually get patched AWB to connect either though. -Chieftain AlexUser Chieftain Alex sig.png 21:58, 5 December 2016 (UTC)
Oh! My mistake. Did not realize I was actually updating the DLL, not the exe… Link above is updated. poke | talk 22:18, 5 December 2016 (UTC)
Huzzah! It works! -Darqam 22:28, 5 December 2016 (UTC)
Glad to hear that! :)
Just FYI on the actual issue with our configuration: Apparently this is caused by a SMW regression and Justin is working on preparing a quick SMW update to get this fixed. poke | talk 22:48, 5 December 2016 (UTC)
Just want to mention that we'll try to expedite the process (minor versions do not require full testing passes) but we'll still do a little bit of testing to make sure that nothing breaks. No promise on the ETA but hopefully it won't take too long :) Thanks to poke on the troubleshooting and fixes! --Stephane Lo Presti talk 22:51, 5 December 2016 (UTC)

(Reset indent) Has this been fixed? I was just able to connect a non-Poke-patched AWB version by accident, so I'm curious. - Doodleplex 18:34, 14 December 2016 (UTC)

Stephane sent an email out about 18 minutes ago that SMW has been updated to 2.4.4 from 2.4.1, which had the bug in it. So yeah it should be working now. Poke's Special:ListTransclusions also works now. -Chieftain AlexUser Chieftain Alex sig.png 18:40, 14 December 2016 (UTC)

Yes Screenshots not loading up

For some time now, every new screenshots I uploaded and still do doesn't change automatically to the new one for some strange reason. Is it a problem on my end? It's kinda annoying when I want to see what it looks like on the final article. || Louise || 03:38, 10 December 2016 (UTC)

It could be your browser cache. Try hitting ctrl+f5 (on firefox) for a force refresh. Alternately try opening the same page on an alternate browser. if the page looks the same on both browser, it might be a wiki-cache issue. -Darqam 03:42, 10 December 2016 (UTC)
I'm using Chrome. Is there a way to clear the wiki-cache? It wasn't doing that a couple months back, atleast not at the time of the Rising Flame release. || Louise || 03:44, 10 December 2016 (UTC)
I believe for chrome it's ctrl+F5. for the wiki chache, try clicking on the clock on the top of the page (or digital timer thingy). -Darqam 03:48, 10 December 2016 (UTC)
Ctrl-F5 seems to work. I tried to click the time thing and F5 only and none of those did anything. Atleast now I have a workaround. Cheers. || Louise || 03:50, 10 December 2016 (UTC)
What he said, and if you want you can also go to the three dots on the end -> More Tools - > Clear Browsing Data ->Cached Images and Files. Sometimes though, it's just weird stuff and won't update itself for a day or so, which I discovered when mass uploading weapon images last month. X_x - Doodleplex 03:51, 10 December 2016 (UTC)

(Reset indent) Hi everyone, is this a common issue experienced by wiki editors? I'm asking in particular after the maintenance 2 weeks ago, because a lot of software was updates and one of them was the server caching software Varnish. Let me know! --Stephane Lo Presti talk 16:35, 12 December 2016 (UTC)

I could be wrong but the cache probably lasts for 24 hours or something like that, so I'd only record it as an issue if it doesn't update after that period has elapsed. -Chieftain AlexUser Chieftain Alex sig.png 18:06, 12 December 2016 (UTC)
All I know is that it was fine a couple weeks back, atleast at the time of the latest Living World release. I never had to clear my Cached Images and Files, as it was recommended to me, before. I have resorted to spamming CTRL-F5 each time for now but it would be great if there was a fix or to atleast know if it's a problem on my end. || Louise || 18:36, 12 December 2016 (UTC)
After uploading a new version of an image, you can a) wait for the wiki-side cache to update itself, or b) go to the file page and click on the wiki clock (which will force a purge of the wiki-side cache). You should only need to do CTRL + F5 once to see the update (this clears your local cache, not the wiki cache). Note that if the file isn't updating on a page where the file is linked, that page has to be purged too (either by waiting or clicking on the clock). -Chieftain AlexUser Chieftain Alex sig.png 19:30, 12 December 2016 (UTC)
I tried clicking on the wiki clock before but it wasn't doing anything either, if I recall correctly. || Louise || 19:38, 12 December 2016 (UTC)

No Console message (vector only)

Exception in module-execute in module site:  load.php:178:411
TypeError: $.client is undefined TypeError: $.client is undefined
Stack trace:
@ line 4 > eval:4:715
@ line 4 > eval:4:696

Anyone know why i randomly get this error appear in my javascript console whilst visiting the occasional page? (about 1 in 20 pages, randomly occurring) - I've disabled all my personal javascript/css additions. -Chieftain AlexUser Chieftain Alex sig.png 21:15, 5 January 2017 (UTC)

Any special browser, or all of them? poke | talk 18:27, 6 January 2017 (UTC)
Currently firefox. I can try another browser and see if I can reproduce it. -Chieftain AlexUser Chieftain Alex sig.png 18:49, 6 January 2017 (UTC)
Hmm, I also use Firefox and just tried quickly to reproduce it but couldn’t. I’ll try more harder. poke | talk 23:34, 6 January 2017 (UTC)
It happens quite rarely, and very inconsistently. Sometimes it's when I've pressed edit, and sometimes when I visit RC.
(expanding the Edge message leads to the same breakdown of the stack trace, albeit with line numbers different by 1/2 lines (guess it formats it differently) -Chieftain AlexUser Chieftain Alex sig.png 13:39, 7 January 2017 (UTC)
I'm still getting this error, pretty frequently too (naturally it prevents any JS running, so the vector clock doesn't appear) -Chieftain AlexUser Chieftain Alex sig.png 00:39, 16 March 2017 (UTC)
So it sounds like it has been patched on MW within the last week! Maybe we'll see it when we eventually upgrade to something above MW 1.29 -Chieftain AlexUser Chieftain Alex sig.png 00:59, 16 March 2017 (UTC)