User talk:Emily Diehl/Wiki discussion archive 6

From Guild Wars Wiki
Jump to navigationJump to search


Deadlocks are back.

It appears that when accessing talk pages I encounter the SQL Deadlock error, looks like it's bad with a vengeance. UserDrago-sig.gif Drago 04:06, 6 November 2008 (UTC)

The SQL errors seemed to have ceased. For the moment... UserDrago-sig.gif Drago 04:19, 6 November 2008 (UTC)
On another note, I sent you an email. :) UserDrago-sig.gif Drago 04:21, 6 November 2008 (UTC)
"A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:(SQL query hidden)from within function "SiteStatsUpdate::doUpdate". MySQL returned error "1213: Deadlock found when trying to get lock; try restarting transaction (172.30.129.98)"."
While trying to access ArenaNet_talk:Developer_updates#VOD.2Bdmg through FireFox. --TalkAntioch 16:25, 6 November 2008 (UTC)
Another issue perhaps? I quote:Parse error: syntax error, unexpected ')' in /home/httpd/guildwars/external_includes/en_mysql_pw on line 29

Have no idea what this is, but it happened as I was looking for a boss for SF Afflicted Soon Kim. -- UglyLooking 16:57, 6 November 2008 (UTC)

Time

Not sure if this is the right place to put this, but the Wiki's time seems to be off. My Watchlist says a change occured on November 8th, when it is November 7th in all of America. I'm a bit novice at Wiki so maybe it's a personal user setting that for some reason is screwed up, but better safe than sorry! DarkNecrid 01:58, 8 November 2008 (UTC)

It did that to me, but -you- need to dig in your preferences/settings and put your time offset.-- User Vanguard VanguardLogo.pnganguard 01:59, 8 November 2008 (UTC)
(Edit conflict) See your preferences to set your local time zone; that will change the time settings that are viewed on special pages (e.g. watchlist, recent changes, page history etc). Comment timestamps will stay as UTC as that's what the server setting is, though. --User Brains12 Spiral.png Brains12 \ talk 02:02, 8 November 2008 (UTC)
Alright thanks guys! It's just weird because I thought before this it used Pacific time (I've been on this time before and it'd still say NOVEMBER 7TH for everything basically.) DarkNecrid 02:03, 8 November 2008 (UTC)
You have to reset it when the change happens for Daylight Savings which for most in the US was last Sunday. --Wyn's Talk page Wyn 03:43, 8 November 2008 (UTC)

question or comment

So when you upgraded the wiki software, what changed? Meaning, are there new features, maybe some bugs fixed? I see nothing. Vael Victus Pancakes. 01:32, 10 November 2008 (UTC)

See http://www.mediawiki.org/wiki/Release_notes/1.12#New_features_in_1.12. -- Gordon Ecker 02:47, 10 November 2008 (UTC)

Your Characters Tab :D

Well I was browsing thru the wiki and found your user page got to the characters tab and checked all characters then I noticed a bug, if you would select Celeste, Ryiinn or Lianne the Journal tab appeared to be selected. I knew what the problem was so I took the liberty of fixing it because I have nothing to do and have to much free time and you're probably busy with more important stuff. I hope you're not mad. Qaletaqa 01:57, 13 November 2008 (UTC)

Not at all! Thanks so much :) --UserEmilyDiehlStar.gif Emily Diehl (talk) 02:09, 13 November 2008 (UTC)

Halloween Event 2008

Hey Emily i am a super gw fan and your the only staff member i can locate is there a perticular reason that the halloween decorations are still up in Droks, Kamadan, Tomb of Primeval Kings, and LA, ect... cause its November 12, 2008 and frankily im getting annoyed at them they been there for weeks and i miss the regular versions of the city's.

also any voulenteer job openings :D love the game and would love to help in any way whatsoever

thanks for all you have done for the wiki and the game. KellyLSB 02:30, 13 November 2008 (UTC)

