User talk:Echelon

Some Nice Extensions
I've browsed through mediawiki.org's extension matrix the other day and I've found a few extensions that would be nice to have (not all of them now, but in the future perhaps). I've arranged it in a sortable table format with rationales and links to make it easier for you to make a decision on them :)

Also, I've bolded the name on those that I feel would help right now, the rest can be installed whenever (if ever). If a release status is italicized it means that it may not work correctly on our current version of MediaWiki. An underlined release status means that it has dependencies which we may or may not have installed as of yet. An italicized name means that we already have it, it just needs to be updated. These are also marked with "(update)" in the release status.

I'll be giving you messages like this periodically, but I'd appreciate it if you looked over these extensions. -- 16:57, 29 August 2007 (CDT)
 * I would say yes to the bolded ones (Parser is already installed, probably just needs an update) and no to the non bolded (beta, spammable, editcountitis). -- Prod (Talk) 21:28, 29 August 2007 (CDT)
 * Hence the "(update)" part. ;) Anyway, of the non-bolded ones, the only one I feel that we might need in the future is the RandomSelection one, mainly for rotating the featured guides once we get a few. I don't know what kind of caching issues the extension causes however, so I'll need to do a bit more research on that (which is actually why it isn't bolded). As for MultiUpload, I can see what Prod means by 'spammable' (I'm assuming that it was the one he was referring to). You can prevent either some or all of the spam by restricting what rights groups can use it (namely either autoconfirmed or sysop), but I have no idea how to do that, either. :( Oh, and we seem to be missing the description image for imagemap. A quick fix would be copying Wikipedia's and just putting it in the appropriate path (which can be found on InvisiClues). -- 09:41, 30 August 2007 (CDT)
 * Oh, nice job! I really like some of these. As soon as I get back from robotics lab tomorrow I'll be on it. I'll give MediaWiki an upgrade while I'm at it. echelontalk 02:21, 31 August 2007 (CDT)
 * You'll be making a backup to update MediaWiki anyway, so could you look into making it available (except for the user table), or at least supply it to the sysops/bureaucrats? StrategyWiki has boatloads of content now, and having a few backups held by the regulars can't be a bad thing. GarrettTalk 04:20, 31 August 2007 (CDT)
 * Is it worth upgrading MediaWiki at the moment? The next major version will be out soon, so it might be an idea to wait until then. -- 05:29, 31 August 2007 (CDT)
 * Personally, I'm more comfortable with bugfix versions of the branches since they tend to have fewer bugs in the new features. -- Prod (Talk) 19:36, 31 August 2007 (CDT)
 * Let me talk with you guys in IRC tomorrow (today - Saturday afternoon EST) about getting fresh backups distributed this weekend. If you think it's best to wait on the new MediaWiki branch, I trust that assessment as well. I think it should be okay to work with the extensions, though. echelontalk 01:47, 1 September 2007 (CDT)
 * I updated ParserFunctions, added DeletedContributions, MultiUpload, Newuserlog, and UsernameBlacklist. While I liked some of the other extensions, I do not feel comfortable that they are not built by the MediaWiki team. I would like to continue discussion of those extensions before we reach a consensus on whether or not to add them. If you can, test the heck out of the extensions that were added to make sure nothing went awry. echelontalk 02:19, 1 September 2007 (CDT)
 * I'd be wary of the username blacklist, one wrong edit can block all user creation so I think we should update the mediawiki text here Maybe with an email address or something in case that happens .--Rocky http://media.strategywiki.org/images/thumb/7/78/Rally-X_Rock.png/25px-Rally-X_Rock.png (Talk - Contributions) 02:55, 1 September 2007 (CDT)
 * Special:MultipleUpload is a bit messed up atm.--Rocky http://media.strategywiki.org/images/thumb/7/78/Rally-X_Rock.png/25px-Rally-X_Rock.png (Talk - Contributions) 02:57, 1 September 2007 (CDT)

I tried fixing Special:MultipleUpload, but even CSS didn't hide the edittools at the bottom for me, so I just reverted my changes to let you (or someone else) have a go at another method. As for the blacklist, you may want to set a few people with the "uboverride" right so they can create blacklisted accounts upon request if there is a good reason for it. As for blocking everybody... yeah, that might be a problem. You could put in a comment (a line starting with #) of regexs NOT to use. -- 11:04, 1 September 2007 (CDT)
 * Oh, and Special:DeletedContributions is broken (not just the interface showing up correctly, but it gives db errors when you actually try to look them up). -- 11:16, 1 September 2007 (CDT)
 * We need an new welcome message now, and new user log only works for a day.--Rocky http://media.strategywiki.org/images/thumb/7/78/Rally-X_Rock.png/25px-Rally-X_Rock.png (Talk - Contributions) 11:54, 1 September 2007 (CDT)
 * For the moment, you can subst User:Rocky/Welcome.--Rocky http://media.strategywiki.org/images/thumb/7/78/Rally-X_Rock.png/25px-Rally-X_Rock.png (Talk - Contributions) 11:59, 1 September 2007 (CDT)

New User Log
While the new user log is kinda neat, it doesn't seem to be of much use to us. Because we aren't welcoming new users until they've actually made a contribution, the log doesn't serve much purpose that I can see. It just clutters up the recent changes list. Is there a setting where I can turn that off?-- Duke Ruckley  21:43, 2 September 2007 (CDT)
 * For the moment, enhanced recent changes hides the logs, but I really would like another way.--Rocky http://media.strategywiki.org/images/thumb/7/78/Rally-X_Rock.png/25px-Rally-X_Rock.png (Talk - Contributions) 02:54, 3 September 2007 (CDT)
 * It does get a bit messy, doesn't it? I wonder if there's a way around showing it all in Recent Changes... echelontalk 15:41, 3 September 2007 (CDT)
 * I do like to see all these strange, unused accounts and the socks that get created by some of them. Only thing better would be IP's. -- 16:26, 3 September 2007 (CDT)

Donation
No, it's ok. Just the name is fine. -- 08:58, 4 September 2007 (CDT)


 * Same here Ech. BTW, we tried to replace the "Donate" text with the Paypal icon that Skizzerz put on the Donation page, but it didn't work.  That nav bar obviously needs some tweaking to allow images to appear in there, but I think it would be worthwhile if it's possible.  If it can be done, it should be positioned below "Help".  As for attracting new traffic, Duke and I came up with a funny campaign slogan: "What the FAQ? www.strategywiki.org" :) Procyon (Talk) 09:19, 4 September 2007 (CDT)
 * I had a go on my user page, is this what you want?--Rocky http://media.strategywiki.org/images/thumb/7/78/Rally-X_Rock.png/25px-Rally-X_Rock.png (Talk - Contributions) 09:54, 4 September 2007 (CDT)
 * Err... kind of. I assume you got it as close to what I meant as you could, but yeah, the image would literally replace the text, not live along side of it.  Procyon (Talk) 13:27, 4 September 2007 (CDT)
 * It's an issue with different screen sizes and browsers I think, on mine it replaces the donation text. Anyways, could you externally link to the image in the mediawiki sidebar?--Rocky http://media.strategywiki.org/images/thumb/7/78/Rally-X_Rock.png/25px-Rally-X_Rock.png (Talk - Contributions) 14:39, 4 September 2007 (CDT)
 * That was a no-go. I tried it out, didn't work.  Someone needs to fiddle with the MediaWiki:Sidebar settings to allow it.  Procyon (Talk) 16:30, 4 September 2007 (CDT)

