UESPWiki:Administrator Noticeboard/Archive 13

The UESPWiki – Your source for The Elder Scrolls since 1995

This is an archive of past UESPWiki:Administrator Noticeboard discussions. Do not edit the contents of this page, except for maintenance such as updating links.

Contents 1 More Site Suggestions 2 DNS Issues 3 Dapel Namespace 4 Site Traffic 5 An Affiliate Deal Between the UESP and The Elder Stats? 6 Blocked Roleplayer4life 7 Updating ProtectSection 8 I volunteer 9 Image Layout 10 TemplateSandbox 11 Morrowind vs Oblivion Parallelism (MOPP) 12 Server-level Blocks 13 Possible Image Fixes 14 Missing Oblivion Easter Egg 15 Cookie Problem? 16 Mods Map request 17 External Editor 18 Rename Request 19 Request for Adminship 20 Registered Spammers? 21 Patroller Policy Change 22 Request Block for 90.220.242.186 23 Deleting to Restore 24 Namespace Links 25 New Servers 26 Patrolling Style - Elliot 26.1 Several days later 27 UESP E-Mail Server 28 Template Protection 29 Edit Notices 30 Image prods 31 Suggestion 32 Deleted Logs 33 Vandal notice 34 Complaint about a personal attack

[edit] More Site Suggestions

Sorry for the number of these "big idea" posts recently -- I think this should be the last set of new ideas (at least for a few months). However, during my immersion in the site's PHP code over the last couple of weeks, I've discovered a couple of other configuration changes that could be useful for the site:

• Better default category sorting
  • In a nutshell, it should be possible to remove the DEFAULTSORT tags from all of our trail templates.
  • To do this, I'd tweak the php code so that the default (used if no other category sort tag is provided) is no longer {{FULLPAGENAME}} (e.g., "Oblivion:Anga") but is something more appropriate for the majority of our pages, such as {{CORENAME}} {{SORTABLECORENAME}} (introduced above, e.g., "Anga").
  • The immediate effect on the site would be negligible, since we never use the default sort tag right now. However, we should be able to simplify our templates, fix problems with templates providing conflicting sort categories, and we should be able to use DEFAULTSORT tags the way that was intended: only use them on those articles that need special treatment.
  • This was also discussed above, but since it was buried under a lot of technical details there, I figured I'd put it somewhere more visible
• "Fixing" the Tamriel namespace
  • In a nutshell, make it so that any external links/bookmarks to old Tamriel articles will permanently work -- without us having to keep around the actual old Tamriel articles.
  • Specifically, what can be done is specify in the site configuration files that "Tamriel" is a namespace alias for "Lore". It's the same way that on Wikipedia "WP" can be used universally as an alias for "Wikipedia"; the result is somewhat like a super-redirect that works for the entire namespace. (Also, "Tamriel_talk" would become an alias for "Lore_talk".) I've tested how this works, and it is completely transparent: whether you type in a URL for a page, type in a link to a page, or use the search function, you always end up at the corresponding Lore page. Furthermore, when you end up at the Lore page, it always calls itself a Lore page (even the URL is fixed, i.e., there's a HTML-level redirect that happens, too, if necessary). I tested this on my test wiki, using the exact same namespace configuration as UESP. However, any skeptics can easily experiment on Wikipedia and see how WP works there.
  • Simultaneously, I'd suggest that in our wiki settings, NS=100 is renamed to Tamold and NS=101 is renamed to Tamold_talk. In other words, that we instantaneously transform all of our existing "Tamriel" articles into "Tamold" articles (this is not a bot-type move, but rather a single universal change made to the wiki's lookup tables). I think this would make it much less confusing trying to clean up the old articles. In case anyone is curious, without this renaming, the old Tamriel articles would still be accessible -- "real" Tamriel articles apparently take priority over the Tamriel->Lore alias. But I would be very very uncomfortable trying to delete all of those old Tamriel redirects if there's any chance that a Tamriel link is actually leading to a real Lore article (for example, if you don't refresh the to-be-deleted category, then actual Lore pages would effectively be listed in the to-be-deleted category).
  • Unfortunately I didn't realize this option existed back before we did the Tamriel->Lore move ;) It probably would have made nearly all the bot work unnecessary. But hopefully better late than never!
  • I think we could safely do this change right now; we would still wait until August to actually delete the Tamold articles, just because that's what we said we'd do. The other option would be to wait until August to introduce the alias, i.e., not make any changes until the currently established date. However, I don't see how waiting helps any readers -- why spend a few months telling readers they have to update their bookmarks if in fact they won't really have to in the end?
  • This is also an option to keep in mind for the Review and General namespaces -- we don't actually have to physically keep the namespaces, even if we want existing external links to those articles to work forever.

If these suggestions are acceptable to everyone, I could add these changes into the code that Daveh is about to install. --Nephele^Talk 20:07, 25 March 2009 (EDT)

That all sounds good to me, although RoBoT is a bit miffed that the work he did wasn't necessary! The sort order fix is also good - although with {{SORTABLECORENAME}} rather than {{CORENAME}} - unless that's what you mean by exceptions. –Rpeh^{•T•C•E•} 04:13, 26 March 2009 (EDT)

Yes, I meant to say SORTABLECORENAME ;) --Nephele^Talk 10:05, 26 March 2009 (EDT)

Daveh just added these changes -- the Tamriel/Tamold change is sitewide; the defaultsort change is only on content1 so far. Another new only-on-content1 feature is that our large categories have been fixed! Compare how the Oblivion NPCs category works on content1 and content2 when you're not logged in -- in particular that the "next 200" and "prev 200" links work on content1 but are useless on content2. --Nephele^Talk 00:44, 7 April 2009 (EDT)

I just noticed one thing while playing with the NS* magic words in the sandbox on content1. On UESPWiki pages, those new words return "Project". I know why, but I imagine that should be expanded into "UESPWiki"? –Rpeh^{•T•C•E•} 04:33, 7 April 2009 (EDT)

...and the subspaces don't seem to be working either ([1]). Should I just stop messing around until this all goes out? –Rpeh^{•T•C•E•} 04:45, 7 April 2009 (EDT)

Ugh, I introduced a typo when getting the main and main talk namespaces working, which effectively disabled the mod subspaces. I've fixed that, and I changed the namespace names to be the UESP-specific names instead of the canonical names, so that takes care of UESPWiki/Project and any other cases, if they exist. I also decided to finally get smarter about my testing, by creating some lists of test pages to run through before finalizing a set of edits, which should hopefully minimize stupid mistakes from now on. I've passed the code on to Daveh.

Also, UespCustomCode should be in pretty good shape, so it should be ready for serious testing. Although I can imagine that hitting these problems is frustrating, on the other hand, identifying them early is better -- especially given that it takes a bit of extra time to get any fixes posted. So I'd say test away -- as long as it isn't driving you crazy. --Nephele^Talk 12:09, 7 April 2009 (EDT)

It's not frustrating so much as uncertain. I keep wondering whether I've hit a bug or made a mistake. Just to check - it's only UespCustomCode at the moment, right? Not MetaTemplate? Am I right in thinking that needs the MediaWiki upgrade? That's the one I really want to play with! Also, shall we take this whole discussion to the talk page of one of the new extensions? –Rpeh^{•T•C•E•} 12:35, 7 April 2009 (EDT)

Yes, it's only UespCustomCode so far. So that's the NS functions, the #label and LABELNAME functions, and the CORENAME and SORTABLECORENAME functions. I've passed the code for MetaTemplate to Daveh, but he has not yet installed it. See UESPWiki talk:MetaTemplate for details about MediaWiki versions -- the short version of which is that it does not need an upgrade and in fact will not work with an upgrade (yet).

The best way to keep track of what's available is the Special:Version page -- or rather the content1 version of the page. The version of UespCustomCode that Daveh installed yesterday (with category fixes and search fixes) is version 0.4; the latest version with the new NS fixes is version 0.5. Even more importantly, down at the bottom of the version page is a list of all the tags and function hooks added by extensions. The one set of features that does not show up in that list is the full list of new variables (e.g., CORENAME, SORTABLECORENAME, LABELNAME -- although you can semi-infer that they've been added given that the sortable and label functions are listed); the NS variables show up because they can be used as functions (e.g., {{NS_NAME:Shivering}}) as well as variables (e.g., {{NS_NAME}}). --Nephele^Talk 14:06, 7 April 2009 (EDT)

I just tested and confirmed that the new default sorting is working -- it's just hard to find examples of pages where it is even being used right now, since the majority of our pages have a DEFAULTSORT tag or a manually-set key. Furthermore, updating a page's sort option is not trivial -- simply purging doesn't appear to work. Nevertheless, the dozen-odd redirects that I edited this morning are all being sorted correctly in the Redirects from Alternate Names category. One notable example is Tamold:The Wolf Queen, Book I/Description: it's being sorted under "Wolf Queen, Book I, The", whereas all of the other Wolf Queen books and subpages are being sorted under "Wolf Queen, v? ..." So it's clear that the default algorithm is taking effect, but also provides an example of a case where a manual sort key (or DEFAULTSORT tag) is preferable -- automatic algorithms can't figure out everything ;)

We could perhaps start gradually removing the sort tags from trails. I'd suggest, however, just focusing on cases where the sort tags are currently causing problems (I recall a case a month back where there was a problem on a tamriel rebuilt page, perhaps the TR trail and the quest trail conflicting, but I can't remember where for sure). It's likely that a lot of our trail templates are going to be merged/made redundant/deleted when we start updating templates, so all of the template-based sort tags should automatically get cleaned up as part of the general revamping. --Nephele^Talk 12:33, 8 April 2009 (EDT)

I can't remember either, but I'm pretty sure you're right and it was the quest and TR trail. I've removed the DEFAULTSORT from the Tamriel Rebuilt trail, but I didn't want to touch the site-wide templates without further discussion. I'm going to suggest that we take all the DEFAULTSORT tags off templates, wait until the job queue settles down, and then check the results. Otherwise, I imagine we'll find several places where pages are being affected by multiple defaults, which will be confusing.

It looks like there are about 150 templates using DEFAULTSORT, so that's going to be quite a bit of work. –Rpeh^{•T•C•E•} 03:07, 10 April 2009 (EDT)

One side effect of the recent change to Template:Tamriel Rebuilt Trail is that old categories such as Category:Tes3Mod-Tamriel Rebuilt-Weapons are no longer used since now the relevant pages instead want Tes3Mod-Tamriel Rebuilt-Items-Weapons... --Gez 11:39, 10 April 2009 (EDT)

Hmm. That's how I think it should be done, but I've changed it back to the old way for now. –Rpeh^{•T•C•E•} 12:22, 10 April 2009 (EDT)