You are posting on the biggest anet volunteer job there is right now. --LemmingUser Lemming64 sigicon.png 02:32, 13 November 2008 (UTC)
True never thought of it that way KellyLSB 02:35, 13 November 2008 (UTC)

Low Cost Linux Solution?

I have been thinking about building a box just for GW and Ventrilo but I am not really sure where to start.

My current Microcrap Dell barely gets me 20-30fps under minimal settings with loads of lag in my average ping times. Ideally, I'd like to be able to host my vent server with the option of leaving GW running 24/7 with medium to max quality settings. I'd be happy with 60+fps and an avg ping that keeps my ping meter green.

I have a feeling my current system with its bloated registry and other issues is to blame for much of my lag, video, and rubberbanding issues. Instead of dealing with that antique...

Could someone suggest a reasonably low cost solution that will make my GW experience more visually enjoyable (ie higher settings that dont produce errors or glitches) and a smooth network interface. Please include every part necessary, linux build, and whatever other software I will need to get GW running smoothly at med/high to max settings (assume I can buy ea. individually at a local pc shop or online). Possible cost? How cheap can I build this considering GW, vent, and some sort of internet browser will be the only things ever run on this box.

Thank you in advance...

Elric Coy 02:41, 15 November 2008 (UTC)

You'd be better off posting this on Guru, not on Linsey's Emily's page. --Kokuou 03:02, 15 November 2008 (UTC)
You could also try Talk:Guild Wars on Wine. -- User Gordon Ecker sig.png Gordon Ecker (talk) 03:11, 15 November 2008 (UTC)
I think you mean Emily, Kokuou. Linsey's talkpage is on Linsey's talkpage. =D --User Jioruji Derako logo.png Jïörüjï Ðērākō.>.cнаt^ 03:12, 15 November 2008 (UTC)
This is a place you might want to check out. -- WoBUser Wings of Blood sig icon.png 04:19, 15 November 2008 (UTC)
Ack! I'm such a scatter-brain! Yes, of course I meant Emily. ^_^;; --Kokuou 10:11, 15 November 2008 (UTC)

Image cache problems:The reprise

I hate to tell you this Emily, but since the hardware upgrade/software downgrade, the image cache problems seem to be back in full force when dealing with replaced images. See Image talk:Norn Woad m ritualist.jpg for one example, I have also been having cache issues with other armor image replacements (too many to list individually). --Wyn's Talk page Wyn 17:40, 12 October 2008 (UTC)

Oh no...are you serious? Uggghhh... T_T Thanks for the heads up! I'll pass it along and hope that it was something simple that got affected by our problematic security update. --UserEmilyDiehlStar.gif Emily Diehl (talk) 16:59, 13 October 2008 (UTC)
Apropos problematic security update: It seems as if the update somehow disabled edits by sysops/bcrats being automatically patrolled. Might be just a rights-setting, might as well be more :P poke | talk 18:09, 13 October 2008 (UTC)
About the patrolling, based on what I've seen it appears that they are patrolled just not listed maybe. Unless someone is patrolling my edits it doesn't seem to have a ! next to it right after I make it. --Kakarot Talk 20:17, 13 October 2008 (UTC)
Hm, you're right. I wonder if it is an error from that update or if it was intended to not show them in future versions. Btw. the wiki logo is broken!? poke | talk 20:21, 13 October 2008 (UTC)
Hm? I don't see it broken on this end. What are you seeing, Poke? --UserEmilyDiehlStar.gif Emily Diehl (talk) 20:57, 13 October 2008 (UTC)
It fixed itself some minutes after my comment.. :P poke | talk 21:05, 13 October 2008 (UTC)

(reset indent) Heya again guys! My IT compadre tracked down the issue with the woad image, and told me that the problem should be resolved. He also looked into the patrolled changes issue and found that $wgUseRCPatrol = true; has actually never been set. Do you guys want us to set it for you? --UserEmilyDiehlStar.gif Emily Diehl (talk) 23:26, 13 October 2008 (UTC)