Yo Ech, keep my (real) name private aight? =) You can list me as my username.  -- 21:00, 4 September 2007 (CDT)
 * Sure thing. I promise not to tell anyone your real name is Georg Fredrick Claget von Dusseldorf. I totally promise. :P echelontalk 22:21, 4 September 2007 (CDT)
 * If I donate $1 100 times, do I get my name on the list 100 times? -- 02:18, 5 September 2007 (CDT)
 * If you donate it all in the same month, no. You can, I suggest, donate $1 every month for 100 months and get your name on the list 100 times. :P

Goals
One of the things that has come up in discussions is the question of where money gets put to use, so I think a productive thing to do would be to come up with some sort of list of goals or places where money would be applied to. Donators would be more inclined to donate knowing specifically where it would be applied to and feel reassured it was being put to good use. Charitwo and I discussed fundraising (see my talk page for a little bar) and that if we were to say it was a fundraiser then it would be easier to work towards any goals we made. Hm, maybe that's it (I can't check my IRC logs for a few days)! Fundraiser + Goals = Win! -- 18:54, 14 September 2007 (CDT)
 * For now, I'd be happy with budgets/balance sheets for the past few months (since we got google ads). -- Prod (Talk) 19:42, 14 September 2007 (CDT)

Zelda Wiki Interconnectivity
Hey - this is Jason. I'm not entirely sure if it was you who I spoke to earlier in the summer, as I've misplaced your AIM s/n, but I'm assuming it was. Remember how we spoke about "integrating" StrategyWiki and ZeldaWiki.org? Curiously enough, although I put links to SW on ZW.org, I never saw this fabulous integration happen on your end. I was very excited about it, saw that it didn't happen, and then just ignored it for a while. But now I want to see it. Are you still up for it? --GoldenChaos 11:19, 13 September 2007 (CDT)
 * Ah, yes! I really apologize for the delay. At the time I was waiting for the final version of Procyon's LttP guide, and I got completely sidetracked. I'm going to talk with Procyon and others about how best to implement this--details such as whether we should use templates or interwiki, etc. I should have this resolved for you guys by this weekend. echelontalk 02:11, 14 September 2007 (CDT)
 * There are two levels on which this can be accomplished. One would be the obvious guide front page link like we have for a lot of Wikipedia articles.  So LttP could easily have a "for more information, see..." link on it to ZW.org once DrBob and the others decide upon a template format.  The other level is a level that has already been implemented to a very small extent.  The name Sahasrahla has been linked to ZW.org throughout LttP for some time now.  It was an easy and obvious choice, and few other terms are linked as well.  Since I'm not entirely familiar with the content of ZW.org, and don't know what terms are available for linking, it might be more advisable to suggest that GoldenChaos search through the guide and find some terms that he feels is appropriate to link up.  He can then either proceed to link them on his own by editing the guides, or submit a list of terms that he would like to see linked, and we can proceed with the edits.  I think the only problem on our side is not a lack of willingness, but an unfamiliarity with the content of his site.
 * P.S. I left a response for you about DoubleJump when you get a chance. Procyon (Talk) 06:49, 14 September 2007 (CDT)
 * I brought up a more "visible" thread in Community Issues sometime yesterday (here), so perhaps we should discuss this there? Also, I've tried contacting Jason on his ZW talk page, but they're currently having some sort of server problem that isn't allowing some pages to be displayed (including his talk page). -- 08:31, 14 September 2007 (CDT)
 * Yeah, I'm working to resolve that problem. Should just be a PHP memory issue, I think... I'm just being lazy. Shame on me. But it'll be easier to let the server guys fix it; I also need them to fix ImageMagick anyway, so I'll give them a call in fifteen minutes or so. As per the content of Zelda Wiki.org, it really applies to characters, items, places etc. from the Zelda series. That's a broad description. So, I would link items, characters, and places within the walkthroughs to go to ZW.org, or something along those lines. --GoldenChaos 09:30, 15 September 2007 (CDT)