(outdent) You're going to hate me for this, but I have a new suggestion. Some kind of randomize function would be very useful for the "Did you Know?" section of the main page, and may be useful in one or two other places. At the moment, DYK items get added and removed at the whim of editors but they're still all true. If we had a "pick x items from this list" function, they could all be kept and re-used. Something like {{#pickfrom:2|Item 1|Item 2|Item 3|Item 4|Item 5|Item 6}}, which would pick two items from the parameter list.

On a usefulness scale, I know that's right down the bottom, but it has always annoyed me to see perfectly good "did you know"s disappearing without trace. –Rpeh^{•T•C•E•} 14:28, 12 April 2009 (EDT)

Done... at least in my version of MetaTemplate ;) I've added how it could possibly work at User:Nephele/Sandbox/2#Did You Know. The complicationsfeatures I added are:

• A seed parameter can be used to provide the random function seed. In my example, I'm setting the seed to the current week -- so Did You Know will look the same for everyone on the site, but will change once per week. Reducing the randomness means that if someone posts a comment like "I think that last Did You Know entry is wrong", we have some chance of knowing which entry is actually being discussed. It also means if a reader notices a couple of interesting entries in the DYK list, follows one of the links, then comes back to the main page, the other entries that caught his/her eye are still there.
• The 500 strangeness is so that if you view the Main Page/Did You Know page you are able to see all the DYK entries; the random 5 entries are only shown on the Main Page. Also, if the pickfrom number is larger than the number of entries in the list, the list is not randomized -- I felt it would make more sense when viewing the full list to have it always be in order.
• I kept the first four DYK entries out of the pickfrom, as an example of how we might want to treat any new additions to the list. I'd say if new DYKs are added, we want them to appear right away. Once they're "old news", then we can move them down into the pickfrom list. I considered whether to somehow work guaranteed entries into the pickfrom code, but it seemed like more trouble than it was worth.
• The separator text is inserted between each of the entries. Since wiki trims whitespace in parser functions, the line breaks all get stripped out. '\n' is the default value for separator, so that option doesn't really need to be specified in this case, but I made it possible to change the separator in case it's necessary for any other applications. Plus, the separator text recognizes C-style escape sequences.

Does it look like that would do the trick? --Nephele^Talk 02:56, 13 April 2009 (EDT)

Fantastic! That looks perfect. I wasn't expecting you to do it that fast... or even do it at all. My sink still needs unblocking, incidentally ;-) –Rpeh^{•T•C•E•} 03:28, 13 April 2009 (EDT)

[edit] DNS Issues

Just in case anyone noticed and was wondering, there have been a few issues with the DNS of the site (register.com) this week which may have resulted in site requests timing out. Nothing to do with the site, the load balancing, or the recent code changes by Nephele. Although I noticed it myself a few times the traffic logs show no noticable drop in traffic or bandwidth so it likely affected only a small number of users over a few short periods of time. -- Daveh 15:40, 3 April 2009 (EDT)

I've been noticing it and was wondering what was going on. At one point, the outage lasted for about an hour; other times, it seems to have been for just a few minutes. Thanks for the info. --Nephele^Talk 15:49, 3 April 2009 (EDT)

I'm glad it's not just me. I just had to put a hosts entry in to even reach the site. For windows users who need a workaround, add the line "72.55.137.132 www.uesp.net" to your hosts file, which will be located in your Windows\System32\drivers\etc directory. Remove it again once this is over in case the IP changes. –Rpeh^{•T•C•E•} 16:47, 3 April 2009 (EDT)

Nod...the problem is just the site name (www.uesp.net and all subdomains) don't resolve to their appropriate IPs. Reaching the site directly by IP works fine. At one point www.uesp.net was fine but all other subdomains weren't resolving. -- Daveh 17:22, 3 April 2009 (EDT)

[edit] Dapel Namespace

I've copied all the articles in the Dapel namespace to a separate Wiki (dave.uesp.net) so you may delete them as you see fit. There are a few pages with some Oblivion related content which might be useful in the Tes4mod namespace. . -- Daveh 23:17, 6 April 2009 (EDT)

[edit] Site Traffic

Just a quick note on recent site traffic. The last two weekends have seen the highest traffic the site has ever seen. Still trying to get stats working correctly on squid1 but Google shows over 596,000 ads shown last Sunday alone, the highest traffic day so far. Actual page views will be higher as that doesn't include any map views or people with ads disabled.

I'm trying to update the statistic tables and graphs with more recent versions if I can get the numbers wrangled up. -- Daveh 23:46, 6 April 2009 (EDT)

[edit] An Affiliate Deal Between the UESP and The Elder Stats?

Hello. My name is Tom, and I have a question to ask about an affiliate deal between the UESP and The Elder Stats (http://www.elderstats.com). I've talked to Daveh about this, and he told me to ask about it on the Administrator Noticeboard since he isn't as active on the site as most of the other administrators are. So, here is my proposition to get The Elder Stats out there so that Oblivion fans all over can have a nice place to share their characters with the world.

I have released a website called The Elder Stats. We have nearly 200 members now, and it's going well. The Elder Stats is a website that allows Oblivion players to post statistics and photos of their characters in Oblivion, and then organizes all of this information into a neat and organized profile for each character. Then, the characters' profiles can be shared easily with players' friends and such. We also have leaderboards, stat comparison pages, and much more. It's a really great website, and everyone who has tried it has told me that they think it's wonderful and well-put together.

Now, since the UESP and The Elder Stats are not in any sort of competition (because the UESP contains information about Oblivion, whereas The Elder Stats allows players to post their Oblivion characters), I was wondering if we could do some sort of affiliate link-back (or maybe "a short front page news item" as Daveh suggested to me)? I know that the UESP is a big website and you may think, "who is this guy to be an affiliate of mine," but I promise you that The Elder Stats is a growing website, and being less than 3 months old, it still has a lot of room to expand.

Since people who are on the UESP might be interested in a website such as The Elder Stats, I thought that it might be nice if we could do some sort of link-back, new post, or whatever you wish to do. I figured that since I worked so hard on The Elder Stats and so many people like it, that it would be a great resource for Oblivion fans to have to post their characters, get help with their characters, and compare their characters to others.

Thanks for reading this comment, and hopefully we can come to some sort of agreement or something of the sort. The Elder Stats is a great website, as is the UESP, and I think that placing a link to The Elder Stats on the UESP would be beneficial to the Oblivion fans who are looking for such a website. —The preceding unsigned comment was added by TomCat (talk • contribs) on 24 April 2009.

Feel free to add a link here. Beyond that, I don't see that there's any need for further integration. –Rpeh^{•T•C•E•} 15:41, 27 April 2009 (EDT)

[edit] Blocked Roleplayer4life

Seemed like an obvious personal attack (wiping Nephele's pages) with promises to re-attack from new accounts. So I did an infinite block. Not sure how that fits with blocking policy, but I didn't see other admins active, and figured at least some block was desirable. Please revise as needed. --Wrye 23:20, 2 May 2009 (EDT)

Thanks, Wrye. I'd say it falls under "An editor that personally attacks any member of the community will immediately be permanently blocked." -- especially having just read wikipedia's definition of personal attacks. Or maybe I'm just biased ;)

It might be worth considering blocking the user's IP address, given that all four accounts have used the same IP address. But given his personal animosity towards me, I don't think I should be the admin to make that decision. --Nephele^Talk 00:13, 3 May 2009 (EDT)

Agreed. But GuildKnight beat me to it. :) --Wrye 00:48, 3 May 2009 (EDT)

FWIW I think an indefinite block is completely appropriate for this user (and his IP). I don't think any revision is necessary. –Rpeh^{•T•C•E•} 01:02, 3 May 2009 (EDT)

[edit] Updating ProtectSection

In the year+ since we started using ProtectSection, the only problems we've had with abuse of the protect tags have all been caused by editors inserting text between the opening protect tag and the top of the article -- either adding a ton of white space to push the protected section down from the top of the page, or else enclosing the entire protected section in a pair of formatting tags.

Therefore, I'd like to propose tweaking the ProtectSection code so that if a protect tag appears at the very start of an article, then inserting any text in front of the protect tag is blocked.

I've gone ahead and made the necessary code tweaks to implement this change. While I was at it, I also effectively upgraded the extension to the current version of the extension -- which means that I've fixed some problems related to editing sections (e.g., it's not possible to use the + button to insert a new section at the bottom of a page containing protect tags). I'm going to pass the code along to Daveh right away, because I'm guessing it would save us all a lot of hassle if this change could be in place before the one-day protection of User talk:24.56.226.181 expires. Nevertheless, feedback is still welcome. --Nephele^Talk 21:02, 6 May 2009 (EDT)

Sounds good to me.--Ratwar 02:31, 7 May 2009 (EDT)

Definitely. I don't like having to fully protect talk pages but it's been the only solution in some cases. –Rpeh^{•T•C•E•} 03:23, 7 May 2009 (EDT)

The change has been made. As long as <protect> is the first thing that appears on a page, it should no longer be possible for non-admins to insert anything in front of the tag. And, as mentioned in my last post, a few other problems with the extension should also now be fixed. If anyone notices strangeness, post a followup; otherwise, I'm taking this off my todo list ;) --Nephele^Talk 16:47, 1 June 2009 (EDT)

[edit] I volunteer

to making pages for numbers 12, 14, 15, 19, and 21 (On the Wanted Categories list if my definition and the sites definition of "User" is the same. Mine is of course in-game users (Vendors, Quest Givers, misc members)

Notes:I have never done the Temple quests, but I think it would be incredibly easy for me to make the page as I go through it. Telvaani is my chosen house, always has, so I believe I would be the best candidate for making the User page.

Actually, "users" in this context refers to UESP editors/readers who wish to identify themselves with one of these categories. --GuildKnight^Talk2me 10:39, 18 May 2009 (EDT)

Sorry to ask, but isn't a category such as that really necessary? —The preceding unsigned comment was added by Chronic (talk • contribs) on 18 May 2009.

[edit] Image Layout

At some point in the site's history, a change was made to the site's css files that alters how images are laid out. This change was made directly to the common.css file that's part of the wiki source code -- instead of being made to a more visible location such as Mediawiki:common.css or Mediawiki:monobook.css. As a result it's hard to know now when the change was made or why it was made. The change is somewhat technical, but the bottom line is that it alters the default layout of images on our site and makes it so that images on our site don't behave the same way as default wikipedia behavior. I'd like to propose reversing this change.

The technical details are that for div.floatleft, table.floatleft, div.tright, and div.tleft, the css was changed to specify "clear: none", whereas the default value is "clear: left" (except for div.tright, which is "clear:right"). What that all means is that for default (non-UESP) wiki behaviour, two images with "thumb|left" placed back to back will be placed one under the other on the right side of the page. But right now on UESP, those images will be placed side by side. Whichever way things are set up, the default can always be overridden in specific cases if necessary. For example, "thumb|none" can be used instead of "thumb|left" to make images appear side by side, regardless of these css settings. Or else, tables can be used to force a particular layout.

Although in some ways the default layout is just an arbitrary preference, I think we should revert to the original mediawiki settings for a few reasons:

• It is the mediawiki default, which means it's what wikipedia regulars expect, and it's what the mediawiki software is designed for (i.e., other image-positioning features assume that clear:left is the default, and therefore are going to provide customizations based on that assumption).
• More often than not, I think that's what we want on our site. We generally want images to stay lined up against the margin, where they keep out of the way of the main text. We have numerous pages where there are currently image-alignment problems caused by the use of "clear:none" on the site. For example, I just made an edit today to Bloodmoon:Fort Frostmoth to fix image-layout problems. Lore:Dwemer is another example, that I haven't bothered to fix. On standard-width browsers, these pages look OK. But for extra-wide browsers, the images get really messed up -- the dwemer Orrery image overlaps Anumidium by a miniscule amount, and therefore the whole image gets shifted to the middle of the page, squeezing the text and leaving an unattractive empty box by the margin. There are also a ton of pages where the images would be messed up even on standard-width browsers, except we've already done various shenanigans to fix those pages.
• On the other hand, there are fewer places where we want images to appear side-by-side. At one point, the various creature pages (e.g., this version of Oblivion:Undead) had side-by-side images, but those were subsequently changed to gallery-style images. The only other examples I can think of offhand are the Morrowind material pages, e.g., Morrowind:Dwarven, and Morrowind place pages with multiple maps.
• Using "clear:left" as the default means that editors don't have to worry about what might happen on other browsers. If side-by-side behavior is actually what is desired, it is immediately obvious to an editor that the layout is wrong using "clear:left" -- for any browser settings. But with our current settings, using "clear:none", editors don't realize that the images that look well-spaced for them are an overlapping mess for other readers.
• "thumb|none" provides a very easy way to override the "clear:left" setting -- there is no such easy way to override the "clear:none" setting. Also, as just mentioned, gallery tags are another option for getting side-by-side layout -- one that works better if there are more than two or three images being displayed.
• Many of our image layout problems are caused by combining images from templates (e.g., place images inserted by a place summary template) with supplemental images added in the article itself. Fixing the layout in this case is more difficult -- you can't combine all of the images into a single table. Using the default "clear:left" settings, however, would be a very easy fix.

However, making this change will inevitably cause problems -- because there are currently images on the site that count on side-by-side layout. We can try to look for these cases now and fix them, but it's best to assume that we won't find them all. So does anyone agree that making this change is worth the problems? --Nephele^Talk 13:34, 21 May 2009 (EDT)

Well I'd agree that it's always a good idea to keep standard defaults but I'm a bit worried about the extent to which it's going to mess things up. The maps on Morrowind place pages rely on the non-default behavior although that's not very important. I'm more concerned about pages that we don't know about. I'd rather not be getting "helpful" talk page comments like "u guys suck this paige is al messd up" a year after the change.

Having said all that, it's only going to be a one-off hit and if things go really badly it can always be switched back. We may be able to benefit from templates on other sites if we share their defaults, and the argument that the current situation can be emulated but the default can't is a powerful one. On balance, I'd say "go for it", but I hope I don't regret that later! –Rpeh^{•T•C•E•} 14:17, 21 May 2009 (EDT)

What about having one of your lovely bots scan the entire site for multiple consecutive images that don't have the appropriate "thumb|" markings? Would that be possible? Then we'd know all the images that need to be checked and we could drop them into a Category or make a custom page to flag them and delete each one as it's checked. Or maybe even just add "thumb|none" to all images, to be backed out on a case-by-case basis? --Robin Hood (Talk • E-mail • Contribs) 00:55, 22 May 2009 (EDT)

Bots aren't really practical, alas. Two images placed right next to each other could have the problem, but so could two images with a bit of text between them, or one image placed on a page and another coming from a template. Then again, it also depends on the thumbnail size. The other option would work but I'm not sure it's a good idea as we'd probably end up with a mishmash of styles and it would reduce the benefit of the change. –Rpeh^{•T•C•E•} 02:59, 22 May 2009 (EDT)

Yeah, I figured you might say something like that. :) --Robin Hood (Talk • E-mail • Contribs) 14:39, 22 May 2009 (EDT)

When I started to follow up on this, I realized that |none doesn't really work as a replacement for |left -- with |none the image is not floated. So instead I decided to make it possible to specify the image's position. Images now recognize a |clear= option, that override the thumbnail's default setting:

• [[Image:example|thumb|right|clear=none]] is equivalent to UESP's current default for [[Image:example|thumb|right]]
• [[Image:example|thumb|right|clear=right]] is equivalent to the Mediawiki default for [[Image:example|thumb|right]]
• [[Image:example|thumb|right|clear=left]] and [[Image:example|thumb|right|clear=both]] are also possible if there's reason to use them.
• I just used thumb|right as an example here; a clear=x tag can be used with any image, and it will add "style=clear:x" to that image's outermost <div> tag (even if it doesn't do anything useful).

If you want to see an example of the tags in action, see the two images at the bottom of Morrowind:Places (which look exactly the same as they did before -- but you can see the change in the HTML).

I also did a regexp search in the database to find all articles which contain two thumbnailed images back-to-back. I'll go through those pages and add the explicit clear=none parameter to the images. When MW1.14 is available for testing, it will be possible to see the effect of switching the CSS to the Mediawiki defaults. If problems are noticed, or if there are concerns, the clear:none CSS codes can be added back into MW1.14 before the site is fully switched over. --Nephele^Talk 01:55, 15 June 2009 (EDT)

[edit] TemplateSandbox

After talking with Ratwar and after a look over by SerCenKing and Krusty, I have created a page for the frequently used templates (found here) in a sandbox. I was wanting to know if I can have the go-ahead to make it an actual page. If so, what is the correct namespace to use? UESPWiki? Thanks in advance.

P.S.: Sorry for ebing a pest about this, but I have a lot I want to do and I hate interrupting my tasks! Thank you! --Mr. Oblivion^(T-C) 18:45, 27 May 2009 (EDT)

Remember what I told you on your user page? By using each of those templates on the page, you put it in a lot of categories in which it shouldn't be. If, instead, you do something like this...

==Questionable Content==

* [[Template:Incomplete|Incomplete Article]]: <code>{{Incomplete|}}</code>
* [[Template:Quality|Quality Issue]]: <code>{{quality|}}</code>
* [[Template:Cleanup|Requires Cleanup]]: <code>{{Cleanup|}}</code>
: Pages with this template on them will be listed on the appropriate namespace subpage under [[:Category:Pages Needing Cleanup]].
* [[Template:Wip|Work in Progress]]: <code>{{wip|}}</code>
:Placing this on an article will let others know that you are working on it over a reasonable period of time. It will also <snip>
:* editor = name of editor who placed the WIP tag
:* date = date on which WIP tag was placed
And so on...

... it would result in this...

---

• Incomplete Article: {{Incomplete|}}
• Quality Issue: {{quality|}}
• Requires Cleanup: {{Cleanup|}}

Pages with this template on them will be listed on the appropriate namespace subpage under Category:Pages Needing Cleanup.

• Work in Progress: {{wip|}}

Placing this on an article will let others know that you are working on it over a reasonable period of time. It will also place the article into the appropriate works in progress category. The following parameters are optional:

• editor = name of editor who placed the WIP tag
• date = date on which WIP tag was placed

---

... and it will not clutter categories needlessly, plus it would make the page more compact and reduce the need for scrolling. --Gez 20:33, 27 May 2009 (EDT)

I do remember and I did definitely consider this. I made the decision to go ahead and place them on there so editors have the visual thing right there. I will wait for an Administrator to respond before I make any changes. Thanks! --20:51, 27 May 2009 (EDT)

I'd say that the most appropriate namespace is Help.

However, Gez is correct. The article doesn't belong in any of the dozens of cleanup categories to which it has currently been added, and having it appear in those categories will only cause a lot of confusion when editors try to wikify it, or find the unanswered questions, or the to-be-verified information on the page. Furthermore, it definitely does not belong in any of the deletion categories. If it continues to appear in the Speedy Deletion category, it could very well end up getting deleted accidentally, because articles in that category are supposedly ready for immediate deletion, without any further discussion or review.

Having said all of that, however, my opinion is no more important on this question than any other editor on the site. Decisions about what content belongs on the site, or where it belongs, are not the responsibility of admins -- those are community decisions. See, for example, UESPWiki:Consensus. Not to suggest that asking for feedback is unwelcome (and it probably is best to sort out questions about article namespace/name before creating the article, instead of needing to sort it out later and then having to clean up the redirects). It's just that you don't need a stamp of approval from an admin. --Nephele^Talk 22:29, 27 May 2009 (EDT)

Okay, thanks Nephele. I will edit it ASAP. I only wanted an administrative comment due to namespace and major control/understanding of categories and templates. I will edit it and go ahead and make the new page. Thanks again! --Mr. Oblivion^(T-C) 22:31, 27 May 2009 (EDT)

[edit] Morrowind vs Oblivion Parallelism (MOPP)

I was wanting to know if I can an edit on a rather large scale. It wuld consist of matching the Morrowind Quest Boxes with the Oblivion Quest Boxes. Currently, the MW quest titles for the boxes are just floating text, while OB quest titles are represented in a header. I am willing to go though and edit them all so there is consistency on the site. Thanks for the heads up!

P.S.: I moved this here due to recent inactivity of the admins. I wish to start on this as soon as I finish the template page (mentioned above). Thanks. --Mr. Oblivion^(T-C) 16:53, 29 May 2009 (EDT)

[edit] Server-level Blocks

Daveh made a few changes yesterday that will make it possible for me to help out behind-the-scenes much more than previously. In particular, I now have the ability to do server-level blocks of individual IPs that are doing DoS-type attacks on the site (as discussed originally at Blocking Rogue IPs at the Server, and more recently in posts such as Forum bots). Basically, I can now do one-week blocks of HTTP requests from specific IPs to the site's individual servers (e.g., on content1, where most of the problems have been occurring).

Within the next week (as I catch up with my new capabilities) I'm planning on posting a bit more in the way of details and proposed guidelines for such blocks, both here and on the forums (which are the most affected by these attacks). But in the meantime, I wanted to let everyone know that this is now possible. So if anyone notices that the site (or in particular content1) has become non-responsive, post a message here. Just to be clear: this type of extreme block is not for vandalism or IPs causing problems with edits to the wiki; it's for IPs that are causing problems at the server_status level.

And completely coincidentally, just as I'm finishing up this message, I get my first case. 198.24.6.168 has now been blocked on content1 after making some 30+ simultaneous forum requests, all of which were left to time out and make content1 stop responding. --Nephele^Talk 17:14, 1 June 2009 (EDT)

84.234.254.83 and 81.85.214.15 just finished with about 23 connections to content1 each - all for the forums. –Rpeh^{•T•C•E•} 01:03, 3 June 2009 (EDT)

They don't quite fit the typical profile, though -- in particular google doesn't provide a long list of incriminating reports. Also, I've been trying to keep tabs on content1 over the last two hours, and haven't noticed either IP pop again (so at least they're not creating dozens of timed-out connections at a time). For the moment I'm being a bit cautious about blocks (including unblocking the last IP, 198.24.6.168, after an hour). I'd like to work out a bit more of a notification system (including an announcement on the forums letting users know what's happening) -- just in case. Hopefully you won't have reason to curse my lack of action while I'm sleeping! --Nephele^Talk 04:21, 3 June 2009 (EDT)

In case anyone else noticed that the site stopped responding for a couple of 10+ minutes intervals just now... The culprit this time was not a rogue IP. Rather, the problem each time was that db1.uesp.net (our database server) stopped responding. Once I was able to even login to db1, it was clear that source of the problem is the database backup. One outage was while the backup was creating the uespwiki.sql dump; another 10+ minute outage was while the dhackforum database was being dumped. I can understand why backing up the uespwiki database would require a lock interfering with wiki-related database requests, but it's not so obvious why the dhackforum backup would mess up the wiki.

I remember rpeh pointing out regular site problems at this time of day at some point a while back, but I can't remember where and therefore I can't remember Daveh's response. Nevertheless, I'm wondering whether it might make sense to investigate ways to make the database backup a bit less intrusive. --Nephele^Talk 04:47, 4 June 2009 (EDT)

I think we traced the slowdowns to the daily reboot of the web server, and I'd assumed that was still the cause of the problem, since it usually happens roughly as content1 does its cycle. I did notice that the whole server, including content2, went totally glacial earlier today. It seems odd that even a full backup would be locking everything: certainly MS-SQL can do a backup while still processing queries, and I'd be a bit surprised if MySQL can't do that these days. Could a combination of server restarts and backups be causing the problem? –Rpeh^{•T•C•E•} 08:29, 4 June 2009 (EDT)

The db server was supposed to backup daily at 4am (not 4pm). I'll check its time and schedule and ensure things are set correctly. Currently content1 is set to restart the Apache server once a day. Note this is just a web server restart which should be instant and not an actual server reboot. This was setup a while ago to deal with the issue of lingering connections that wouldn't die. If restarting is causing an issue we can try disabling it.

The db backups might lock the entire database depending on how its setup. Locking all databases makes it much easier to restore a slave from a backup. Unfortunately, there is little that can be done to speed up backups other than moving from a daily to a weekly backup schedule (which I've been thinking of doing anyways). MediaWiki seems to use a combination of ISAM and InnoDB tables so we can't use the faster mysqlhotcopy rather than the current mysqldump. -- Daveh 11:23, 4 June 2009 (EDT)

The backup is starting happening at 4am, server time.

Thinking about it some more, I realized the problem isn't with any database locks. The problem is that during the backup some server resource is getting completely maxed out -- I'm guessing memory. Because when the problems were occurring, db1 was nearly completely unresponsive -- not just mysql, but all processes (it took a couple minutes just to respond to a login request, a basic command like 'ps -ef | grep dump' took a couple minutes). Perhaps if the number of mysql requests being processed exceeds some number, then memory starts getting swapped, and everything just grinds to halt? From the 'ps -ef' calls that I made during the processing, the number of mysqld processes dropped to about 30 while uespwiki.sql was being zipped, during which time the wiki was functional. But as it dumped dhackforum, the number of mysqld processes climbed to ~150 then ~230, then probably even higher (I switched to 'ps -ef | grep dump' at that point, so I don't know how many mysqld processes there were at the worst). I'm guessing the problem doesn't occur on every single dump (e.g., the six databases in between uespwiki and dhackforum seemed to be dumped without problems; the previous night the site didn't lockup during the dumps). But perhaps some combination of the dump, a couple time-consuming mysqld requests, plus the usual flood of quick requests can add up to be too much? In which case, it might also happen occasionally at other times, if there are enough difficult mysqld requests at the same time. --Nephele^Talk 11:57, 4 June 2009 (EDT)

I'm assuming what is happening is that during the backup the dbs are write-locked which means any db write request will be queued (or timeout) until the db is unlocked. I'm also assuming that any read requests will still be honored. If enough write requests get in the queue it may cause a "traffic jam" effect which makes the problem worse. This is just an un-educated guess though.

I'm not sure why the dhackforum db would be causing issues. The uesp_net_wiki5 db is the largest at 4.2GB so is obviously going to take a while to backup but the dhackforum is barely 15MB (the uesp_net_phpbb db is almost 200MB by comparison).

One of my main objectives in the near future is to ensure the site's backup procedures are working correctly and efficiently and this definitely comes under that. I still want to do backups off the master db, if not daily at least once a week. All the important dbs are being mirrored live by backup1 but there is always a risk of a mirrored db becoming corrupted so I don't want to rely solely on that. I'd like to get details on what Wikipedia (or another large MediaWiki) does for backups as this can't be an unknown issue that just UESP is having (a 4GB db is tiny compared to what some people deal with). -- Daveh 15:00, 4 June 2009 (EDT)

(outdent) I don't know if our current version of MySQL supports them, but I see MySQL 5 supports incremental backups. It might be worth looking into that as a way of reducing backup times. Have a once per week (say) full backup and then do incremental backups every other day in the week. Each daily backup will only record the changes made since the previous day so should be substantially smaller and faster than a full backup. It would mean that in the event of a disaster recovery, things would take a little longer to get going, but since UESP isn't a critical system (heresy, I know!) that shouldn't be a big problem.

I'd definitely add my voice to Daveh's statement that mirroring isn't a backup system. There have been a couple of cases fairly recently of major websites being taken down by hackers because they hit one server and the destruction was mirrored over to their backups. Mirroring is a Failover solution, not a backup solution. –Rpeh^{•T•C•E•} 16:15, 4 June 2009 (EDT)

Various random observations:

• At a first glance, various memory stats look OK (free -m, vmstat, ps aux [2]) -- at least on average, which is basically all I can see right now. If possible, I'll try to run them next time I notice a problem in progress.
• There are a series of settings in our mysql.cnf for InnoDB tables, all of which are commented out. Should they be uncommented given that the wiki primarily uses InnoDB?
  • In particular, innodb_buffer_pool_size seems important [3]; with the default 8M value mysql might be forcing itself to do disk swapping even when there's no need.
• There's a log file at /var/log/mysl/mysql.slow.log that logs queries which take longer than 1 sec to process -- but I can't read the contents ;) Might be worth checking to see some details on the slow queries and also to see when they occur.
• One tip I've seen for mysql backups is to do daily backups from the mirror/slave: lock the mirror, then backup without affecting requests to the master database.

--Nephele^Talk 17:48, 4 June 2009 (EDT)

• We're currently running MySQL 4.0.27 and, looking at the incremental backup docs, appears to support it. We're actually doing the "log-bin" for mirroring purposes I just never associated it with incremental backups. With a few changes we should be able to easily change the backup strategy on the master to take advantage of it.
• Currently we're doing daily local backups of the databases on both db1 and backup1 (the db mirror). On backup1 we just stop the slave as Nephele suggested. The only issue with backing up on the mirror is the occasional mirror error which stops the mirroring until it is manually corrected (couple of times of a year so far). I've been meaning to change db1 to weekly backups for a while now anyways.
• I did basic my.cnf tweaking when I setup db1 but I could have easily overlooked things like the innodb settings. Last I checked db1 was doing fine with memory (4GB of RAM and most of it was being used as cache) so tweaking these value shouldn't hurt things. Of course I've also never actually done any explicit performance tests so any increase/decrease in performance would have to be large to be noticed.
• I've also been meaning to document the backup strategy so it can be critiqued and improved upon (there might be some existing but its terribly out of date).

I'll look into things in more detail this weekend and make changes as needed. -- Daveh 20:59, 4 June 2009 (EDT)

Whatever is happening on db1 has been occurring multiple times per day, and not only when backups are taking place. Each time, both content1 and content2 stop responding for 5-10 minutes (can't even get server-status reports). It's possible that this issue has been going on for some time, and I'd just previously been assuming that any site slowdowns were specific to content1. However, I'm worried it might be a relatively new issue -- I hadn't previously noticed both content1 and content2 freezing up simultaneously.

Unfortunately, I'm having a very hard time getting more details on what's happening on db1 during one of these events, because while one is occurring it is always impossible for me to login to db1 -- the server won't even respond to a login request. When possible, I'll try to keep an open connection to db1 so that I'm not locked out next time it happens.

As for whether any changes recently might have prompted these problems, I can't see anything obvious. The single biggest recent performance change (fixing the file cache on content2) should have decreased db1 requests, not increased them. Similarly with the changes to the search engine -- and most of those took effect weeks ago; the most recent search updates didn't have any real performance implications. The #load and #save functions are the only changes that I can see that would increase the number of database requests, but they're being used in so few places that I can't imagine them having any widespread effect (in particular, #load is, as far as I know, only being used on two pretty obscure pages: Oblivion:Sandbox and Oblivion:Spell Effects -- and even if I purge one of those pages, I don't see any effect on db1).

In any case, I don't think we should be focussing solely on the backups as the cause/solution. I'm thinking they're just one factor that can contribute to or exacerbate the issue, but it's happening even when no backups are active. --Nephele^Talk 17:43, 5 June 2009 (EDT)

I think it's related to images. Remember this discussion? I got around the problem by uploading direct to content1, which worked fine in most cases. Since then I've noticed several occasions where pages load but the images on them take significantly longer to appear. I even got significant slowdowns when deleting images. Something is definitely not right with images at the moment. –Rpeh^{•T•C•E•} 02:15, 6 June 2009 (EDT)

I'm not so sure. I just had some ideas about images; I posted details below in a new section since the proposals there won't have any direct effect on db1 performance -- and definitely don't have anything to do with server-level blocks ;)

The $wgHashedUploadDirectory setting does not have any direct effect on db1: db1 doesn't even mount the problem image directory; it never tries to access any of the image files. So delays uploading/reading/altering image files should not cause db1 to lock up. And it's clear to me that in these recent situations, db1 is the source of the problem. content1 and content2 only stop responding to server-status requests because all of the http connection slots are filled -- by requests that are waiting for information from db1. Other than http, however, content1 and content2 are fully responsive -- I can login, command line response times are fast. On the other hand, db1 is practically dead during these events -- nothing is working on db1.

If there is a connection between db1 and images, it seems more likely to me that it's an indirect connection. For example, past image problems triggering corruption problems in the database. Or perhaps even that a wiki process on content2 locks the images table in the database before making an image change, then goes to make the physical change to the file, gets hung up on that change, and therefore leaves a lock in place for much too long, as a result blocking other wiki requests or even deadlocking two requests. Of course, I'll cross my fingers and hope that there might be some such indirect connection, it's just that I'm not ready to abandon other lines of investigation under the assumption that images are the cause.

It would really help to know the contents of /var/log/mysql/mysql.slow.log. It's clear from the timestamp that the file is being updated every time one of these lockups occur. Without knowing its contents, we're really just making circumstantial guesses about which requests are causing problems.

In the meantime, I'm trying to see what status information I can get for mysql. The image tables are all OK -- but I did just find corruption in the logging table. I'll continue scanning table status, and figure out what to about the logging table. --Nephele^Talk 15:00, 6 June 2009 (EDT)

My subjective impression so far is that since repairing the logging table, there haven't been any more freezes on db1, and the site seems to be working more smoothly again (even during our Saturday traffic peak). I also just repaired some errors in the forum's database tables; based upon some reports of strangeness on the forums, those errors may date back to May 13 or earlier, and therefore might have contributed to content1/forum slowdowns over the last month. So hopefully we've made some progress (* knock on wood *).

I'll still follow through on the image configuration/reorganization, and getting the wiki software upgraded. I also think it's still worth exploring whether some of the innodb parameters in my.cnf should be un-commented. Other than that, I think this might be going onto the back burner, at least as long as there aren't any more problems on db1. --Nephele^Talk 01:52, 7 June 2009 (EDT)

(outdent) Just a quick note that I've changed the UESP wiki backups on db1 from daily to weekly. All other databases on db1 are backed up daily as are all the slaved databases on backup1. I'll see if I can get the incremental backups working easily on content1 so it can still be a daily effective backup but without having to lock the databases for 30 minutes. Or similarily only do a complete Wiki database dumponce a month with incremental inbetween. -- Daveh 21:27, 8 June 2009 (EDT)

[edit] Possible Image Fixes

In terms of our assorted problems with images I have two ideas about what we should do:

1. Change a configuration setting, $wgHashedUploadDirectory, from false to true. I just realized that this one setting could explain a lot of the problems.
2. Upgrade to mediawiki 1.14. The code relating to images has been nearly completely rewritten between MW1.10 and MW1.14, so I'm not sure it's worth investing a lot of time tracking down a problem in obsolete code.

On the other hand, one implication of my recent thoughts is that our problems on db1 are unlikely to be related to the image issues, at least not directly.

With our current setting of $wgHashedUploadDirectory (false), every image on the site is put into the w/images directory (in our case, that's 12,720 files in a single directory). Even worse, every image thumbnail on the site is put into the w/images/thumb directory (assuming 5 thumbnails per image, that comes out to 60,000+ files). That's just way too many files in a directory, so any attempt to access an image file is likely to take extra time -- and those delays will be magnified on content2, where the directory is remotely mounted. Wikipedia and probably every other wiki with thousands of image uses $wgHashedUploadDirectory=true, and that's also the default value of the setting; with "true", the images are reorganized into 256-odd subdirectories, making the number of images per directory much more manageable.

Unfortunately, the reason why we're using $wgHashedUploadDirectory=false is because changing the parameter is not easy. We started out with "false" as the setting, because that was effectively the mediawiki default when UESP was first set up (pre MW-1.4). Furthermore, as stated on the mediawiki manual page "This parameter should not be changed after the first image or file has been uploaded". If the parameter is simply changed (without any other site changes), the wiki will no longer be able to find any of the existing images on the site. There aren't any pre-existing maintenance scripts that can be used to help convert a wiki from one image configuration to the other. I can't even find any information on mediawiki about how to convert (except for one discussion about converting in the other direction).

Nevertheless, it should be possible to convert UESP, and I think it's worth the effort. What I'd like to propose is:

1. Temporarily disable file uploads. I'm guessing this would be necessary for at most one day (possibly only for a few hours). Also, during this period, we shouldn't delete any images.
2. I'll run a script that will copy every image on the site to a new image directory, and place the copied image into the correct hashed subdirectory. This is what will take most of the time; I've already created the script and done test runs of it on my test wiki.
3. At the end of this process, we will have two complete sets of images: one using the hashed=false organization, and one using the hashed=true organization.
4. Edit LocalSettings.php on content1 to simultaneously change $wgHashedUploadDirectory to true and change the images directory to point to the new images directory; check and see whether images are still accessible on content1.
   • If there are any problems on content1, the changes to LocalSettings.php can be immediately undone, reverting images to the original configuration.
5. Assuming everything worked on content1, setup content2 to nfs-mount the new images directory and make the same changes on content2.
6. Re-enable file uploads and we're done. Eventually, delete the original copies of the images to free up the disk space.

The current size of the images directory is 3.6GB, so we have more than enough disk space (115 GB) to duplicate the entire directory.

If this plan seems acceptable, then the question is just when to do it. I'd prefer to not do it over a weekend, however the start of next week is simply not good for me. So the earliest time that I think would be good for this conversion is Wednesday-Thursday (e.g., start at maybe 8pm PDT Wednesday). Any objections to file uploads being turned off temporarily at that point? Or does anyone feel that problems are so bad right now that I should just start the process right away, even if it means there's a risk of triggering new problems when the site is at its busiest?

(Daveh, if you notice this post, there are a couple steps that you need to do: (a) create a new images directory at /home2 with whatever name you think appropriate; make sure it's got the same permissions as wikiimages (b) export that directory (c) mount that directory on content2. These could all be done right away, or else they could be done right before propagating the change to content2.)

As for the other suggestion, namely upgrading to MW1.14, I'll try to spend some time today doing some of the upgrade preparation. --Nephele^Talk 15:00, 6 June 2009 (EDT)

I think I probably speak for most site members when I say "Err... whatever you think best"! As far as I'm concerned, anything that stops the problems we've been having with images is good, and well worth putting up with a brief outage for uploading images.

I assume the upload page can actually be disabled and that we won't have people uploading images that disappear into the ether? –Rpeh^{•T•C•E•} 18:51, 6 June 2009 (EDT)

Yes, the upload page would be disabled. I would set $wgEnableUploads to false for the duration of the conversion, which removes the "Upload File" link from the sidebar, displays an error message if someone finds another way to pull up the Upload page, and makes the wiki refuse to accept any file uploads. All existing images on the site remain completely accessible, however. --Nephele^Talk 19:10, 6 June 2009 (EDT)

Possibly worrying too much here, but... my reply wasn't meant to sound dismissive - it's just that I don't know enough about MW/Linux to do much more than defer to your judgment. As for the upload page - I assumed that's what would happen but thought I'd better check. All sounds good to me. –Rpeh^{•T•C•E•} 19:42, 6 June 2009 (EDT)

I've added /home2/wikiimages2 to content1 and shared it to content2 as requested. Disabled file uploads for a few days shouldn't be much of a problem. Preferably include a noteor something on the upload page saying its temporarily disabled and will be working in a few days. I would wait until after the weekend before starting anything. -- Daveh 20:07, 6 June 2009 (EDT)

Oops, I just noticed one small problem: the permission on /home2/wikiimages2 needs to be changed to 775 (so apache group can write to the directory). At the moment, I'm unable to write any of the new files to the directory. --Nephele^Talk 23:53, 11 June 2009 (EDT)

Given that I couldn't write the images to the correct location, I basically did a dry run tonight then re-enabled file uploads. The entire copy takes less than half an hour, so once the wikiimages2 directory is fixed, it should take about an hour to do everything properly. --Nephele^Talk 01:40, 12 June 2009 (EDT)

Er, should I hold off on image deletions for now? I've noticed the process is pretty sluggish and I don't want to mess with whatever you're working on. –Eshe^talk 01:45, 12 June 2009 (EDT)

It's probably better to hold off. It's not that you're messing with what I'm doing; it's that until some of these changes are implemented, you're going to keep hitting the problems that are making these changes necessary. Problems such as image alterations locking up content2, and files only getting partially deleted because content2 is locked up (e.g., the pictures of Eris Senim and Aevnir). --Nephele^Talk 01:50, 12 June 2009 (EDT)

Well that would explain some of the strange things I've been running into then! I'll work on it later. Thanks Neph :). –Eshe^talk 01:53, 12 June 2009 (EDT)

Images have been reorganized, and we are now using $wgHashedUploadDirectory=true. There are a few quirky workarounds that I took just so I could get the job done now (otherwise it might have been two weeks before I would be able to do this), which means that there are a few more tweaks that should be done eventually. However, any further tweaks can be done without disrupting the wiki.

For anyone who is curious, we had 12,770 files in the images directory, 2595 in the images/archive directory, and 49,070 thumbnails in the images/thumb directory.

If you notice any problems related to images let me know. I'd say if there aren't any reports of problems within the next day or so, then we might as well try image deletion, too, just to see whether it seems to be working any more smoothly (if not, there's still a wiki upgrade to come). --Nephele^Talk 15:07, 12 June 2009 (EDT)

[edit] Missing Oblivion Easter Egg

Discussion moved to Easter Eggs.

[edit] Cookie Problem?

I'm suddenly getting the ol' "Loss of session data" error when I try to save whilst logged in. Do we have a problem? 85.92.194.123 08:21, 9 June 2009 (EDT) (aka, Rpeh)

It was a /tmp on content1 filling up which prevented php sessions from being created. I've moved the UESP wiki file cache to /tmp1/cache (with a sym-link in /tmp/cache) to prevent it from happening again. -- Daveh 08:49, 9 June 2009 (EDT)

Ah! Much better. Thanks. –Rpeh^{•T•C•E•} 08:51, 9 June 2009 (EDT)

Except /tmp1/cache is owned by root and can't be written to by apache. So I've changed LocalSettings.php to use /tmp1/cache1. Any chance you could clean up /tmp1/cache and /tmp/cache (both of which are owned by root, so I can't do anything to them). --Nephele^Talk 00:39, 12 June 2009 (EDT)

[edit] Mods Map request

I've made a request for some help in developing a mods map for [ORE], that conversation can be found here. It was recommended to bring the discussion here, hopefully to catch the attention of some of the admins who are not actively monitoring the UESP map's talk page. We'd like permission to use images and possibly code from your map in the creation of a mods map. Thanks :) --75.70.19.85 14:55, 18 June 2009 (EDT)

I'm more than happy for tiles I've created to be used elsewhere as long as it fits in with the standard UESP licensing conditions, but the tiles I've made so far won't be of much use to you. If you look at our map, you'll see a big blank space where Frostcrag Spire should be. The same will happen with any of your mods. To get around that you'll need to do the tiles yourself and run the artifact remover over the tiles. At the moment, I'm not prepared to release the code into the public domain for the simple reason that's it far too ad-hoc and hackish. The version of the code I used for the Shivering Isles map killed the OB map and vice-versa - the colours are too different. I spent two solid days trying to get rid of everything on the OB map a couple of weeks ago and it turns out there's still more work to do. I will release the source at some point, but not until it's in a more usable state. –Rpeh^{•T•C•E•} 18:11, 19 June 2009 (EDT)

If by "big blank space" you mean the lack of an actual spire on the tile as opposed to a ruin where the actual ruin itself is visible and not just a marker - I don't think we're too worried about that. The primary purpose is to help players find mods based on location and to help modders find some empty space to place their mods. As far as licensing goes, if you're referring to the section in Copyright and Ownership regarding using materials from UESP, I'm quite certain we can agree to those terms, but I'll redirect the other ORE members involved to that page so that we're all aware of it. Having the tiles would be the biggest help, I believe, since as you say it's taken quite a bit of time and work to get them to where they are and I don't see any reason to make a duplicate effort if it can be avoided. Thanks for the response :) —The preceding unsigned comment was added by 75.70.19.85 (talk • contribs) on 24 June 2009.

That's fine then. You might want to look at doing your own tiles for places with mods though. Since you're all modders, the thought occurs that you wouldn't need my program anyway as you can just temporarily remove collision boxes, monsters and other items that make a mark, then resize by hand. Including modded content makes quite a difference - Frostcrag Spire is pretty from above! –Rpeh^{•T•C•E•} 01:01, 24 June 2009 (EDT)

I have an e-mail address where things can be sent, it's ore (at) oblivionsrealestate.com. We really appreciate all the help and resources you guys can give us :) —The preceding unsigned comment was added by 75.70.19.85 (talk • contribs) on 14 July 2009.

[edit] External Editor

I'm looking at a link to Edit this file using an external application, but the setup instructions are confusing.

"Associate the MIME type application/external-editor in your web browser with ee.pl" [4] I understand now, I don't like it. How come the PHP file is supposed to be associated with that local perl script? This seems like an complicated and unnecessary hack. Lukish_ Tlk Cnt 00:00, 24 June 2009 (EDT)

I moved this question here (from UESPWiki talk:MediaWiki 1.14 Upgrade) because it's unrelated to the MW1.14 upgrade -- when you posted the question, the site had not yet been upgraded, and was behaving the exact same way as it has for the last three years (at least).

As for the actual question, that's simply how external editing works. I've never used it, and honestly if you want help with how to use an external editor or complaints about why it works that way, somewhere like MediaWiki is probably a better place to start. Other than that, I can't provide much feedback, especially not right now. --Nephele^Talk 17:06, 24 June 2009 (UTC)

[edit] Rename Request

The information about the MediaWiki Upgrade says "Admins can rename users. Not that renaming users is a frequent occurrence, but it seems like a task that can be entrusted to admins." Would it be possible to have my username changed from Rayjquinn to Viroconium? It's something I've wanted for a long time and is a better option than starting a new account (which I should have done a year ago). «Ray♦Quinn» 23:46, 24 June 2009 (UTC)

I'll see what I can do. Just so you know, you may "lose" your past contributions to the site, but I'm not sure. If you're okay with that, I'll go ahead and give it a shot. New buttons, ahoy! –Eshe^talk 01:15, 25 June 2009 (UTC)

Yeah, that's fine if it happens. I don't have 10,000 edits (or even 30), so it's okay. Thanks Eshe. «Ray♦Quinn» 03:46, 25 June 2009 (UTC)

Thanks (in advance!) for following up on this, Eshe. I considered trying to do it myself, then realized it wouldn't be a good test of the new admin capabilities, given that Daveh bureaucrat-ized me a few days ago. Plus, it would be best to give the rename user feature a full test right now while I'm actively focussed on the site's code ;) --Nephele^Talk 03:58, 25 June 2009 (UTC)

No problem :). Looks like it worked! It moved the user and talk pages in one fell swoop. Also, it looks like all the past contributions have been reattributed as well! That was fun :D. –Eshe^talk 04:05, 25 June 2009 (UTC)

Awesome! Thanks again. :D VIROCONIUM 12:23, 25 June 2009 (UTC)

[edit] Request for Adminship

(moved to User:Timenn/RfA)

[edit] Registered Spammers?

We've had two "users" in the last several days that have been blocked for spam: "795 buy celebrex" on the 26th and "385 buy propecia" just today. Our blocking policy doesn't really say what to do with registered spammers, but it seemed pretty clear to me that these accounts were created for no other purpose, which is why I've gone ahead with an immediate block in both cases.

I don't know if there's some kind of automated something-or-other making these accounts (it seems unlikely), but if someone more knowledgeable could look into it that would be great. If you look at their deleted page histories, you'll see they've been pretty much identical. I would also appreciate it if others could please be on the lookout for this kind of thing and at least replace the spam page with a speedy delete notice until I come along. Thanks! –Eshe^talk 15:56, 28 June 2009 (UTC)

I think it probably is an automated task: The Oblivion Mods Wiki has had "988 buy trileptal", "364 buy cardura‎" and "88 buy capoten‎" and both ours have come from the same ISP in Russia. We could slap a range block on the necessary IPs but that may be a bit extreme just yet. –Rpeh^{•T•C•E•} 16:12, 28 June 2009 (UTC)

To be fair, registered spammers are hardly new to the site, whilst they may not be as common as other types they normally seem to just get the same treatment as any other spammer. Looking over the section covering first offense blocks, i fell a little re-wording may be necessary where the first point states "Editors (or IP addresses)" whilst all other points simply state "An anonymous IP address" quite how having an account should affect a vandals block status i dont quite understand, any thoughts? --Volanaro ^Talk 16:40, 28 June 2009 (UTC)

The fact that these accounts are somehow being created automatically is a bit worrisome -- implying that a hacker has found a way to circumvent our Captcha system. It could mean that an algorithm has been found to crack the Captcha; or it could mean that a site has been set up where people are being asked to translate our Captchas (e.g., in exchange for a reward, or as part of a fake login process on another site).

Nevertheless, I'm thinking that we should be able to stop this, and simultaneously fix another issue, namely certain overly popular account names (e.g., Gray Fox variants): I could add a username blacklist to the site. A quick search shows at least one extension that provides such a feature. Entries on the blacklist would then be, for example, '^\d+ buy' and 'gr.y fox'; no accounts matching those patterns could be created any more. The list would be editable by admins, so if a new pattern for spambot account names emerges, any admin could add an appropriate new entry. I can't think of any reasons not to add the extension. --Nephele^Talk 17:08, 28 June 2009 (UTC)

Correction, admins who know regular expressions! That looks like a good idea. There have been a few other accounts (the M'aiq variants) that have several duplicates so it could be of use. Of course, we have to spot which ones are getting popular in time, but that should be easier now the User Creation log shows up too. –Rpeh^{•T•C•E•} 17:34, 28 June 2009 (UTC)

After a few botched attempts, the blacklist seems to be in place and working. The biggest problem appears to be getting any changes to MediaWiki:Titleblacklist to register on both content1 and content2. It seems that the page needs to actually be saved on each server in order for that server to load the new version. Long-term, I think we need to do some reconfiguration of our memcaches (IIRC, wikipedia only has a single memcache, used by all servers, not a separate memcache for each server), but I'll leave that issue for another day. In the meantime, we'll just need to remember to do a dummy edit or two. --Nephele^Talk 20:38, 28 June 2009 (UTC)

[edit] Patroller Policy Change

I've just updated the policy page on Patrollers. Since administrators have been given the ability to make these changes it seems perverse not to make the change, but if anybody disagrees, this is the place to express that disagreement. –rpeh^{•T•C•E•} 17:36, 3 July 2009 (UTC)

[edit] Request Block for 90.220.242.186

This anonymous user has already been warned and after the fact decided to spam an external link. If you look at his minor contributions and current talk page, you will understand why. Thanks. --Elliot^(T-C) 15:27, 22 July 2009 (UTC)

[edit] Deleting to Restore

You may have noticed I deleted User:Elliot and restored it without the various obnoxious comments left by idiots from Encyclopedia Dramatica (that's a tautology, I know). As this isn't really covered by the deletion policy I thought I ought to post a brief explanation and perhaps start a debate.

Firstly, some of the comments were extremely offensive, and secondly, the large diffs were hurting the server - at one point about half the connections to content2 were getting the recent changes RSS feed. If anybody feels I shouldn't have done this, feel free to restore the deleted edits.

I don't want to start regularly censoring pages, as it's usually better to see the edits vandals made to judge future sanctions. Do we want to use this mechanism for extreme cases? What about special cases such as edits that damage the ability of others to access the site? Do we want to modify the policy or leave it up to the judgment of admins to act accordingly? –rpeh^{•T•C•E•} 09:29, 26 July 2009 (UTC)

Update - several hours later there are still a lot of people downloading the recent changes RSS, so it seems this was a deliberate attempt to slow down the site. –rpeh^{•T•C•E•} 10:20, 26 July 2009 (UTC)

Yes, delete/restore was probably the best course of action in this particular case. Long-term, I'd like to find a way to fix these problem diffs, instead of adding a policy just to cover a software bug. I'd been hoping the bug might have been fixed by the last upgrade, but obviously not. Unfortunately, debugging the problem without again messing up the site might be tricky.

As for the RSS/atom connections, it's unlikely there was anything malicious behind the connections. It's simply the primary symptom of the problem diffs: any attempt to view the diff permanently locks up a connection on the server. The connections you saw several hours later were the same ones you had seen originally (which can be confirmed via the SS column, which ended up reaching values above 56000). The only ways to get rid of the connections are to restart apache or otherwise kill the process on the server, which I did a few hours ago. --Nephele^Talk 23:39, 26 July 2009 (UTC)

I believe that if it compromises the server and people's ability to use the site, it should be gone (barring extreme cases). Also, I happened to stumble upon something Wikipedia uses called Oversight. Here is part of the intro paragraph explaining it:

Suppression on Wikipedia (in the past also known as Oversighting) is a form of enhanced deletion which, unlike normal deletion, expunges information from any form of usual access even by administrators. It is used within strict limits to hide the username, revision content, and/or edit summary in order to remove defamatory material, to protect privacy, and sometimes to remove serious copyright violations. When using the suppression function on an edit, it is possible to suppress the text of a revision, the username or IP address of a contributor, and the edit summary of a contribution, or any combination thereof...

It sounds like possibly something we could use for this type of vandalism. The page explains their policies more with MediaWiki holding the extension. I am just throwing it out there, in-case you guys have not seen this. --Elliot ^talk 20:29, 27 July 2009 (UTC)

I wasn't going to mention Oversight as I've never liked it. The difference between oversight and what I did is that other admins can still see what I deleted, and indeed those edits show up in a "Deleted user contributions" link on the IPs concerned. With Oversighting... it's gone - you have to go into the database to recover the information. In this particular case, I mentioned it here because although I could stretch the deletion policy under the "site disruption" clause, it's still an unconventional use. I also stated that if any other admin had a problem with my action they could restore the deleted edits, in case anybody wanted a site-wide debate. With Oversight, that wouldn't be an option.

The difference is between "I've done this, and I'm telling you so other admins can check and tell me what they think" and "I've done something, but you can't see what so just trust me". Unlike Wikipedia, we have a very small number of admins, which means that even if sensitive information is posted, it can be deleted and only those few people - as opposed to the thousands on WP - can see it.

In other words, I'd prefer to steer clear of Oversight for now. –rpeh^{•T•C•E•}

Ah, I see. Perhaps it should just be given to Daveh and Nephele? In any case, I was just making sure you knew about it! :) --Elliot ^talk 21:48, 27 July 2009 (UTC)

Maybe we do need Oversight after all. This is getting tiresome. –rpeh^{•T•C•E•} 11:14, 17 August 2009 (UTC)

I looked into Oversight just now, but it didn't look like it provided the one feature I was looking for right now (namely the ability to erase user accounts from all logs). However, I'm willing to install it to make it easier to erase revisions from the logs, especially if continued problems warrant it. Given the lack of any type of undo feature with Oversight (short of manually altering the database), I'm not sure whether anyone other Daveh and I should have access to it (since we are the only two people who could fix any mistakes made while using the feature). But I'm open to feedback on that point. --Nephele^Talk 05:30, 19 August 2009 (UTC)

[edit] Namespace Links

I've created aliases for all of our namespaces using their standard IDs -- i.e., the IDs listed on Mediawiki:Uespnamespacelist. Therefore, links such as OB:Jauffre or MW:Creeper are now possible, for those who might find typing the full namespace excessively onerous. Unlike the OB/MW/etc templates that have previously been used for this purpose, there is a minimal CPU overhead associated with the aliases. The only namespaces for which this will not work are MAIN (the software doesn't support aliases for main), TR3, and TR4 (which are fake namespaces).

If there are problems/concerns with this feature, I can easily remove it. On the other hand, if everyone agrees this is better than our existing templates, I think we can propose deletion for many of the templates in Category:Link Templates; documentation such as UESPWiki:Namespaces, Help:Namespaces, and Help:Links would also need to be updated

One other, semi-related question is about our transparent namespace links. For example, if I type [[Archive]] it automatically gets expanded to [[UESPWiki:Archive|Archive]] when I save the page. There's an alternative way this feature could be implemented: have the original [[Archive]] text be preserved when the page is saved, yet still have the link displayed in HTML article as a link looking like Archive. I've already coded up this alternative treatment, and it's been implemented successfully on a wiki at work for a couple months. Therefore, the main question is what would be preferable here. The advantage to the current approach is that you can explicitly see how the link is transformed (although only if you re-edit the page). The disadvantages, in my mind, are that it's more difficult to subsequently edit the link (any typo needs to be fixed twice) and that new editors are generally not aware that the shortcut exists (because they never see it being used on articles). Any thoughts on which approach we should use? --Nephele^Talk 22:28, 2 August 2009 (UTC)

Would the [[OB:]], for instance, get re-formatted into [[Oblivion:]] or would it stay as [[OB:]]? This is the same thing Wikipedia does with their WP shortcut, I think, and it certainly doesn't seem to be bothering them any, though personally, I sort of like the order imposed by having them all be the same format. I believe [[some link]] would stay as exactly that on Wikipedia, so it may be slightly more comfortable for Wikipedia users when they come here. (I also think it looks cleaner and would therefore prefer it personally as well, but it probably messes with peoples' minds when I advocate consistency in one sentence and then flexibility in the next. <g>;) --Robin Hood (Talk • E-mail • Contribs) 03:05, 3 August 2009 (UTC)

Oh, I was about to ask someone about this, since it really works on Wikipedia. I think I will mainly use them in informal settings, such as in edit summaries and in the UESP namespace. Otherwise, I think we should still use Oblivion: and Morrowind: etc. in the game namespaces, otherwise new editors might get confused (as they do with sic). So to recap: Talk namespace, UESP namespace, etc. should use the shortcut namespace entries. Game namespaces should use the full one.

So, what are the shortcuts for Daggerfall, Arena, Lore, and UESPWiki? Thanks for adding this! –Elliot ^talk 03:19, 3 August 2009 (UTC)

I like it. As long as there's no(t much) overhead then it's a good idea.

Judging from Nephele's post, it looks like the links don't get expanded when you save, but they are expanded when presented to the user, so you get the full link displayed (eg http://www.uesp.net/wiki/Morrowind:Creeper for MW:Creeper).

The other shortcuts are listed on the page Nephele linked to: Mediawiki:Uespnamespacelist. So DF, AR, LO and UESP for those specific cases. –rpeh^{•T•C•E•} 06:39, 3 August 2009 (UTC)

Thanks for answering the questions for me, rpeh. One other point worth mentioning is that the aliases work in a lot of places other than just links: in manually-typed URLs; in the search box (e.g., "go OB:Armor"). Also, the aliases are not case-sensitive (no namespace names are). So "go ob:armor" works just as well.

As for recommended usage, I think just saying that the full namespace names are preferred is sufficient. Editors can use the shortcuts if they feel it's necessary (otherwise why have them?), but hopefully they'd eventually be converted into full namespaces. The only "forbidden" action should be converting a full namespace link into an abbreviation. That's my opinion. --Nephele^Talk 05:45, 4 August 2009 (UTC)

Speaking as an editor who can type Oblivion nearly as fast as OB I still think the addition warrants enough merit for it to happen if there are enough regular editors supporting it. But I'm not comfortable with the change of no longer subsituting shortcuts to full links (e.g. [[OB:Armor]] => [[Oblivion:Armor|Armor]]). The thing I like about all the shortcuts is that they don't show in the actual article, instead it will contain links in only one format. Otherwise you would see a combination of different kinds of formatting, which seem more confusing to me to new editors than one link format.

The new shortcuts will mostly benefit the more active editors, which are likely already aware of them. I agree it might be an idea to better inform newer editors of the shortcuts, but the shortcuts will only start to be helpful if you are editing more articles than just one per day. --Timenn-<talk> 08:48, 4 August 2009 (UTC)

I pretty much agree with Timenn and Neph. The only time I really see myself using them is in edit summaries (where it is sometimes hard to fit a link in) and talk pages (for speed I guess), like a mentioned before. I don't think we should use them in any of the articles that contain information (so... like 90% of them). I have been thinking about the use of [[User:Elliot|]] and haven't decided if this should be avoided. –Elliot ^talk 08:56, 4 August 2009 (UTC)

[edit] New Servers

I'm planning on replacing/buying a few servers in the near future. My general plan is:

• Replace the monthly content1 with a 24-month server (i.e., it is currently billed monthly, paying for 24-months up front gets us a better price)
• Similarily replace squid1 with a 24-month server, upgrading bandwidth to 100Mbs and 3000GB/month (currently at 10Mbps, 1500GB/month)
• Possibly purchase db2/backup2 for backup/redundancy purposes (a little overkill to have 2 db servers but mainly to make it easier and quicker to recover from failures)

The main reason for replacing content1/squid1 is to reduce the monthly server cost and eliminate excess bandwidth fees (over 1300$ alone in the past year). If we do this and purchase db2 we'll end up saving about 1000$ per year. See Site_Costs for more details.

If anyone has any other ideas or requests for server upgrades, either a new server or upgrading an existing one, just let me know. -- Daveh 19:54, 4 August 2009 (UTC)

Question: Instead of getting a new server for db2/backup2 why don't we just use util1/content3? I mean, weren't we running fine just having two content servers? Besides, the Summer is almost over, we're probably going to lose traffic due to people going back to school and such. Then again, according to site support, we've got enough money to get a little more redundancy. Of course, I'm not a server guy, so I don't really know. --Ratwar 20:46, 4 August 2009 (UTC)

We could, although my "grand plan" is to have content1/content2 solely handle the UESP Wiki content and leave content3 with serving everything else (forums mainly) as well as being the misc/utility server (e-mail for example). Whatever happens I'll be doing things one at a time anyways starting with replacing squid1 and then content1. If anything happens immediately with db2/backup2 it would be next month at the earliest.

Along the lines of your idea though...content3 could probably do everything (misc content, db backup, e-mail, etc...) as all of this is very low load compared to what the UESP Wiki uses. -- Daveh 21:20, 4 August 2009 (UTC)

What I'm going to do for now is purchase the squid1 replacement since that represents the greatest potential savings and is the easiest to setup (250$ for extra bandwidth in July alone). The content1 replacement will be in a few weeks depending on my schedule. There are a couple of options regarding db2 or upgrading db1 (hard drives, RAID, etc...) so whatever happens there will happen in a month or so. -- Daveh 21:40, 5 August 2009 (UTC)

[edit] Patrolling Style - Elliot

Over the past few weeks I have been concerned at the style of Elliot's patrolling of the wiki. The latest series of edits have brought me to the point where I feel I have to ask the community to consider removal of Elliot's patroller status for a short period.

The latest discussion isn't the only example of style that isn't really appropriate for a patroller.

• This discussion highlights the difference between Elliot's style and that of a non-patroller (Wolok_gro-Barok). Elliot's replies don't really explain anything to the user but Wolok's immediately give a clear explanation.
• In this case the poster admits that the information s/he added may not be including; Elliot's response is harsh and dismissive.
• This is such a horrible post I almost removed it before posting my own response, which solved the problem.
• This removal of an editor's suggestion was reverted by Ratwar. We both found it an ingenious use of one glitch to fix another.
• This edit removed potentially useful information. An editor of Elliot's authority should have spotted that the information wasn't included anywhere else on the page and either improved the original edit or linked to the correct page.
• This reply is just wrong, as a very brief search would have confirmed.
• (I could supply others but this will do for now)

His style and terse edit summaries have already been discussed on his talk page (here and here), and I know other editors (including myself) have tried to discuss his style with him on IRC.

I should say here that well over 95% of Elliot's edits have been fine, and it's just a few that cause a problem. None of these are bad on their own, but the overall pattern is not good. The net result is that I find myself having to double-check both edits that he makes and ones that he patrols: this is usually used as a criterion to reject a patroller nomination.

I should say here that I'm fully aware my own edit history has sometimes caused... raised eyebrows... from others. The difference is that I have learned from what other people have told me and have changed my style accordingly. Elliot shows no signs of doing this.

Since we have no defined policy, I'm going to suggest a temporary measure with a view to formalising a process in due course. I suggest that Elliot's patroller status be removed for a period of two weeks. After this period his status would be reinstated automatically, hopefully with a better perspective gained.

I'm not calling for a vote at this point. Ideally I'd like to hear other editors' opinions including, obviously, Elliot's. Any actions can be voted on later, should that be necessary. –rpeh^{•T•C•E•} 20:02, 5 August 2009 (UTC)

I can't say I pay that much attention to Elliot's (or anyone else's) edits, but what I have read of his summaries is often abbrassive and confrontational---two qualities wholely undesirable in anyone in a position of any authority at UESP: it runs the risk of casual visitors and contributors getting a bad impression not only of Elliot, who does indeed contribute many good edits, but of UESP in general. If only for the sake of UESP's image I agree that the pattern you've outlined, rpeh, cannot continue without intervention. As for hat to do about it, a fortnight's revokation seems sensible to me as an emergency measure. Anything else should, I think, be dependent on Elliot's own input. JKing 00:27, 6 August 2009 (UTC)

While some of it doesn't speak well of his diplomatic skill, I've certainly seen as bad out of other Admins and Patrollers alike. As you say, it doesn't reflect well on UESP at large when we're a bit snarky, but it happens. Given that he's only been here for a little over 2 months, I'm not sure he's had time to really absorb the level of diplomacy expected from someone "on staff", so to speak (which may be a good reason to put a minimum time limit in for Patrollers, etc., but that's another discussion). If possible, I'd like to see it taken up with him directly by someone (yeah, okay, so I guess that's probably me) whom he gets along with and is likely to have a productive discussion with, rather than feeling like a bunch of people are jumping on his back about it (as would probably have been the case if there was an IRC discussion, where it may have seemed like one vs. many).

I'm not sure what two weeks would really accomplish. To me, that seems punitive, which is only likely to aggravate the situation. I think an informal agreement for him to only patrol non-controversial edits for a while until he gets the hang of a more diplomatic approach might be more constructive.

Oh and I don't see mention of this on his talk page...I assume you e-mailed him privately about it, to make sure he has a chance to respond? --Robin Hood (Talk • E-mail • Contribs) 04:14, 6 August 2009 (UTC)

Last question first: he was told about it in IRC so is definitely aware.

I ought to make clear that the post was not a spur-of-the-moment response to one series of posts. I'm going to go through a bit of the history to make clear that there has been a lot of effort from several people to resolve this in other ways. I'm not going into full detail because some of the communication was private.

Elliot was given patroller status on 21 June. Almost immediately, I noticed that his style changed from being helpful and friendly to being rather forceful and opinionated. Take these two edit summaries, for instance. The first undo was correct, the second wasn't, but in both cases the edit summary was worrying. A couple of days later I got my first email from another editor expressing their concern. I have had others since.

On 6 July, two weeks after his election, came the Protect Tags incident. This was when I started having serious doubts about Elliot's status. I had a long discussion about it with him in IRC, not just about the policy violation, but about the principal of using special abilities to lock a discussion in which one is a participant. When the discussion ended I was still unsure whether Elliot had understood that point, one that you (RobinHood) picked up on immediately (from your response to Elliot and Nephele on his talk page).

By now, more people were expressing doubts and there were several informal discussions in IRC about how to proceed. Eventually, on 14 July, all the active admins were consulted through email or using IRC, about their thoughts on the matter. This was not, it's important to note, circumventing the site. It was simply a way to canvass opinion and discuss ideas. Any formal discussion would have taken place - like this - on the site. The end result was that one of the admins agreed to discuss the problems with Elliot. In any case, two days later Elliot made this post to his user page and the issue seemed moot. His retraction, less than 24 hours later, re-opened the matter. I decided to see if events had impressed themselves on him and whether this would make a difference.

It didn't. The same style has continued and the same complaints keep coming. Since at least four different people have tried discussing Elliot's style with him, all to no avail, there is a need to try something else. The purpose of a two week removal of status isn't to punish, it's to help the site. Other patrollers will no longer need to check every edit in case it's one that Elliot has patrolled. His own edits will not be automatically patrolled and so will stand out more easily. And hopefully, since all the problems seemed to start when he was made a patroller, the removal might cure the bad style and remind everybody why he was a unanimous choice for patroller in the first place. I'm open to any other suggestions for remedies, but I believe the time for simply talking has long passed. –rpeh^{•T•C•E•} 07:22, 6 August 2009 (UTC)

What exactly do you want me to say? It was made aware to me through GK, that I was improving and that she was glad that I was trying. And then this states I haven't been improving, so I am rather confused. Again, I never intended to take a malicious tone when I reply, it is just who I am naturally. A month is not enough time to change such behavior (and like I said, GK said I was improving). I could possible dig up everything wrong that other patrollers or admins have done, but I don't feel that is necessary. And with the protect incident. As I said before, I said it was a mix-up of different site policies, to which you replied "Oh rubbish". Within that same conversation, you accused me of lying more. I don't see how that is proactive in any sense of the word. Are we perfect? No. And that seems to be something easily forgotten.

Then we come to the edits which you have dug up. I believe the only reason I stick out is because I am the most active patroller. I make plenty of edits, which allows itself a higher chance to "slip up" or do something wrong. I stick out like a sore thumb due the amount of edits, replies, patrols I make. Yeah, I'm sorry for messing up, but we all do it. Sometimes you are pretty sure you are right about something when you are completely wrong. Guilty. I never said I was perfect, and I don't claim to be. Like I said before, in the real world, I am known for being a smart-ass with a quick whit and silver tongue with an ego to match. Frankly, I find myself doing rather well considering how I am IRL. Am I working on it? Yes, but it is pretty hard changing who you are (and with all the drama the real world carries with it, fighting parents, medical bills racking up, etc.).

I usually come to the wiki for a solace, but as of late, it has become nightmarish. So I actually agree with the two week step-down (or however you want to put it). I think it would be best for me (since I haven't been able to receive any antidepressants as of late). But I won't promise to be as active as ever within that period (or even after, for that matter). Sometimes you have to answer the call of real life, and sometimes it becomes hard to salvage after so much has gone on. The me in real life is actually doing a lot of soul searching (especially with college on the horizon), so perhaps a two week period would be good for me to self-analyze and self-correct. I'm am actually a compromising and understanding person, but it hardly comes across that way unless you really know me, which, unfortunately, none of you have had the chance to do; ergo, I come across as this monster (just ask my teachers in high school, I made people cry with anger by just talking about welfare). But I mean no harm, and I never have.

So, like I said, I am all for the two week time frame. However, I believe Nephele should do the actual action, as she is the most neutral person to possibly do it. Also, I ask that my name be left on the patroller page and the userbox left on my page, since this isn't a removal of my rights but rather a variant of a curb checking (which I am agreeing to). Again, I am sorry for all of the nonsense I have created and hope this can all be resolved, eventually. And I hope I get better in both instances. Thanks. –Elliot ^talk 10:54, 6 August 2009 (UTC)

Edit conflict...

Though I'm one as the supporters for the "talk first, act later" approach, I have been absent the past week, so I can't see well enough if that time has already passed. I do think the examples rpeh posted say enough, giving more would only be admonishing as Elliot is still a respectable editor. It's more that we try to find the precise point that is troubling us. For me it is the attitude towards newer editors, and the dismissal of potentially helpful additions. Let me adress the attitude issue first:

From out point of view it looks like some question are asked over and over again, but from the person who asks the question again it may be his/her first time posting something like that. Does he really ask because he is too lazy to search? I can think of more good reasons: The reader is still uncomfortable with English sites which so much content (i.e. text to read), the reader is not adept at searching (not everyone is adept at that) or the reader did search extensivily, but only encountered dismissals from other editors. I can remember from my days of searching for answer on working with the Warcraft III Map Editor the frustation with finally finding a topic on a message board somewhere with a similar question, on to have the topic started be dismissed with the advice to search the message board for a similar question asked earlier. A regular visitor of the site, who has its posting history in his memory, often forgets how overwhelming the content can be to newcomers.

In other words, I understand the need to blow off steam at IRC from time to time, but don't do it posting it here on talk pages or edit summaries.

The second issue is also worrysome. The challenge of patrolling is judging whether a new addition or modification is sound or not. The problem is that if you take to much time researching every edit, it won't leave you time to do your own work, but sometimes it just comes with the job. It's better to waste too much time, than to dismiss what could have been a brilliant idea only badly worded. --Timenn-<talk> 11:14, 6 August 2009 (UTC)

Now adding my reply to Elliot

I understand how you feel most of the patrolling has come down to you, but let me add that this doesn't necessarily mean there are no other patrollers standing by. The fact that a long list is gathering just means that there isn't a patroller standing by at that time. Myself, for example, usually work from the list in one go. If I miss a day, I make up for it the next day.

As for the requirement for perfection. No we don't have it, but we do try to point out a certain pattern in attitude/patrolling style we'd wish to adress. Whether you make mistakes isn't the issue. --Timenn-<talk> 11:27, 6 August 2009 (UTC)

Elliot, in our original conversation about patrol tags, that took place only minutes after I had removed them, you didn't mention Wikipedia or policy confusion once, so forgive me if I'm sceptical when that becomes the centrepiece of your argument some weeks later.

I'm not accusing you of being a monster or even of acting in bad faith. In a way, what's happening is more problematic. If you were acting in bad faith there would be no difficulty in acting under existing site policies and issue a warning or a ban. I fully understand you're acting in good faith, but you're doing it in a way that is causing widespread disquiet. Additionally, you always defend your actions even when the problems are brought to your attention. You claimed to understand the point I made about escalating disputes but yesterday's series of edits did exactly the same again, so what has changed? In your final post, you said "So stop making something out of nothing" but if you had followed your own advice the problem would never have occurred and I wouldn't be writing this.

I would love to see you continue contributing to the site because, as I said in my original post, the vast majority of your edits have been great. You will need to start listening to other people, though, and learning from what they tell you. –rpeh^{•T•C•E•} 11:58, 6 August 2009 (UTC)

Okay, so it looks to me like we have an agreement from both sides for a two-week suspension, and hopefully that'll give a little time for everybody to cool off and reflect. (And yes, I say "everybody" in italics because while I certainly see some issues here, I do think they're being blown out of proportion, probably due to the last month of back & forth discussions.)

While it's a little unusual, I understand Elliot's desire to leave the indicators of his Patroller status in place while he no longer has that permission, and I didn't see any complaints at the thought by either Timenn or rpeh. I don't particularly see a reason for Nephele to make the permissions changes, but respecting Elliot's wish for that to be done, I'll send Nephele an e-mail and ask her to make the appropriate change without changing his page or the Patroller page.

And finally, responding to one point of rpeh's, I don't remember wether it was a private e-mail or a posting here, but I clearly remember Elliot saying at some point that there was confusion in his mind around the <protect> tag policy, so at least on that point, I can back him up and hopefully reduce your scepticism. --Robin Hood (Talk • E-mail • Contribs) 18:06, 6 August 2009 (UTC)

The point is that the claim wasn't made at the time, but that's another matter.

I have no problem with the indicators being left. This wouldn't a removal of status, but a suspension. –rpeh^{•T•C•E•} 18:29, 6 August 2009 (UTC)

I share many other editors' concerns over Elliot's patrolling style. While this discussion seemed to wrap up rather quickly, I'd like to add a few comments.

Firstly, Elliot's right, everyone makes mistakes. My only request is that when someone points out those mistakes, the editor realize that it is an opportunity to improve themselves and the wiki, it is not someone "yelling at" them.

Next, I am rather concerned about the way he has thrown my name into this discussion, and the way I read his comments suggest a different conversation than the one that actually occurred. I have been in IRC regularly, and after he asked for feedback in the channel on several edits before deciding what to do about them, I told him that that was an improvement, and I was glad to see it; however, his comments seem to suggest that I think he's doing fine, and he is well aware that I do not. I have had numerous discussions with him since the referred-to conversation, all outlining my concerns.

Finally, his comment, "I never intended to take a malicious tone when I reply, it is just who I am naturally." I'm sorry, but that's a cop-out. When editing the wiki, you are not responding to someone face-to-face, where words can unfortunately come out before you think about the repercussions. You are typing, and so it is very simple to not make a post if you can't do it without it being abrasive and/or inappropriate. A few slip-ups, where an editor's "emotions" get the most of them I can understand... not condone, but understand; however, when multiple editors have brought concerns to a person about their patrolling style, it really is as simple as not making the post if you can't do it appropriately.

In summary, I agree with the outcome outlined above. Perhaps the suspension will help everyone, including Elliot, remember why he was nominated and elected in the first place. I also have no problem with the indicators staying in place. See y'all in a coupla weeks!  ;) --GK^Talk2me 19:09, 6 August 2009 (UTC)

Rpeh: Poor wording on my part. I meant that around the time of the protect tag incident, he'd indicated that there was confusion over policy, but that may have been in a private e-mail - I don't remember. --Robin Hood (Talk • E-mail • Contribs) 19:57, 6 August 2009 (UTC)

GK, I didn't just throw it around, and then there was a miscommunication on both of our parts. And I wish the regular editors would have talked to me through e-mail and whatnot, instead of having the administrators do it one by one. But that is beside the point.

Nephele, can you do this now? Thanks. –Elliot ^talk 18:47, 9 August 2009 (UTC)

I hadn't taken any action here yet for two reasons. First, it's taken me this long to finish typing up my feedback. Second, I didn't want to rush to take any action. Even now, less than a week has passed, and normally only actions necessary to prevent damage to the site are made so quickly. On the other hand, I don't think Elliot's return to normal status should be delayed either, especially since he clearly hasn't been doing any patrolling since this discussion was started. Therefore, I just changed Elliot's status, but I'm planning to restore his patroller rights in 11 days, i.e., two weeks after Elliot agreed to the temporary change.

In the meantime, I don't think the discussion should be considered closed, since there may well be community members who haven't even had a chance yet to see the discussion. Or others like me who take a while to collect their thoughts. Therefore, I'm hoping some of my slowly-typed feedback might still have some value.

Elliot has claimed that he's being singled out, and I agree that's probably true. However, inherently he's being singled out because of his value to the community. Elliot is currently one of the most influential editors on the site. Everything that I've read suggests that everyone wants Elliot to continue contributing. Furthermore, I think everyone sees the potential for Elliot's role on the site to continue to increase. For these reasons that Elliot's contributions have been noticed and other editors have invested time in providing feedback. If Elliot's contributions were insignificant, they would have been simply ignored -- it takes much less time! Furthermore, the only intention I've seen behind all of the discussions has been to help Elliot improve as an editor, so he can continue to contribute and do so even more effectively -- so he can learn from his mistakes, not make them disappear or atone for them.

However, being influential means mistakes are influential, too. "With great power comes great responsibility" (or some such cliche). Even if only 5% of Elliot's edits need improving, those 5% "stick out like a sore thumb" because of their effect, not their quantity. Over the last month, Elliot has probably been the single editor who has been most likely to influence new editors: his actions (reverting an edit, responding to a question) have directly affected new editors. Furthermore, because he is a patroller, his responses are likely to be seen as representative of the UESP community as a whole. Even if an edit only represents 5% of Elliot's edits for the day, it may represent 100% of another contributor's impression of our site. We only have one chance to make a first impression on any new editor. Which is, in my opinion, why certain edits made by Elliot have come under more scrutiny than many other edits.

It's clear from Elliot's overall record that he wants to welcome new editors to the site. However, these discussions have identified several situations where Elliot's edits have been more likely to have the opposite effect. I think the problem is one of relative priorities. Elliot apparently believes that the integrity of the site is the single highest priority. I disagree; if integrity were so important, the site would not be a wiki (the best way to maintain integrity is to prevent the site from being altered). Therefore, rushing to undo edits just to keep the site clean should not be a priority.

Rather, I believe the highest priority is the community of editors: without people who are interested in contributing to the site, it will stop being a wiki. Site integrity may suggest that a questionable edit should be undone as quickly as possible. However, respect for the contributor may instead suggest that it's better to leave the information in place for a day or a week -- in which case, I think the latter objective should take higher priority. Of course, obscenities and blatant vandalism need to be removed as quickly as possible, but for the majority of the edits made to the site, there will be no harm if they are seen by some readers. In the meantime, we can take the time to make sure we're responding properly to the edit, and to treat a new editor with respect -- assuming new information is correct unless you can prove otherwise (no matter who added the information); providing more detailed explanations if an editor didn't get the first explanation; making sure your actions (not just an anonymous welcome message) show new editors that they are welcome. In the end, the edit may still be undone, but perhaps after the contributor understands why it's being undone.

Finally, I have one concrete suggestion for Elliot, for now or for after his patroller privileges are restored: try waiting 24 hours to make any counter-responses. Some of you might think I fall back on the "wait 24 hour" suggestion too often; however, looking over the incidents that have been discussed, I really think waiting after the initial response would have prevented most of them. Elliot's initial undo or the initial response wasn't noteworthy; it was the subsequent, rapid exchange before anyone else could even respond. Therefore, Elliot, if someone re-instates an edit you undid, wait 24 hours to see what other editors think should be done. If someone doesn't like one of your responses, wait and see whether someone else can explain it better. Or ask someone else on IRC to look at the question/edit/response.

Simply giving time for other editors to get involved can make a huge difference -- for me, or any other patroller, just as much as Elliot. Sometimes an editor might simply not respond well to my style of feedback -- not because there's something inherently wrong with my style, but simply because we all have different personalities, and therefore sometimes two people get along right away and sometimes they don't. If an editor didn't like my response the first time, the chances are that editor simply won't like any response I provide; the editor may just need a different style of response or different perspective, which can be best provided by another patroller. Even if the editor isn't going to like anyone's response, hearing from multiple people ensures that the feedback is representative of the community, not just one individual.

--Nephele^Talk 06:26, 10 August 2009 (UTC)

Thanks Neph for the response. And trust me, I will try to utilize your advice. I admit that I like to rush things (I am extremely impatient a lot of the time), and I agree it is something that needs to be worked on. After some more thinking and time away from the computer/wiki, I will probably slowly come back and make more edits, and they will be better than ever. Thanks again, all! –Elliot ^talk 12:20, 10 August 2009 (UTC)

I think you should keep editing during this "time off". The whole idea is to remove the pressure of being a patroller so you can become more relaxed on the site again. That won't happen if you're not here. –rpeh^{•T•C•E•} 12:26, 10 August 2009 (UTC)

I plan to; I just haven't had enough time to focus in on myself. I'm still observing from outside the box. But don't worry, it won't be too long of a wait. Elliot ^talk 12:32, 10 August 2009 (UTC)

How do you know he's not Daedryon under a new ISP? 24.36.37.224 06:33, 12 August 2009 (UTC)

Well, how do you know? 24.36.37.224 06:52, 12 August 2009 (UTC)

(outdent) The Admins would be able to tell if it's someone in the same city as Daedryon, unless he's also managed to change cities or find an unknown proxy. Apart from that, the use of language isn't the same. --Robin Hood (Talk • E-mail • Contribs) 06:54, 12 August 2009 (UTC)

Well you might wanna look into this possibility, as I know that Daedryon is no longer in the same city, nay, province anymore. He's left for college in the states. The only problem I see with the possibility of Elliot being a sock of Daedryon is that Elliot is gay, but maybe Daed is just posing as someone else. 24.36.37.224 06:58, 12 August 2009 (UTC)

Also, your perceptions of peoples language is flawed. Anyone can change the way they speak or type. It's not hard to do. Cover all your bases. 24.36.37.224 07:04, 12 August 2009 (UTC)

Elliot isn't Daedryon, but since you share his ISP and location you could well be. You have also vandalised this page in a manner typical of Daedryon. Please don't do it again. –rpeh^{•T•C•E•} 07:07, 12 August 2009 (UTC)

Again, how do you know? I know Daedryon personally. He is no longer in Canada, having left to the United States for college.

Obviously I share is ISP and location, I've lived next door to him for the past 6 years or so, until recently when he left. And also, I saw that Daedryon did that whole Zalgo thing, so I thought I'd try it, and honestly...it's lame. Not all that fun. So yeah, I apologize for that.

But if I was you, I'd look into Elliot being Daedryon. Just because you say he isn't, Rpeh, doesn't make it so. You're just doing things half assed as an admin because you've gotten lazy. Snap back and do things properly. 24.36.37.224 07:10, 12 August 2009 (UTC)

Would that be the next-door neighbour mentioned on Daedryon's user page...the infamous vandal? I think we're quite capable of policing ourselves without the help of an anonymous editor who is likely either Daedryon himself or his next-door neighbour that everyone on other wikis believes is Daedryon. I think it's probably fair to assume, in light of rpeh's warning, that further edits to this thread will only result in the blocking of your IP address. --Robin Hood (Talk • E-mail • Contribs) 07:28, 12 August 2009 (UTC)

I wouldn't have blocked him for engaging in a sensible discussion, but he made the decision very easy with that post on your talk page.

I have many reasons for saying that Elliot isn't Daedryon, not least that Elliot has made hundreds of useful posts to this site while Daedryon's activities earned him one of the few perma-blocks we have for named accounts. If I choose not to share them with an offensive BoN, that's tough. –rpeh^{•T•C•E•} 07:55, 12 August 2009 (UTC)

(outdent) Yeah, that was a rather amusing post, wasn't it? What does "BoN" stand for? I've been trying to figure it out and I'm not getting anything. If it's not suitable for public posting, by all means, reply by e-mail. :) --Robin Hood (Talk • E-mail • Contribs) 21:17, 12 August 2009 (UTC)

"BoN" = "Bunch of Numbers". Just another way of describing an anon. –rpeh^{•T•C•E•} 21:53, 12 August 2009 (UTC)

Ah, got it! Thanks. --Robin Hood (Talk • E-mail • Contribs) 22:46, 12 August 2009 (UTC)

[edit] Several days later

Now that that Elliot's patroller permissions have been reinstated we should continue on this. What are our opinions on it, what does Elliot have to say and what is the commmunity's final decision.

I hate to say it, but I'm disappointed with the results of this entire set of events. I'm not really talking about Elliot in this case. He has made less edits than usual, and seems to have avoided some of the more difficult edits. Which I think worked in his favor. I refer to how these 11 days (not 2 weeks, as I was surprised to learn) have not really been enough to make a good final decision.
Past week few people seem to have been really around to make it seem they have been paying attention to Elliot. Now it's perfectly understandable if you're away for a week, but if you had a strong say about this matter, and then not be around when the actual thing happens I find it strange. Were these days not just a waste of time, and unecessary hindrance for Elliot? Sure we may have been trying to cool down, but you don't cool down by totally avoiding the conflict. I was really under the impression that we could have used this time to work with Elliot in a way we learned to appreciate his good sides again, while Elliot could notice we have not criticised his person, but rather some elements of his patrolling style. Simply avoiding each other simply won't work.

So it comes down to this, has this really helped the case forward? --Timenn-<talk> 20:52, 22 August 2009 (UTC)

Yeah, I actually found/find myself calmer than ever. It was 11 days because I stopped patrolling three days before Nephele enacted the decision. I don't what else there is to say, but I know taking a break from patrolling definitely helped. –Elliot ^talk 21:04, 22 August 2009 (UTC)

Looks to me like he totally misunderstood the idea of the thing by staying away. But not having him around for two weeks definitely improved the wiki. Now we're back to the usual opinion-based deletions made with no checking. Just in the last few hours we've had this and this. How Elliot ever got made a patroller in the first place I really don't know. 94.136.16.242 03:20, 23 August 2009 (UTC)

Both of those examples are provided out of context. The first edit, despite the somewhat opinionated summary, removed an edit that did not conform to the style guide. The second edit was done after the anon who posted it origionally created an account to discuss the issue (their actual comment can be seen here), at which point Elliot placed it back on the article in a manner which conforms to the general wiki style. Shortly thereafter, the User KFM updated his talk page with this, proving that the edit was unnecessary. Eliot then removed the information again. I fail to see how those examples can be considered overly opinionated, nor do I see any evidence that Elliot failed to check the information. -Dlarsh^{(Talk,Contribs)} 03:43, 23 August 2009 (UTC)

I agree — both edits look fine to me. —Robin Hood ^{(Talk • E-mail • Contribs)} 04:00, 23 August 2009 (UTC)

And 94.136.16.242 has been banned for being an open proxy and probable troll. --Ratwar 04:07, 23 August 2009 (UTC)

I was not very active during the original discussion (I only discovered it after the whole Elliot/Daedryon discussion), but I understand Timenn's point. Now it does seem to look like we continue on like the whole matter didn't take place. But I do think this has helped the case forward. First, Elliot himself concludes that it really helped him, which is important. Secondly, Elliot seems to realize his sometimes hasty reverts, and makes up for it by adding it again. Therefore, this break, I think, has helped Elliot and the site. However, 3 days (I don't know exactly when Elliot officially became a patroller again) might not be enough to judge that yet. Wolok gro-Barok->T->C->E 10:38, 23 August 2009 (UTC)

[edit] UESP E-Mail Server

I've finally got around to setting up the e-mail on content3.uesp.net. If anyone (admins, patrollers, or active editors) wants a uesp.net email (i.e., dave@uesp.net) just let me know. There is a web interface at webmail.uesp.net and it supports the POP interface (can't send mails through it yet).

[edit] Template Protection

I just added semi protection to a few templates and was looking further down the list to see if there were any others that should probably be protected. Given that (currently), even an important template like Template:Place Summary is way down in 50th place on the Most Linked Templates list... wouldn't it just be easier to stop anon edits on all templates?

I'm still not sure which way I'd go if there was a vote on disallowing anon edits to everything, but surely with templates that are used on hundreds of pages at a time, it would be a good idea to stop just anybody editing? It it possible to add semi-protection to an entire namespace, and are there any reasons why it shouldn't be done? –rpeh^{•T•C•E•} 15:04, 9 August 2009 (UTC)

Protecting namespaces can be setup in the wiki's config via the $wgNamespaceProtection setting. Currently only the MediaWiki namespace is protected this way. I can't think of any good reason why Template shouldn't be protected from anonymous edits. -- Daveh 15:30, 9 August 2009 (UTC)

Except protecting the entire namespace would mean that /Doc subpages would get protected, too, even though one of the reasons for separating the /Doc content is to make it easier for anyone to improve the documentation, fix categories, etc. Furthermore, new templates shouldn't need to be created that often (especially once we fix the trail template insanity), so it's not as if adding protection manually is a daily task. Finally, we haven't had too many problems with anon edits of templates -- in fact, IIRC, we started template protection in part because editing templates used to have a DoS-type effect, but since we fixed the job rate, that's no longer an issue. So I think protecting the whole namespace would be overkill. --Nephele^Talk 16:35, 9 August 2009 (UTC)

I take the point, but turn it around: the only reason it's a problem is if a brand new editor wants to edit a template but can't wait 7 (?) days yet it's not important enough to mention somewhere else. In other words: why would an anon ever need to edit a template? –rpeh^{•T•C•E•} 16:58, 9 August 2009 (UTC)

Actually, having thought about it... I don't even accept the point. Why would an anonymous edit want to edit our template documentation? Any edit somebody wants to suggest can be made on a talk page. The change to sub-pages for documentation was made for performance reasons anyway; not permissions. I simply cannot see any reason why we should let anons edit templates. –rpeh^{•T•C•E•} 17:04, 9 August 2009 (UTC)

But why not ask the reverse? Why is it needed that we block anonymous user from editing the templates? Nephele mentions that templates are less vulnerable than they used to be, and even then, how many times were they vandalised?

In the end it will make little difference, I think. In that case it would be best to have as few protected pages as possible, to promote the openness of the wiki. --Timenn-<talk> 19:02, 9 August 2009 (UTC)

I don't like protecting too many pages either, but there's a difference between a template and a content page. If somebody vandalises a content page, just that one page is vandalized. If somebody vandalizes the NewLine template, over 2,000 pages are vandalized. Protecting the namespace would just be easier than protecting individual templates, which I still think we ought to do. Or am I being paranoid? –rpeh^{•T•C•E•} 07:23, 10 August 2009 (UTC)

[edit] Edit Notices

One thing added by the latest upgrade is configurable page edit notices (second one in that section). The idea is that one can add warnings when somebody edits a namespace or even a page, although my quick tests couldn't get the page stuff working.

I wondered what people thought about adding warnings to the User namespace asking people not to edit pages other than their own, or to sign in if required; and to Mainspace suggesting that people are probably creating information in the wrong namespace. We might, in the future, want to look at adding a notice to other namespaces (probably just OB) asking people not to create TESV pages there. Another suggestion would be to add something to the Help namespace telling people that it's not the right place to ask for help.

This will create an extra note (box, probably, or it won't be seen) at the top of each affected page, which could be annoying, but it might be helpful to new users in that they would be less likely to edit incorrectly, and to established users in that they would have less to clean up.

Thoughts? –rpeh^{•T•C•E•} 18:20, 15 August 2009 (UTC)

I think it's worth pursuing. Unfortunately with user pages it doesn't seem possible to do a test such as {{#ifeq:{{USER}}|{{BASEPAGENAME}}|...}} (although there's probably an extension somewhere that adds a variable like USER... if someone's willing to dig around), which could make the message especially useful.

However, we also need to keep in mind existing notices at talkpagetext and anoneditwarning (and possibly others), to try to avoid redundancy or message overkill, and also try to maintain some consistency in format, etc.

(I'm guessing your 2nd and 3rd tests didn't work because it's supposed to be "Editnotice" not "EditNotice". From the code, it looks like "Editnotice-2-Rpeh" should be the correct name. While I'm in the code, one other obscure little feature is that for a page such as "Tes3Mod:Tamriel Rebuilt/Book X/Author", it will look for an edit notice at Editnotice-122-Tamriel_Rebuilt, Editnotice-122-Tamriel_Rebuilt-Book_X, then Editnotice-122-Tamriel_Rebuilt-Book_X-Author, and display any or all that are found (note "-" not "/" as separators). So an edit notice will target an entire set of subpages.) --Nephele^Talk 22:13, 15 August 2009 (UTC)

[edit] Image prods

Elliot has {{prod}}'d some images that were recently uploaded by ACGrecor to fill out this page. I agree completely, the images are below the quality we would want, but at the same time, I feel that something is better than nothing. So basically, I don't object enough to remove all the {{prod}} tags and revert the page, but at the same time, I feel I should voice some objection before they get deleted and ask for a second opinion on whether we're better off with poor images or no images. So this is me doing just that. :) Can an Admin please make a decision on this one? Thanks! --Robin Hood (Talk • E-mail • Contribs) 03:39, 17 August 2009 (UTC)

Call me a "deletionist", but I think there should be a minimum standard for "initial" images to include on the wiki (as in, temporary placeholders until something better is provided). I mean, the images basically broke every rule (suggestion?) provided on the Help:Images page. Yeah, we can have some lack-luster images, but these images detract way more than add, in my opinion. Also, this would have to be brought up on a Deletion Review if someone else objects. –Elliot ^talk 03:48, 17 August 2009 (UTC)

It doesn't need an admin. The images are not very good but at least they are better than nothing. 94.76.246.74 08:01, 17 August 2009 (UTC)

I'm with Elliot on this one. We hold text based edits/additions to a higher standard on main articles, so why shouldn't we do the same for images? A poor quality image detracts more from an article than simply having no image at all in my opinion. I see it along the same lines as a section of text that uses the first person in that even though they are trying to add something pertinent to the article, it just makes it look less professional than it did before. -Dlarsh^{(Talk,Contribs)} 18:55, 17 August 2009 (UTC)

Well, Elliot has said elsewhere that he'll write it up on Deletion Review since there's clearly conflicting viewpoints here, so once he's done that, we can all move this chat over there. :) --Robin Hood (Talk • E-mail • Contribs) 04:25, 18 August 2009 (UTC)

At the current moment, I am waiting to see if Timenn plans on getting better pictures for them in the near future. He has stated that he plans for it (see User talk:Timenn#Images). So as of now, the DR is on hold. –Elliot ^talk 04:30, 18 August 2009 (UTC)

Oh, sorry, I was only skimming and must've missed that. --Robin Hood (Talk • E-mail • Contribs) 04:48, 18 August 2009 (UTC)

[edit] Suggestion

With the recent nonsense going on in the account creation, I was wondering if installing ConfirmAccount would be too much? I think that with CA and Oversight, the wiki should be pretty safe. We could also remove CA after awhile until some things chill off. Also, perhaps placing Administrator's, Patroller's, and established user's usernames in the blacklist could help. Thoughts? –Elliot ^talk 02:56, 19 August 2009 (UTC)

Or as a less extensive solution, this could be used. –Elliot ^talk 03:00, 19 August 2009 (UTC)

How involved would this bureaucracy be? I'm all for preventing offensive user names, but this is a public site that focuses strongly on the community. If something like this is implemented, what sort of delays would there be for new users who truly want to help? I realise that something like this will be disscused at length, but I just thought I'd bring these concerns/thoughts up now. Also, a possible alternative, would there be some way to block certain keywords from being used? I don't know much about programming, and I do know that there are always workarounds, but something like that plus the second option Elliot mentions (preventing the same IP from creating multiple accounts) would, I think, at least cut down on inappropriate account creations. Oh, one other question. Would the second option affect the creation of sandboxes since they are part of the User namespace? Again, I know next to nothing about programming so I appologise if these questions are pointless in the context of this issue. -Dlarsh^{(Talk,Contribs)} 03:16, 19 August 2009 (UTC)

The ConfirmAccount can be used by whoever is set up to use it (bureaucrats, admins, patrollers, etc.), so you shouldn't have to worry about waiting (we could even have some special members use it); I just think this recent activity is a problem especially considering the content of the usernames. There is something called a blacklist that we use to prevent certain words in a username (such as Arch Mage, Gray Fox, etc.). No, the sandboxes wont be affected, since they are for account creation only. –Elliot ^talk 03:22, 19 August 2009 (UTC)

I'm not sure about ConfirmAccount. I share the above concerns about it being an obstacle for legitimate users. Also to the extent that this vandal simply wants to flood the logs with obscenities (and not actually use the accounts), I'm not sure it would be effective, in that the offensive names would still be logged. Blacklisting might be worth investigating, although probably still not effective in this situation (he'd just change one or two letters).

I have gone ahead and set $wgAccountCreationThrottle to 1 -- meaning only one account can be created from a given IP in 24 hours. I'll change the setting if that's the outcome of this discussion, but in the meantime putting some type of limit in place seems prudent as an emergency measure. --Nephele^Talk 05:31, 19 August 2009 (UTC)

[edit] Deleted Logs

I just took the liberty of deleting the entries detailing the account creations, blocks, and renames from the recent changes log and the activity log. In particular, I think that the main goal this vandal wants to accomplish is to add offensive nonsense to the recent changes page in the hopes that the nonsense then cannot be removed. Therefore, clearing out the information from the logs is likely to be the best way to thwart the vandal. Note that all I've done is remove the log entries -- the blocks are still in place, and the accounts still technically exist (although I'm also going to rename them all). Also I've dumped the sql of the logs so that if it's decided that the information should be restored, I can do it.

I'll look into other options for dealing with this, including the above suggestions. I just wanted to post this information first to explain why the evidence all suddenly vanished. --Nephele^Talk 04:02, 19 August 2009 (UTC)

I'm glad to see that they could be taken away! But there are two more in the account creation log dated at 06:00, August 17, 2009. Just a heads up! –Elliot ^talk 04:16, 19 August 2009 (UTC)

I'm already working on them. --Nephele^Talk 04:25, 19 August 2009 (UTC)

Okay, cool. Just letting you know. Nephele, I swear you have special powers or something. –Elliot ^talk 04:29, 19 August 2009 (UTC)

[edit] Vandal notice

Following the advice listed here, I would like to bring the anon editor 71.239.161.45, to the administrators' attention. All three of this User's edits at the time of this post have been disruptive to the site (1;2;3) and in the edit sumary for the third example, the User asks to be banned. Given their reaction to warnings, I feel that stricter action on the part of the site is required. -Dlarsh^{(Talk,Contribs)} 19:36, 24 August 2009 (UTC)

Thanks. User has received a one-week block. --Timenn-<talk> 20:23, 24 August 2009 (UTC)

[edit] Complaint about a personal attack

As you can see on my talk page, a troll by the name of Priam is flaming me. In fact, he used the exact words "fucking idiot" to describe me.

If you would be so kind as to send the Troll Patrol over there and settle this, I would be quite grateful.Dstebbins 21:03, 27 August 2009 (UTC)

I believe the acute situation has been settled. Priam seemed insistent on his insulting behaviour, resulting in an indefinite block. --Timenn-<talk> 21:53, 27 August 2009 (UTC)