Heya Poke...do you want me to ask for this change to get implemented while we're mucking around in LocalSettings?? --UserEmilyDiehlStar.gif Emily Diehl (talk) 19:14, 15 December 2008 (UTC)
According to the manual it is enabled by default, so there is no need to set it explicitly. poke | talk 19:18, 15 December 2008 (UTC)
Ah ha! I didn't realize that and forgot to double check, haha. You win this round, wiki mans. Thanks :) --UserEmilyDiehlStar.gif Emily Diehl (talk) 20:44, 15 December 2008 (UTC)

Wiki problems

From about 15:35 to about 16:15 UTC today, the wiki was redirecting to the Network News page again (for me, for everyone awake on IRC at the time, for at least 2 people who talked to me in-game, and there's a rather glaring gap in Recentchanges). This has been happening off and on for like a week now. Could you give IT a poke and see what's up with this when you get a chance? - Tanetris 16:49, 11 December 2008 (UTC)

Hiya Tanetris! We're already aware of this issue, and IT is looking into what caused the outage this morning. I'll let you know what I find out, and we apologize for the unplanned downtime. --UserEmilyDiehlStar.gif Emily Diehl (talk) 19:11, 11 December 2008 (UTC)

Wiki upgrade coming Monday!

Hi guys! I just wanted to give you a heads-up that we'll be doing the upgrade to 1.13.2 here and on the GW2W on Monday. Since there are a bunch of DB changes, the upgrade duration is a little longer. The scheduled downtime is from 4:30 am Pacific (so 12:30 pm GMT) until 8:30 am Pacific (4:30 pm GMT), so somewhere in the range of four hours.

I'm going to post a network news post on the website, but I wanted to give you guys advanced warning so you can get a maintenance header in place for the weekend. For the curious, here are the SVN MediaWiki patch notes for the 1.13 snapshot. Yay for new features and bugfixes! --UserEmilyDiehlStar.gif Emily Diehl (talk) 23:34, 12 December 2008 (UTC)

yay, great! Thanks for the great news, Emily! poke | talk 23:39, 12 December 2008 (UTC)
Why did it take 2 months to install a security patch? --The preceding unsigned comment was added by User:170.167.4.210 (talk).
It's not just a security patch. It's an upgrade to MediaWiki's quarterly version update. Check out the linked update notes to see the extent of the changes...they are significant. --UserEmilyDiehlStar.gif Emily Diehl (talk) 23:57, 12 December 2008 (UTC)
Thank you for the heads up...--Silverleaf User Silverleaf sig.pngDon't assume, ask! 00:00, 13 December 2008 (UTC)
Emily, I have some configuration requests for when MediaWiki 1.13 goes live. Could you ask the IT to set the setting $wgEnableWriteAPI = true (disabled by default in 1.13 and below) and maybe the writeapi right disabled for non-admin/bot usergroups (= *, user, autoconfirmed, emailconfirmed) to make sure it won't be abused by vandals. Thank you :) poke | talk 00:10, 13 December 2008 (UTC)
Poke, always on top of the next exploit. Cheers! --TalkAntioch 00:11, 13 December 2008 (UTC)
Hiya Poke! Thanks for the heads up...I sent an email off to IT about it tonight :) --UserEmilyDiehlStar.gif Emily Diehl (talk) 02:09, 13 December 2008 (UTC)
You are probably still working on the update (based on the current "speed"...), but I already noticed some weird problems: First it seems as if the image redirects don't work any longer. The setting was removed in MediaWiki 1.13 and the feature enabled by default, but images don't seem to redirect any more automatically..
Also I'm experiencing some caching issues; I still get the "You have new messages" notice but already looked at my talk page and I already answered on it (and the last changes button shows the old message, not my already added) - that error is showing up randomly, as of now, it works again. poke | talk 15:10, 15 December 2008 (UTC)
And now it doesn't again ^^ (Also the entries are disappearing from RC). poke | talk 15:11, 15 December 2008 (UTC)
The last time we had an update also showed the redirect problem, didn't it? I remember it has already happened after a downtime. Erasculio 15:40, 15 December 2008 (UTC)
Now that was because of the update; MediaWiki 1.12 introduced a setting to enable or disable image redirects - it was disabled by default. That was why we had to enable it first; now in MediaWiki 1.13 that setting was removed again and image redirects are enabled by default, but they don't work. poke | talk 16:16, 15 December 2008 (UTC)
Btw. why wasn't GW2W updated? (Also caching issues seem resolved) poke | talk 17:40, 15 December 2008 (UTC)
Hiya poke! I just read all of these messages, and I think that a majority of them have been resolved. According to IT, the upgrade is complete on both this wiki and the GW2W. They even managed to sneak in the 1.13.3 patch, which came out early this morning. I was told that a few of your setting change requests weren't implemented because they had to change over 2 million lines in the db and didn't want to change anything extra without testing first. We'll be going back through and making additional changes on staging, and then pushing them live when they're confirmed. Anyways, if there is anything specific that pops up as an issue, please let me know right away. Also, if there are any issues that you've mentioned earlier but are still noticing, let me know those too (I am not experiencing the ones you've already reported, so I think they are resolved...then again, I just got here, so I'm not 100% sure :)). Thanks a ton! --UserEmilyDiehlStar.gif Emily Diehl (talk) 18:43, 15 December 2008 (UTC)
Huh, ok - GW2W seems updated now o.O Weird.. For still existing bugs, I think the only one left is the missing image redirect. See for example this image. As for the settings I requested, I fail to see where there are that many lines to be changed in the db. The only file that needs to be changed is the LocalSettings.php, in this case adding one line and changing 4 or 5 rights listed in the same file. Or is that because of your special backup server system? poke | talk 18:56, 15 December 2008 (UTC)