DynamicPageList update(s)
Just dropping by to let you know that our current version of the DynamicPageList extension is a bit out of date (1.3.1 versus the current 1.4.8). Therefore, I wish to request that it be updated. See: version history download. Thanks! -- 19:36, 15 October 2007 (CDT)

Skins
Hey Ech, I was trying to update my reskin of bluecloud but I ran into a little problem. I'm attempting to alter the background of the gallery that appears in image categories (I assume this is the same as using ) to black, but to no avail. I've changed all the references I believe that would be handling that attribute, but still nothing. Using WebDeveloper I've looked into what inherited values could be causing the problem, and all I can pinpoint are from http://media.strategywiki.org/w/skins/common/commonPrint.css (what is that anyways? could it be globally dominating all the skins?). I dunno, maybe I'll go back and keep looking for substitutes, however, I had the idea that maybe we could create an actual entry for the skin so that it wouldn't have the inherited bluecloud css possibly messing it up. Could we do that? -- 02:46, 5 November 2007 (CST)
 * Additionally, we need to set up a policy (this is more like something we'll put up in community issues) about keeping templates, tables, etc. skin neutral. For instance, we need to define properties within specialized classes, otherwise skins like mine end up with a lot of contrasting colors of both extremes (dark blue on black, white on white, etc.).  Although this increases the amount of data stored in each skin, it does have some reduction in data otherwise (substing a template with skin neutral properties will result in less characters being saved).  I don't see it as a problem, but I'm not running the server nor do I have experience with MediaWiki.  What do you think?  -- 06:33, 12 November 2007 (CST)
 * We already have a semi-official policy on this, and I've been moving the CSS out of templates wherever I see it in the wrong place. What you've done with the thankyou template isn't right though. You should add the class, and then move the CSS to MediaWiki:Common.css, or better yet, notify me and I'll do it. --DrBob (talk) 10:55, 12 November 2007 (CST)
 * Yeah I know where the css is supposed to go, just I didn't know if I was allowed to edit it or whatever. Additionally, if it's redefines in the skin, will it override common.css?  'Cuz if it doesn't, that's part of the problem.  -- 15:11, 12 November 2007 (CST)
 * The skin's CSS is imported after common.css, so as long as each CSS rule's selector has the right level of specificity, things should work smoothly. --DrBob (talk) 15:25, 12 November 2007 (CST)

Upgrading MediaWiki
Just a friendly reminder to update our MediaWiki version. And if at all possible, can you look into the 1.12a trunk (SVN) instead of 1.11? It has a lot of cool options that, when enabled, will make life a lot easier. For example, we'll have:
 * Special:MergeHistory if you set the 'mergehistory' right. It does as the name implies, letting you merge the histories of two articles without having to do all that deletion/undeletion crap (to set the right, add $wgGroupPermissions['sysop']['mergehistory'] = true; in LocalSettings.php).
 * Email bans when blocking
 * Revision deletion if the rights are set (in LocalSettings.php, add in $wgGroupPermissions['sysop']['deleterevision'] = true; and $wgGroupPermissions['bureaucrat']['hiderevision'] = true;).
 * You can now move a page without creating a redirect (not sure what happens to the moved page as of yet though)
 * $wgAddGroups and $wgRemoveGroups allow giving other usergroups partial access to Special:Userrights (without having to assign them the 'userrights' permission)
 * parser function for getting the real URL of files
 * All pages have feed links
 * Allows retrieving raw content via action=raw
 * Allows you to protect uncreated pages via a protect tab (no transcluding/cascading crap)
 * Deleted revisions can be viewed as diffs versus any other revision of that article, deleted or live
 * Added $wgUseNPPatrol option for ability to patrol Special:Newpages, as well as adding filters for that page
 * Parsing order has changed
 * API has been vastly expanded

For a full list of everything added in 1.10, 1.11, and 1.12, check this for 1.12 and this for the others. Also, if you decide to set $wgBlockAllowsUTEdit to true (which allows blocked users to edit their user talk page), you can use the patch from this bug (don't forget to run the SQL query as well, outlined in comment #12). If not... don't bother :)

Also, when you update, MultipleUpload is incompatible with 1.11+, so you'll have to remove that extension from LocalSettings.php. On the other hand, CheckUser should work perfectly with 1.12, so definately try that :) -- 20:13, 21 December 2007 (CST)