(Reset indent) Heya poke! I talked to my wiki guy, and he's making the requested writeapi changes to LocalSettings and checking it out on staging now. The 2 million line reference was for the total upgrade...not for your changes. In general, IT isn't keen on throwing additional variables of change into upgrades that imposing because if something goes wrong, they want to know for sure that it was something that stemmed from the version upgrade itself and nothing in any other settings. That's why he wanted to hold off until he was sure everything was solid. I've also mentioned the image redirect issue, so we'll fix that too when we deploy these other changes. Thanks for the heads up! --UserEmilyDiehlStar.gif Emily Diehl (talk) 19:01, 15 December 2008 (UTC)

Ah, ok - thanks Emily :) poke | talk 19:05, 15 December 2008 (UTC)
Also, since I know it's been awhile, don't forget there's still some GWW:TECH#Community requests that have been waiting around for the big 1.13 upgrade. - Tanetris 19:21, 15 December 2008 (UTC)
Ooh, good catch. We're on these requests now...I'll let you know what get finalized :) Thanks for the pointer, Tanetris. I missed this new batch. --UserEmilyDiehlStar.gif Emily Diehl (talk) 20:35, 15 December 2008 (UTC)

Image redirect fun

Hi guys! I'm working with our IT wiki guy to get the last round of configuration changes made to the site after the upgrade, but we're running into a bit of a conundrum with image redirects. Here's why:

Image redirects first broke in the last big MediaWiki upgrade. Initially, we used a fix that Rezyk suggested, since setting $wgFileRedirects to true didn't really seem to do much.

We're running into the same issues now, but we're worried about using this same fix because of the new version upgrade. I haven't had a chance to check the code myself, but IT is concerned, and would rather have us figure out a more kosher fix than going in and basically adding one-off snippets of code to the source.

We checked out MediaWiki and Wikipedia, and both seem to be using the Imagemap extension to handle image redirects. Here's the code they use for a piece of their main page:

Error: Image is invalid or non-existent.

As you can see, they use the imagemap tag to wrap around images that they'd like to function as redirects.

I can see the value in having an extension control this functionality, as they are easier to upgrade and prevent us from breaking stuff when we forget to re-hack up the source after an upgrade, but I'm also concerned that switching to this system right now would create a lot of extra work for you guys, especially with things like skill image redirects and signature image redirects. From first glance, I think that we'd have to go in and edit every image that requires a redirect, and I'm not even sure how that would affect signatures.

I am not 100% positive, but I think that they may be adding native support for image redirects to the 1.14 snapshot ("Images can link to an arbitrary title or URL"). I don't know if I'm reading this wrong, though. If this is the case, I'd be hesitant to ask for us to flip to the imagemap system, because it would be a ton of work for nothing. In this situation, it may be better for us to just make this one-off change one more time, especially if it's fixed in the next version.

A lot of you guys are very knowledgeable about wikis, so I just wanted to loop you into our current discussion. Obviously, image redirects are extremely important, so we're working to figure out a solution for them. I think my contact stepped out for lunch (since he's been in since 3 am), but when he gets back, I'll pick up this up again. If anyone has any thoughts in the meantime or if anyone knows anything we haven't heard about this topic, fire them at me and I'll pass them along. Thanks again all :) --UserEmilyDiehlStar.gif Emily Diehl (talk) 20:34, 15 December 2008 (UTC)

I looked at the MW 1.13 code and I'm quite confused that they still have that hardcoded check against images in there.. The setting to enable file redirects was removed in 1.13 again and that page states that this feature (that "MediaWiki checks redirects in Image: namespace") is "[e]nabled unconditionally in 1.13".
The imagemap extension, Wikipedia uses is to make it possible to click on images and link to a different page than the image description page; while that might be a possible solution it is not really a nice one as we would have to change nearly all pages on GWW to reflect that change, as the imagemap extension doesn't enables redirects from the image namespace, either.
I think the only solution, until someone actually notices that they really don't work and that their setting they removed was never interpreted at all, I think we don't have another choice than changing the code ourself.. I looked at the specific section and it would be easy again to fix that, but I saw something different from last time - maybe there actually is some control for redirects in it, so I'll check that first before posting code ;) poke | talk 21:25, 15 December 2008 (UTC)
Yep, this is exactly what we're wrestling with right now. We've also come to the conclusion that the best option does seem to be to apply a one-off fix for the issue and hope that it gets resolved in 1.14. If you run into anything that may be a better fix than Rezyk's initial snippet, let us know. Thanks for the help (as always)! --UserEmilyDiehlStar.gif Emily Diehl (talk) 21:33, 15 December 2008 (UTC)
Ok, so far what I found out is, that the setting in 1.12 and the enabled by default behaviour for image redirects means that redirects to - only to - the image namespace is possible. Redirects outgoing from the image namespace are not possible. See for example this test page.
The new feature that will be introduced in MediaWiki 1.14 is a "light version" of the imagemap extension. While it doesn't allow real html-maps (with multiple links depending on where your mouse clicks on the image), it simply adds a link parameter to the image inclusion code, so you can link to any page with a image without using redirects. However this is still not a behaviour we would like (maybe when MW 1.14 is on GWW, we can think about converting slowly).
For redirects from the Image namespace, it seems as if we don't have a choice than removing the check within the code. The code in question is the following from includes/Wiki.php (lines 282ff.)
if( ( $action == 'view' || $action == 'render' ) 	// ... for actions that show content
      && !$request->getVal( 'oldid' ) &&    // ... and are not old revisions
      $request->getVal( 'redirect' ) != 'no' &&	// ... unless explicitly told not to
      // ... and the article is not a non-redirect image page with associated file
      !( is_object( $file ) && $file->exists() && !$file->getRedirected() ) ) {
The last line checks if the image is neither an (image) object, nor an existing file (which actually means that image pages without an uploaded image or with a broken image actually do a redirect, as you can see here for example), nor the page was already a target of a redirect (although redirect loops are eliminated already before this). So to make image redirects possible it would be enough to just remove the complete image test. However, now that I think about it, it might be useful to disable redirects for broken images, so that users will see when there is a problem with an image and have the chance to fix it (actually this makes more sense to me than redirecting only broken or non-existant files by default). So we could change the test to redirect always, except if there is an image and that image is broken. A possible way to do that would be this:
if( ( $action == 'view' || $action == 'render' ) 	// ... for actions that show content
      && !$request->getVal( 'oldid' ) &&    // ... and are not old revisions
      $request->getVal( 'redirect' ) != 'no' &&	// ... unless explicitly told not to
      // ... and the article is not a non-redirect image page with associated file
      !( is_object( $file ) && !$file->exists() ) ) {
What would you think about that? poke | talk 21:57, 15 December 2008 (UTC)
Hiya Poke! Thanks for checking into this for us. I see what you're saying, and I think that your proposed solution makes sense. I'm going to pass this along to IT and make sure they don't have any caveats.
As a sidenote, I'm a bit concerned about your clarification on 1.14 not actually fully fixing the issue in the way we'd hoped. Do you think that if we may need to eventually flip over to a system that uses imagemap anyway, it may be a good idea to actually start taking those steps now? Would there be any disadvantage to getting that extension installed here and having people gradually switch over redirected image code to the new system?
If the two changes (modifying the source directly + adding the image extension) play nice together, if we got started now we'd have double coverage for redirected images (so none should actually break, even if they are not using imagemap code). That would prevent us from having to rush to fix a ton of images when 1.14 comes along and would get folks used to using the new format. I'm sure there are concerns I'm not familiar with, and it also may be tough to track what images are being redirected in what fashion (since they should all work about the same), but it may be something to consider for the long-term since the way we're doing things now isn't the most kosher. --UserEmilyDiehlStar.gif Emily Diehl (talk) 00:51, 16 December 2008 (UTC)
No, actually I don't think the imagemap extension is something we really need. It makes it possible to use <map>-tags for images to make them clickable; but in 99% of our images, a simple link is enough. I think it will be great when we can link to pages with images in 1.14, but I don't think it is that urgent, that we have to install an extension that allows us that. Also the image clicking/imagemap has no relation to the redirect problem. poke | talk 08:06, 16 December 2008 (UTC)
(Hey, Emily - has anyone tried signing poke up to ArenaNet? He's wasted being a freelancer here!) --snogratUser Snograt signature.png 11:47, 16 December 2008 (UTC)
They would, but I think Wikimedia's after him! --User Brains12 Spiral.png Brains12 \ talk 13:51, 16 December 2008 (UTC)
He makes my head hurt... but I <3 him anyway :D --Wyn's Talk page Wyn 13:55, 16 December 2008 (UTC)
lol <3 poke | talk 16:32, 16 December 2008 (UTC)

Wiki Outage?

Am I the only one who lost connection to the wiki for 10+ minutes there? — Jon 01:58, 19 December 2008 (UTC)

You're not the only one (and I think it was a bit longer than that; an hour or so). --User Brains12 Spiral.png Brains12 \ talk 02:03, 19 December 2008 (UTC)
Thirded. GW2W was also inaccessible, apparently because they are on the same server/network (?) Vili User talk:Vili 02:28, 19 December 2008 (UTC)
Hi guys! We're aware that the site has been experiencing intermittent issues. I just received an email letting me know that the team has nailed down the cause for them, and is addressing them as we speak. I apologize for the ups and downs, and I'll give you more details about the problems when I get them. We'll be back to 100% shortly, though :) --UserEmilyDiehlStar.gif Emily Diehl (talk) 17:35, 19 December 2008 (UTC)

(Reset indent) Heya all! I just wanted to let you know that I've received final word about the cause of our recent instability. Apparently, this was caused by issues with the recent changes RSS feed. Some of you may remember that we had to make changes after the 1.12 update to limit the amount of data passed by the feeds. After this update, similar issues popped up and managed to bring the site to a crawl. Since then, we've made some changes that should not only fix the performance issues but also bring the feeds back for those of you subscribing to them. Again, we apologize for the problems. Let me know if you run into any more issues :) --UserEmilyDiehlStar.gif Emily Diehl (talk) 19:18, 19 December 2008 (UTC)

While you're at it

... at editing the source files... :P We have some issue with the new look of Special:RecentChanges.. The MediaWiki fieldset displayed there with the namespace filter is.. very disturbing and we would like to change it, so we can get the old and more clean look back. As MediaWiki was so nice to split this away from any template, we again have to edit the source files for that. The following is what I would like to change in the file includes/specials/SpecialRecentchanges.php (lines 415-426):

/** currently this is the code used there: **/

		$out = Xml::openElement( 'table' );
		foreach ( $extraOpts as $optionRow ) {
			$out .= Xml::openElement( 'tr' );
			if ( is_array($optionRow) ) {
				$out .= Xml::tags( 'td', null, $optionRow[0] );
				$out .= Xml::tags( 'td', null, $optionRow[1] );
			} else {
				$out .= Xml::tags( 'td', array( 'colspan' => 2 ), $optionRow );
			}
			$out .= Xml::closeElement( 'tr' );
		}
		$out .= Xml::closeElement( 'table' );


/** please change that section to this: **/

		$out = Xml::openElement( 'div', { 'id', 'nsoptions' } );
		foreach ( $extraOpts as $optionRow ) {
			if ( is_array($optionRow) ) {
				$out .= Xml::tags( 'div', null, Xml::tags( 'span', null, $optionRow[0] ) + optionRow[1] );
			} else {
				$out .= $optionRow;
			}
		}
		$out .= Xml::closeElement( 'div' );

This replaces the code that is used to generate that selection box and makes it a lot easier to make changes to it using css. Thank you very much. poke | talk 18:21, 17 December 2008 (UTC)

As you seemed to be around but didn't leave a message here yet, I thought I poke you, so you'll see this subsection :) poke | talk 19:34, 19 December 2008 (UTC)
Oh sorry about that, poke! I've already passed along this change and the one above it (along with all of the RFTAs) in an email, so IT is looking into the changes. I'll let you know what I hear about it. --UserEmilyDiehlStar.gif Emily Diehl (talk) 19:37, 19 December 2008 (UTC)
Ah, great! Thanks :) poke | talk 19:46, 19 December 2008 (UTC)

(Reset indent) Heya Poke! I got an email back about this today, and it seems that the fix you proposed is breaking on our staging servers. Here's are the relevant errors and code that was relayed to me: PHP Parse error: syntax error, unexpected '{' in /home/httpd/wiki/guildwars/en/includes/specials/SpecialRecentchanges.php on line 431

Here is what is in the SpecialRecentchanges.php file.

                /* Removed per Community request to give the ability to change the look of the recentchanges page with a template.
                $out = Xml::openElement( 'table' );
                foreach ( $extraOpts as $optionRow ) {
                        $out .= Xml::openElement( 'tr' );
                        if ( is_array($optionRow) ) {
                                $out .= Xml::tags( 'td', null, $optionRow[0] );
                                $out .= Xml::tags( 'td', null, $optionRow[1] );
                        } else {
                                $out .= Xml::tags( 'td', array( 'colspan' => 2 ), $optionRow );
                        }
                        $out .= Xml::closeElement( 'tr' );
                }
                $out .= Xml::closeElement( 'table' );
                */End of original code


                // Added to meet the above remarks possible
                $out = Xml::openElement( 'div', { 'id', 'nsoptions' } );
                foreach ( $extraOpts as $optionRow ) {
                        if ( is_array($optionRow) ) {
                                $out .= Xml::tags( 'div', null, Xml::tags( 'span', null, $optionRow[0] ) + optionRow[1] );
                        } else {
                                $out .= $optionRow;
                        }
                }
                $out .= Xml::closeElement( 'div' );
                // End of custom modification

Any thoughts? --UserEmilyDiehlStar.gif Emily Diehl (talk) 19:57, 6 January 2009 (UTC)

Oh, did I mistake there, the correct line is:
$out = Xml::openElement( 'div', { 'id' => 'nsoptions' } );
( => instead of , ) - Hope that works then :) poke | talk 20:14, 6 January 2009 (UTC)
Thanks Poke! I'll pass that along. --UserEmilyDiehlStar.gif Emily Diehl (talk) 20:21, 6 January 2009 (UTC)
He's making my head hurt again.....--Wyn's Talk page Wyn/talk 20:26, 6 January 2009 (UTC)
Sorry Wyn :) poke | talk 20:34, 6 January 2009 (UTC)

(Reset indent) Heya Poke! We're still getting the same errors for this:

Parse error:  syntax error, unexpected '{' in /home/httpd/wiki/guildwars/en/includes/specials/SpecialRecentchanges.php on line 432

Here's the relevant block of code again.

                $out = Xml::openElement( 'div', { 'id' => 'nsoptions' } );
                foreach ( $extraOpts as $optionRow ) {
                        if ( is_array($optionRow) ) {
                                $out .= Xml::tags( 'div', null, Xml::tags( 'span', null, $optionRow[0] ) + optionRow[1] );
                        } else {
                                $out .= $optionRow;
                        }
                }
                $out .= Xml::closeElement( 'div' );

Thoughts? :) --UserEmilyDiehlStar.gif Emily Diehl (talk) 17:27, 7 January 2009 (UTC)

Already got that from Russ but I'll try to get it running on my server - I just can't do this without trying it myself :) I'll let you know when I have some fix. (btw. sorry for stealing your job on GWW:TECH, didn't know you were already around :D) poke | talk 17:46, 7 January 2009 (UTC)
Awww, after testing the code myself on a test wiki (that I had to set up, but try to find out my database password first - that's why it took so long <_<), I feel really really stupid.. :/
So, here is the correct and working code of that block:
		$out = Xml::openElement( 'div', array( 'id' => 'nsoptions' ) );
		foreach ( $extraOpts as $optionRow ) {
			if ( is_array($optionRow) ) {
				$out .= Xml::tags( 'div', null, Xml::tags( 'span', null, $optionRow[0] ) . $optionRow[1] );
			} else {
				$out .= $optionRow;
			}
		}
		$out .= Xml::closeElement( 'div' );
That should work then finally... poke | talk 20:24, 7 January 2009 (UTC)
And before I forget, could you have this line added to LocalSettings.php? It actually allows users to use the image moving :)
$wgGroupPermissions['autoconfirmed']['movefile'] = true;
Thank you :) poke | talk 20:31, 7 January 2009 (UTC)
my head just exploded....... anyone else?75.165.125.117 12:16, 21 January 2009 (UTC)

(Reset indent) Heya Poke! This topic is huge, so I want to archive it. Can you confirm if I got everything in here taken care of? If I missed anything, let me know. Thanks :) --UserEmilyDiehlStar.gif Emily Diehl (talk) 03:08, 22 January 2009 (UTC)

Ah yes, everything in here was done and worked fine, thanks :) poke | talk 16:26, 22 January 2009 (UTC)
Rad! Just what I like to hear ;) --UserEmilyDiehlStar.gif Emily Diehl (talk) 19:55, 22 January 2009 (UTC)