Open main menu

UESPWiki β

UESPWiki:Administrator Noticeboard/Archive 29

< UESPWiki:Administrator Noticeboard
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.

Wiki Upgrade -- Three Times the Charm

Work slowly progresses towards another attempt at upgrading the wiki to v1.19. I've got another set of changes to test but the main issue is that I cannot replicate the previous issues. I've tried load testing an upgrade like crazy but it never shows the same issue. What I'm thinking of doing is instead of a complete upgrade attempt which turns the wiki read-only for a few hours in addition to some possible down time if it fails is to first deploy the change to one content server and see if the same issue shows up again.

The downside of this is that some people will see an "old" version of a page in the 1.19 wiki. This shouldn't affect anonymous users much, if at all, but editors may be confused by having essentially two different wikis which may appear randomly. The effect will be temporary (under an hour, less if the same issue appears) before I revert top normal behaviour. I'm aiming to try this test tomorrow evening (I'll post an update here).

If this appears to work I'll try another full upgrade attempt this Saturday, although that may be optimistic. If it doesn't work I'll continue more tests to find and solve the issue. -- Daveh 23:52, 20 August 2012 (UTC)

I was wondering if perhaps it was a specific type of edit that either causes or at least triggers the problem, something like a file upload or something that uses a specific extension or whatever. Just something to keep in mind during load testing, if you haven't thought of it already. It would be interesting also to review the edits that were done on 1.19 (if you have any backups of the edits) and see if anything stands out. – Robin Hood↝talk 01:58, 21 August 2012 (UTC)
I think it is just a misbehaving piece of MediaWiki code (LocalisationUpdate) that tries to delete a table a few hundred times from all the concurrent users which causes the database to lock up. There is a setting to use the file system instead of the database for this sub-system which, in theory, should avoid this whole mess. Testing out that theory is another matter. -- Daveh 03:01, 21 August 2012 (UTC)
If you're referring to Extension:LocalisationUpdate, could we perhaps just not install the extension? If not, where's the file you're looking at...I was curious, but I couldn't find anything in the PHP code, so I'm guessing you meant the extension. – Robin Hood↝talk 06:10, 21 August 2012 (UTC)

There is a lost edit here detailing what I was going to do before breaking the site. That issue changed my plans a bit so no upgrade or tests are planned in the near future...at least until I can figure out a way of doing it without breaking anything in the process. -- Daveh 23:39, 21 August 2012 (UTC)

Update -- Another upgrade attempt will be happening on the morning of Monday, September 3. This will be like the other upgrades where the wiki will be locked for around 2 hours while the upgrade is taking place. I think we have a better chance of succeeding this time baring other issues that crop up. -- Daveh 14:19, 2 September 2012 (UTC)

So far so good. Everything should be running on MediaWiki v1.19 and the previous issue hasn't shown up yet. There are no doubt small issues here and there which will need to be addressed and list anything you notice below. -- Daveh (talk) 11:08, 3 September 2012 (EDT)
Test content1 edit... -- Daveh (talk) 11:09, 3 September 2012 (EDT)
Test content3 edit... -- Daveh (talk) 11:11, 3 September 2012 (EDT)
Fixed Issues
  • The Save button in Preferences is too tall. – Robin Hood↝talk 11:43, 3 September 2012 (EDT)
  • Fixed although it may take a while or a forced reset of the user side cache to update (a forced reload worked once for me but not on subsequent edits). I'll double check again in a few days. --Daveh (talk) 15:13, 3 September 2012 (EDT)
  • Bullets are smaller, square, and no longer blue. – Robin Hood↝talk 11:43, 3 September 2012 (EDT)
They were always square for me. But yeah, the color has changed. Not sure if they're actually smaller though. TheRealLurlock (talk) 11:51, 3 September 2012 (EDT)
The bullet and other missing images have been fixed. Something to do with the wiki trying to access them on the wrong path (accessing in /w but they were in /w/skins/monobook). Just copied them into /w for now. -- Daveh (talk) 17:40, 3 September 2012 (EDT)
  • Clock gadget's click-to-purge function no longer works. – Robin Hood↝talk 12:00, 3 September 2012 (EDT)
Clock js code was just updated which appears to fix this issue as well the clock not displaying properly. -- Daveh (talk) 14:17, 3 September 2012 (EDT)
  • Everyone's preferences appear to have reverted to their default configuration. I'm going to guess this was a necessary loss with the upgrade, and the easiest fix is to just return them to the way you like them. Just putting this here as an FYI. --AKB Talk Cont Mail 12:02, 3 September 2012 (EDT)
  • Is it all preferences or just the search ones? I know the search ones were reset as the custom code Nephele added didn't make the upgrade for some reason I forgot (will have to add it back later). I can't tell if any other of my preferences were reset or not. -- Daveh (talk) 14:14, 3 September 2012 (EDT)
  • All preferences, even my updated email have reverted, custom signatures too. The Silencer (talk) 14:16, 3 September 2012 (EDT)
  • Also, HotCat and purge had been disabled. HotCat works after enabling it again, purge doesn't seem to work yet also works. --Holomay (talk) 14:39, 3 September 2012 (EDT)
  • The Gadget, Change UTC-based times and dates, to be relative to local time. doesn't seem to be working anymore. The Silencer (talk) 14:42, 3 September 2012 (EDT)
  • Updated the "local time" gadget which appears to be working. If you find any other gadget that doesn't work just let me know. The gadget code is stored in the database and isn't updated along with the wiki. -- Daveh (talk) 15:19, 3 September 2012 (EDT)
  • Text within <code> tags are no longer small, and appear to be rendering in a different font. This is an example Jak Atackka (talk) 15:41, 3 September 2012 (EDT)
Are you using Chrome by any chance? Code appearing small was an irritating problem with Chrome that didn't appear in other browsers, so this may actually be a fix for Chrome, not a bug. – Robin Hood↝talk 16:08, 3 September 2012 (EDT)
Nope, I'm using Safari. I just checked, and the <code> tags appear incorrectly in Safari, Chrome, Opera, and multiple versions of Firefox. • JAT 16:58, 3 September 2012 (EDT)
Okay, just as a point of comparison, what do you see here
Say hi, Jak!
vs. the same code on Wikipedia? Other than a slight background colour difference, they look the same to me, which is how they looked in most browsers prior to the upgrade. – Robin Hood↝talk 17:12, 3 September 2012 (EDT)
Old code tags looked like this, whereas new code tags look like this • JAT 18:10, 3 September 2012 (EDT)
  • Also, I cannot load my watchlist, and through IRC, Lord Eydvar confirmed the same issue while Eric Snowmane says his works fine. — ABCface◥ 23:38, 3 September 2012 (EDT)
    • Just checked my watchlist using "content1" instead of "www" at the start and it works, but still won't work on the "www" version no matter where I try to access it from (via the links at the top of the page, the Special Pages page from the toolbar, my bookmark, or typing it in manually). — ABCface◥ 23:46, 3 September 2012 (EDT)
      • I just had a blank white page for about 10 seconds or so trying to load the CP (which was very slow to load overall). I got pulled away for a bit, and when I got back, it was loaded. Perhaps there's just some really long lag at times? For the Orphaned Pages, I'm getting a 500 error, though. – Robin Hood↝talk 18:27, 4 September 2012 (EDT)
        • That wasn't the case for me when it happened, as I left the tab open for over 30 minutes at one point and it still never loaded. However, this seems to be resolved now, as it loads every time for me in any way I try it. — ABCface◥ 16:44, 5 September 2012 (EDT)
  • I'm having intermittent troubles patrolling edits. The same edit will consistently be unpatrollable for me even though others are fine. I handed one of the unpatrollables off to Jak and he was able to patrol it just fine. – Robin Hood↝talk 17:54, 3 September 2012 (EDT)
  • There have been lag spikes on the servers whenever I make a change to the wiki settings. I've been manually restarting the Apache servers after each change to try and mitigate the spike. I'm unsure if this would be the cause of this issue or not. I'll not be making any more changes for another hour so see if the issue persists. -- Daveh (talk) 18:33, 3 September 2012 (EDT)
  • I'm not sure if this is entirely an upgrade issue, but Content1 and 2 are both showing abnormally high CPU readings—50-60% at every reading I've done over the last 10 minutes. I know 1.19 is much more server-intensive than 1.14 was, but that still seems awfully high. – Robin Hood↝talk 19:45, 3 September 2012 (EDT)
  • They have indeed been working harder due to the upgrade. Note that the 50% is for one CPU and all the content servers have 4 CPUs so we've still got a lot of extra power just not as much as before. It could, in part, be the wiki working extra hard since I've been invalidating the page cache all day in which case it will settle down in a day or two. There may also be some new settings I haven't set up yet which could help reduce the load. This is the exact same issue we had the first two upgrade attempts where I was missing a "magic" setting that fixed it. The MediaWiki documentation is very poor to non-existent for high traffic Wikis like ours unfortunately. -- Daveh (talk) 19:59, 3 September 2012 (EDT)
  • Actually, I realized another reason of the increased load is due to the change in design. MediaWiki now loads all CSS and JS files through load.php which means that for each page load there may be a half-dozen or more extra file requests through Apache. In the previous version some of these requests were static files served through files1/skins/images.uesp.net. -- Daveh (talk) 20:17, 3 September 2012 (EDT)
  • Another reason for the increased load is that the Squid cache isn't working as well as it was before the update (70% hit rate now compared to 85% last week which would double the page views seen by the content servers). It seems this is due to a max-age=0 HTML header which is something I fixed in v1.14 and will have to refix in v1.19 apparently. -- Daveh (talk) 21:53, 4 September 2012 (EDT)
  • Update -- Since the change a day or two ago that lets the Squid properly cache pages the load on the content servers is back to almost where it was pre-upgrade. -- Daveh (talk) 21:22, 6 September 2012 (EDT)
  • This may be a MediaWiki change or bug, but the Patrol Log is showing the original editor as being the patroller rather than the patroller themselves. For example, I just patrolled this edit, but Sharlikran shows up as the "patroller" in the log. – Robin Hood↝talk 23:51, 3 September 2012 (EDT)
  • After quite a bit of searching, I found a Bugzilla report on it. It sounds like it's not yet fixed in 1.19.1, but there are some details on the fix in the messages. Looking around patrolled MediaWiki sites, I see no evidence of a problem, so maybe it made it into 1.20, but there's no evidence of it being in 1.19.2, so I think you'll have to make the change by-hand. – Robin Hood↝talk 00:46, 4 September 2012 (EDT)
  • I've merged this bug fix into our wiki manually and it seems to work but double-check and let me know if it doesn't. -- Daveh (talk) 21:10, 4 September 2012 (EDT)
  • Yup, that's got it. There's another bug, where it doesn't show autopatrolled edits as such, but that's just a display bug and it's been resolved in one of the 1.19 updates or maybe 1.20. (Autopatrols show up as expected in the API, for instance.) I don't have any details on the source of the bug, so unless you have some overwhelming urge to track it down and fix it, I think that can wait. I'm just mentioning it in case anybody notices that things aren't quite back to normal. – Robin Hood↝talk 21:37, 4 September 2012 (EDT)
  • Gadgets as a whole have disappeared, the whole section has gone from the preferences, plus manually purging a page no longer works, at least up to patroller status (Jak Atackka checked). The Silencer (talk) 03:56, 5 September 2012 (EDT)
I can purge, as long as I add it manually to the URL. – Robin Hood↝talk 13:44, 5 September 2012 (EDT)
Gadgets still work on content3. I can't fathom to guess why it's not working on the others without some additional research, but if you need your gadgets just replace "www" with "content3". --AKB Talk Cont Mail 14:24, 5 September 2012 (EDT)
A strange one for sure...apparently using $wgMainCacheType = CACHE_MEMCACHED; causes the gadgets to not work. I think one of the other settings changes caused this to appear although exactly which one I don't know. There may also be a bug in the MetaTemplate/CustomCode extensions that is causing it. I've change the setting for now to permit the gadgets to function while I investigate. -- Daveh (talk) 20:17, 5 September 2012 (EDT)
  • All post times are now in EDT instead of UTC. – Robin Hood↝talk 15:27, 6 September 2012 (EDT)
  • Fixed: Default time zone for anonymous users is GMT/UTC. Logged in users can change their time zone in their preferences and use a gadget to convert most displayed times to their local time zone. -- Daveh (talk) 00:00, 12 September 2012 (GMT)
  • Right above the edit summary, the explanation for what you're supposed to put in your edit summary seems to be suffering from some broken code. It's currently appearing as "<a href="http://uesp.net/wiki/Help:Edit_Summary" title="Briefly describe the changes you have made here">Edit summary</a>". Also, almost all of the tables have become discolored from what I've seen. I'm not aware if this was a planned update or a consequence of it, however. --Alpha Kenny Buddy (talk) 11:19, 3 September 2012 (EDT)
There are no planned design changes so anything you find different is most likely a bug or accident omission. -- Daveh (talk) 11:35, 3 September 2012 (EDT)
I recall reading that customizing table formatting is a bit different (and I think harder) in 1.19, but I don't remember the specifics. I'll see what I can find. – Robin Hood↝talk 11:43, 3 September 2012 (EDT)
For the edit summary issue, I believe we'll have to revert to Aristeo's first attempt at MediaWiki:Summary and lose the custom hover text. – Robin Hood↝talk 12:24, 3 September 2012 (EDT)
I've done some reading up on this, and I believe it might be this bug. --AKB Talk Cont Mail 12:45, 3 September 2012 (EDT)
I've changed the message text to use wiki markup as it appears from the bug report that not rendering HTML is on purpose since v1.16. -- Daveh (talk) 14:10, 3 September 2012 (EDT)
Now it's stretched across the screen for those of us who view the wiki with justified paragraphs. See Wikipedia:MediaWiki:Summary for the fix. – Robin Hood↝talk 14:27, 3 September 2012 (EDT)
Try it now (should be same as Wikipedia's). -- Daveh (talk) 14:42, 3 September 2012 (EDT)
(←) Apparently that didn't fix it, but I just noticed it's the same at Wikipedia. I don't know if changing it to a div would work or if it would just break the formatting. If not, don't worry about it for now...it's minor. – Robin Hood↝talk 14:52, 3 September 2012 (EDT)
What happens if you use this code? <span style="text-align: left;" title="Briefly describe the changes you have made">[[Help:Edit Summary|Edit summary]]</span> Jak Atackka (talk) 15:41, 3 September 2012 (EDT)
Jak: I suspect that wouldn't make a difference, as it's almost identical to what's there now. – Robin Hood↝talk 16:06, 3 September 2012 (EDT)
The difference, though, is that it would have the correct text when you hover over the link, which is what we're trying to get (unless I missed something). • JAT 16:58, 3 September 2012 (EDT)
Doesn't work. When you hover over the link, all you see is "Help:Edit summary" (or at least that's what I see). – Robin Hood↝talk 17:12, 3 September 2012 (EDT)
(separate suggestion refactored out during archiving) – Robin Hood↝talk 22:11, 16 September 2012 (GMT)
(←) In terms of the justification, I added a #editform entry to my Common.css that fixes a couple of different issues, including this one. Also, I believe my Common.css file can be copied verbatim to MediaWiki space. I took out the obvious Monobook-specific code (i.e., stuff that was copied verbatim from 1.14's default main.css file), but left our customizations in. We should probably go over it to split off any lingering Monobook-specific code at some point, but I believe Monobook is what most of us are currently using anyway atm, so I don't see that as a priority. – Robin Hood↝talk 16:16, 7 September 2012 (EDT)
  • {{showhide}}, which is used on my userpage and Deletion Review among other places is no longer showing me the "Show/hide" link on the side. Not sure if it's related to this, but it doesn't hurt to throw it out on the table. Snowmane(talk•email) 13:38, 3 September 2012 (EDT)
  • Something to do with the JavaScript code not being included in the new version. My first attempt to copy it over failed and I'll look at it in more detail to see what's going on. -- Daveh (talk) 14:43, 3 September 2012 (EDT)
  • This can be fixed by adding a line "addOnloadHook(createNavigationBarToggleButton);" to Common.js, works for me at User:Alfwyn/monobook.js. --Alfwyn (talk) 19:50, 9 September 2012 (EDT)
  • Until this is resolved, I've made hidden text show by default. We can revert the template changes once the site javascript has been updated. Some pages may need purged or null-edited in order to show the changes. – Robin Hood↝talk 17:52, 11 September 2012 (EDT)
  • Okay, a bunch of us ganged up on Dwarfmp and made him change Common.js, so Showhide should now be working. It might require a hard refresh or restarting your browser. – Robin Hood↝talk 19:37, 11 September 2012 (EDT)
  • In regards to table formatting (separating this out so it's easier to find), the style used in common/shared.css is such that it takes precedence over what we currently have in MediaWiki:Common.css. Adding a bunch of !important flags (as done in this edit) seems to work, but I'm still looking to see if that's the preferred method. Also, see Mediawikiwiki:MediaWiki_1.19 and search for "wikitable"...sounds like maybe we should be copying the style from shared.css into MediaWiki:Common.css and then adjusting. Not sure if I'm reading that right, they're not exactly forthcoming with specifics. – Robin Hood↝talk 16:14, 3 September 2012 (EDT)
  • Okay, to skin our tables, it seems that this is the preferred style, as it will cascade down properly to subtables. There are a couple of unrelated edits in there, so to be clear, the various wikitable entries we have in MediaWiki:Common.css should be removed, and replaced by the wikitable entries I've added at the top of my CSS file. Any admin can do this. – Robin Hood↝talk 14:16, 5 September 2012 (EDT)
  • Thumbnail creation of images sometimes fails when looking at an image in the File namespace. An example where it fails for is File:SR-item-Gold_Ingot.jpg. Instead of the image, it shows the following error message: Error creating thumbnail: convert: Output file write error --- out of disk space? `/tmp/transform_4d40987-1.jpg'.. Both the large image at the top and the small image in the upload history fail. -CoolGamer (talk) 10:15, 8 September 2012 (EDT)
I had the same issue 2 days ago. Clearing the cache (ctrl+F5) for the file page solved it for me. --Xyzzy Talk 10:41, 8 September 2012 (EDT)
I've tried that, but it didn't help. After a refresh the filename in the error message changes, so this isn't related to the local cache. -CoolGamer (talk) 10:44, 8 September 2012 (EDT)
I used the purge tab and the error remains. This one is more presistent then when I experienced it. --Xyzzy Talk 10:57, 8 September 2012 (EDT)
I am now seeing this error on the page for wheat. However, the image will show up here if I link it. --Xyzzy Talk 11:09, 8 September 2012 (EDT)
  • I'm also unable to upload new images. It gives me the following error when trying to upload an image: The file you uploaded seems to be empty. This might be due to a typo in the filename. Please check whether you really want to upload this file.. Tried multiple images. I think it is related to the thumbnail problem. It really looks that the disk is full. -CoolGamer (talk) 11:46, 8 September 2012 (EDT)
I also had this uploading problem at the same time as the thumbnail error. Eventually, they both cleared up for me. --Xyzzy Talk 11:52, 8 September 2012 (EDT)
I've had this issue before the upgrade. I think resaving and reuploading the file worked. Vely►t►e 11:55, 8 September 2012 (EDT)
Both I and Kunvulonin are also getting this issue. As reported in the issue above, the thumbnail also sometimes appears or doesn't, but uploading always fails for me, regardless of whether the thumbnail appears. I tried jpg, png, and zip files, just to be sure, but nothing worked. – Robin Hood↝talk 16:10, 8 September 2012 (EDT)
It should be good now unless there are other uploading issues. The temp space on content1/2 filled up with new files related to images and thumbnail creation which prevented things from working correctly. I'll have to figure out a way of preventing this from reoccurring. -- Daveh (talk) 17:10, 8 September 2012 (EDT)
  • copied from Template_talk:Rotate: I think this may have been caused by the upgrade to the wiki, but since this template isn't quite used, no one realised that it's not working after the upgrade. Well, it just so happened that I was editing my Delphine wipsandbox today. One of my tables uses this template, and I noticed that nothing is rotated. So... hope someone will fix this. Thanks :3 ~ Psylocke 16:15, 14 September 2012 (GMT)
I believe I've fixed the problems in most cases, but I had to make a few changes to the template, as documented on its talk page. For the most part, it seems to work fine, but there was clearly at least one instance where changes to the template call were necessary. The template is Jak's baby, so I'll let him figure out if there are additional changes that should be made. If anything's not work, just post here and one of us will take a look at it. – Robin Hood↝talk 20:15, 14 September 2012 (GMT)
  • It seems to be impossible to view more than the first 200 entries of a category. A forum user reported this, and after trying it myself I was immediately able to replicate the problem. Try hitting the "next 200" button on this category, or any that have more than 200 pages in them. --AKB Talk Cont Mail 14:26, 6 September 2012 (EDT)
I found a report on this on MediaWiki, and the user there reported that updating CategoryTree fixed the problem. – Robin Hood↝talk 15:37, 6 September 2012 (EDT)
Possibly related issue - the sorting on some image categories seems to be off. Unless someone can figure out some other reason why in Category:Skyrim-Icons-Armor, the Shield of Ysgramor icon is listed first. Not the only place I've seen issues like that. TheRealLurlock (talk) 14:26, 29 September 2012 (GMT)
This isn't unique to that category and icon. The same sorting issue occurs in other categories as well, such as Category:Skyrim-Ingredients (see H and T lists, I think there's a couple others as well). — ABCface◥ 14:29, 29 September 2012 (GMT)
Dave: it may be useful to run updateCollation.php --force and see if that fixes the sorting issue. – Robin Hood↝talk 19:01, 29 September 2012 (GMT)
Sorry to scratch yours out, but it's already been reported above. It's an awkward workaround, but if you change the "pagefrom" in the URL to simply "from" after you've clicked on it, you'll get somewhere in the right neighbourhood. I believe "from" only pays attention to the first letter, but that should work for all but the absolute largest of categories. – Robin Hood↝talk 23:48, 17 October 2012 (GMT)
  • Lonely Pages Page isn't there. Completely Blank could this be because of upgrades? Lord Eydvar Talk | Contribs 17:01, 3 September 2012 (EDT)
LE mentioned above, but here's a link for convenience: Orphaned Pages, it's coming up as a completely blank white page. Also, WantedPages is coming up empty, and shouldn't be. — ABCface◥ 17:15, 3 September 2012 (EDT)
The above issue has now been resolved. — ABCface◥ 02:14, 18 December 2012 (GMT)

Outstanding Upgrade Issues

  • (Separate issue refactored out of original) To get floating text on edit summaries, try changing MediaWiki:Summary as below.
My bad. Try this instead: <span style="float:left;">[[Help:Edit Summary|<span title="Briefly describe the changes you have made">Edit Summary</span>]]</span> • JAT 17:39, 3 September 2012 (EDT)
  • I've noticed that image thumbnails no longer line up the way they used to. See the examples on Help:Images for the easiest noticeable change. (Note where the descriptive text does not match what you actually see.) I think there were some changes Nephele made to the way these work that was not carried over into the new version. This could affect hundreds of pages, so it'd be hard to come up with a list of everything that's changed. TheRealLurlock (talk) 11:51, 3 September 2012 (EDT)
At issue seems to be the "clear=none" flag, which no longer appears to do anything. So thumbnails which were set up to be side-by-side now appear above-and-below instead, which screws up the layout of some pages. TheRealLurlock (talk) 13:26, 3 September 2012 (EDT)
Yeah, that's Nephele's custom code. That'll need to be re-copied into 1.19. – Robin Hood↝talk 14:55, 3 September 2012 (EDT)
All of Nephele's code should still be present so I'll have to look at why its not working. -- Daveh (talk) 15:22, 3 September 2012 (EDT)
  • Entering a page name (i.e. "combat") in the search bar while within a namespace no longer takes you directly to that namespace's article. Instead, it takes you to a search results screen with an alphabetical list of all of the combat pages in the various namespaces ("Daggerfall:Combat", "Oblivion:Combat", etc). Xyzzy (talk) 11:55, 3 September 2012 (EDT)
That is Nephele custom search code not working. It was re-added to v1.19 so I'll have to check what the issue is. -- Daveh (talk) 15:22, 3 September 2012 (EDT)
This partially works now—exact page names, including the correct namespace, will be jumped to automatically, however jumps within the same namespace do not. For example, typing just "Armor" while looking at Skyrim:Weapons will result in a search rather than jumping to Skyrim:Armor. – Robin Hood↝talk 22:11, 16 September 2012 (GMT)
Umm searching even exact correct names doesn't seem to auto jump anymore. Still takes you to the search page with every possible similar result. I searched Skyrim Destruction earlier got over 2000 results including every page where either Skyrim or Destruction were mentioned... Lord Eydvar Talk|Contribs 07:34, 3 November 2012 (GMT)
You need to search Skyrim:Destruction with the colon in the middle. That'll take you directly there; using a space won't. – Robin Hood↝talk 19:12, 3 November 2012 (GMT)
  • Blockers can no longer block, it looks like. It says I'm not allowed to prevent users from editing their own talk page, but that option is unchecked when I click on the Block button. – Robin Hood↝talk 14:35, 3 September 2012 (EDT)
  • I tried a block and it appeared to work. If you still run into issues let me know what block settings to duplicate it and I'll see if I can find the issue. -- Daveh (talk) 15:22, 3 September 2012 (EDT)
Sorry, I should have been clearer: I meant the Blockers group, since we're not allowed to block talk page edits, not blockers generically. Since you have full block permissions, you wouldn't run into it. As a Blocker, just do a block, add block time and reason, then hit the "Block this user" key with the various checkboxes on their default settings, and it comes back with "Internal error - You are not allowed to block a user from editing their talk page." – Robin Hood↝talk 16:23, 3 September 2012 (EDT)
You should be able to block now. There was a missing "blocktalk" permission which was causing the error message. Unsure exactly how it was working before but perhaps a bug that the update brought to the surface. -- Daveh (talk) 17:59, 3 September 2012 (EDT)
Blockers aren't supposed to be able to block talk pages. The thing is, I was getting the error message even when I wasn't trying to block the talk page. The only boxes checked were "Prevent account creation" and "Automatically block the last IP...". – Robin Hood↝talk 18:18, 3 September 2012 (EDT)
In a similar vein, Krusty mentioned the other day that blocked users are always watched, even when the box isn't checked, so it looks like some boxes are mistakenly being seen as checked when they aren't. Since the custom coding here is minor, I'm wondering if this might be a 1.19.0 bug...I'll see if I can find anything. – Robin Hood↝talk 16:16, 7 September 2012 (EDT)

Outstanding Upgrade Issues 2

  • "Floating" images don't seem to be working correctly. The hearts on Psylocke's userpage, for example. They scroll with me (stay at the corners of my screen) until I reach the end of the NPC box, and then they reappear once I reach the final section (Gallery). Before the upgrade they stayed on the screen the whole time. Previewing the hearts on other pages, they don't scroll at all at the top, and when they reappear at the bottom they scroll only for a short distance. Vely►t►e 11:47, 4 September 2012 (EDT)
This works for me currently. Can you look and see if it works for you as well? – Robin Hood↝talk 22:11, 16 September 2012 (GMT)
I get this on a diff of his page, but not on the actual page. Is it the same for you? – Robin Hood↝talk 18:49, 22 September 2012 (GMT)
  • Adding links by laziness doesn't make them auto fill in as seen here. It should fill in the namespace, a pipe, and link name. Filling in all but the link name [[Skyrim:Hearthfire|]] does work. The Silencer (talk) 12:26, 4 September 2012 (EDT)
    • Also, adding links to pages from the wiki as an external link (such as the "diff" page linked above in The Silencer's post) causes a large space between the link and the next character (this is where the external link icon would normally be, but only shows up for external links that are actually from other sites). — ABCface◥ 12:48, 4 September 2012 (EDT)
      • This is resolved now. — ABCface◥ 22:53, 4 September 2012 (EDT)
        • The issue of the arrow in external links was fixed, the issue of linking not working as before is not fixed. The Silencer (talk) 14:15, 7 September 2012 (EDT)
  • I think CSList has been affected by this. For example, when trying to find a quest by its editor ID, it sometimes doesn't appear. A search for MQ201, the quest Diplomatic Immunity, gives only four results: MQ201 Party Scene 2, MQ201 Party Scene 3, MQ201 Party Scene 1, and MQ201Malborne. The two more major ones, MQ201 and MQ201Party (which holds the aliases and sets up stuff), aren't there. I either have to search for the quest title itself (which can get me to MQ201) or know the formID (which I would need to find MQ201Party unless I remember that it's called "Quest to hold aliases and scenes for party"... which I do). It appears to have nothing to do with formID changes, as MQ201 has had a change but MQ201Party has not. It's happened with a few more I searched for recently: The House of Horrors, The Forsworn Conspiracy... It's very odd that the independent quests don't appear but the dependent ones do. Frustrating as well. It showed up fine before. Vely►t►e 16:42, 4 September 2012 (EDT)
  • The CSList is a completely separate database and code so it shouldn't have been affected at all. I haven't touched its code or database content at all. If you can find more information about any issue, however, just let me know. I don't know much about it myself as Nephele did it all and I've never looked into it in any detail but if there is a issue I can look into it. -- Daveh (talk) 21:00, 4 September 2012 (EDT)
  • Hm, I thought it was different, yeah. It's a recent occurrence though, because a week or so ago it was working fine. Have there been any changes to it or the things it uses in that time? Vely►t►e 23:29, 4 September 2012 (EDT)
  • Both the main page and also noted by another user that the Skyrim:Places pages will not load properly even with using Ctrl+F5. On my Google Chrome browser, it comes up with only a server error messages as following:
Server error

The website encountered an error while retrieving http://uesp.net/wiki/Main_Page. It may be down for maintenance or configured incorrectly.
Here are some suggestions:
Reload this webpage later.
HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfill the request.
And even then it doesn't solve the problem just by reloading the page. Any ideas? -- Helenaannevalentine (talk) 19:17, 4 September 2012 (EDT)
It happened to me too.I wonder if trying to acess it via google will work?Skyrimplayer (talk) 19:22, 4 September 2012 (EDT)
It's failing for both me and HnB from different browsers and across all content servers, so I would guess it's failing for everyone. – Robin Hood↝talk 19:52, 4 September 2012 (EDT)
Chrome, latest version, Windows 7: Still working just fine for me. Vely►t►e 19:58, 4 September 2012 (EDT)
I just tried again, and while I had to do a hard refresh, it's working for me as well now. – Robin Hood↝talk 21:29, 4 September 2012 (EDT)
I just double-checked it again using Ctrl+F5 and it now works perfectly fine. Whatever the issue was it seems to have resolved itself -- Helenaannevalentine (talk) 21:42, 4 September 2012 (EDT)
Okay, I've been trying for 2 days to submit an edit to Skyrim:Quest Items and failing - I can't Show Preview, and I can't even submit blind. I just get an all-white page either way (after a really long load time). I'm trying to add all the icons I uploaded over the last few days, but I think it's too much for the server to handle. (Probably generating dozens of thumbnails in order to show the page is beyond its capability.) There's other pages with far more images on them, though, and they render fine. I just can't submit this change to this one page for whatever reason. TheRealLurlock (talk) 21:46, 4 September 2012 (EDT)
(←) TRL: How's this working for you now? – Robin Hood↝talk 16:16, 7 September 2012 (EDT)

Outstanding Upgrade Issues 3

  • I don't know if this is a problem with the upgrade or what the issue is, but for some reason a lot of the Dawnguard and Hearthfire pages are having inconsistent issues displaying the modheader icon at the top right. Instead of showing the icon, you just see the text [[File:{{{icon}}}|Hearthfire|{{{iconSize}}}px|link=Skyrim:Hearthfire]] (or Dawnguard if it's on a DG-related page). It will work as normal, displaying the icon, then later it will stop working and display the text instead, without any edits to the page. At first, I thought it was an issue with the namespace parameter, but that's not the case. The issue occurs with or without the namespace specified, but it doesn't occur consistently. — ABCface◥ 16:32, 5 September 2012 (EDT)
This sounds almost as if it's not finding the Dawnguard or Hearthfire pages for some reason. I just made some tweaks to have it default to Skyrim in User and Template space, but it should have no effect whatsoever on pages in Skyrim space. Loading multiple DG and HF pages, I wasn't able to duplicate the issue before or after my changes. – Robin Hood↝talk 17:24, 5 September 2012 (EDT)
It's still happening. It was fine about twenty minutes ago, but I got this (screen) just a minute ago on the main Hearthfire page. No recent changes have been made to anything which should alter that template. — ABCface◥ 23:18, 5 September 2012 (EDT)
I was thinking of adding a check to see if it had successfully loaded the icon, but I decided against it for now until we can figure out what's causing this. I think I'd rather have people reporting an oddity, where they probably wouldn't notice if the icon was missing altogether. – Robin Hood↝talk 23:26, 5 September 2012 (EDT)
I've found a way to replicate it consistently. Edit an article that has a template that includes the current article for the exported variables, such as Mod Header on the Hearthfire article does or the Journal Entries template on each quest article does (for the QuestID). When the page is rendered after the edit, the values for the variables that should be exported by the page aren't exported. Therefore they are treated as missing variables. When iconSize isn't set, then using {{{iconSize}}} will print itself. A workaround would be to use {{{iconSize|}}} at these places to prevent printing that code or using {{#if:{{{iconSize|}}}|…}}. It happens after every edit. When the article is purged the variables are exported, so the it will work again correctly. I think I saw this issue already before the upgrade, but I'm not sure. I can replicate it every time after an edit, although in previous replies there is claimed that it also happened without an edit. -CoolGamer (talk) 16:32, 11 September 2012 (EDT)
Okay, I was able to replicate the issue finally...it required a "real" edit, not a null-edit. At this point, I think it's probably better that we leave it as is so we know it's still a problem. If people are getting it frequently, though, and it's a nuisance, we can certainly go with hiding it for now and re-test later when we think we've fixed it. I've yet to see it happen, personally, which makes me wonder what's causing it for some users but not others. – Robin Hood↝talk 18:13, 11 September 2012 (EDT)

(←) Just to clarify, this issue is also happening with Dawnguard pages, though I'm unsure if it happens with pages using the modheader in other namespaces. It just happened when a user made a change to the main Dawnguard article, and purging that page fixed the issue. — ABCface◥ 16:43, 13 September 2012 (GMT)

Some more observations about the problem I made over time. When you edit a page that does a #save, pages #load-ing that value may display empty values for the loaded data (often this is done through a template). In the case of the HF page and the HF icon, as well as in the case of a quest page and the ID displayed in the quest stage table those two pages are the same. But for example editing an individual ingredient page has some chance to mess up that entry on Skyrim:Ingredients. A workaround is to purge the affected page, multiple times if needed. The whole thing seems to be a race-condition between re-rendering the pages #load-ing the values and making the #save-ed data available. --Alfwyn (talk) 13:59, 30 September 2012 (GMT)
Just an update, as brought up here, this issue is not unique to the Skyrim namespace, as it affected the KotN pages as well. — ABCface◥ 20:36, 15 October 2012 (GMT)
  • Semi-protecting pages seems to have failed to block edits from users who shouldn't have the permissions to edit them. Take the recent nonsense bot attack on Lore:Molag Bal. I semi-protected the page here, only to see the page be anonymously edited here. --AKB Talk Cont Mail 18:06, 5 September 2012 (EDT)
There was only a small time period of several seconds between the placing of the block and the edit by the anonymous user. I think it was just a race condition. (BTW, the user who made that edit isn't blocked yet.) -CoolGamer (talk) 18:24, 5 September 2012 (EDT)
I know that it was just a few seconds. Even so, it shouldn't of been able to make that edit. Considering all the other bugs that came with the update, it's better to be safe than sorry if it turns out our ability to protect pages is crippled.. --AKB Talk Cont Mail 19:35, 5 September 2012 (EDT)
If one server processed the protection and the other server processed the edit, that could account for the slight delay, I think. In any event, I just opened the page in another browser and was unable to edit it as an IP, so I'm inclined to think that whatever the underlying cause, the edit only got through due to timing. – Robin Hood↝talk 22:58, 5 September 2012 (EDT)
Lore:Molag Bal is still fully protected. If there were no other problems with semi-protection, could we consider changing it back to semi-protection and see if it is indeed a problem? --Alfwyn (talk) 00:12, 29 October 2012 (GMT)
  • The AbuseFilter log is not showing the Skyrim namespace correctly. For an example, look here. It claims that the edit took place on Shivering talk:Serana, but the filter itself is accurately detecting that it's on Skyrim talk:Serana. It's possible that other namespaces are affected by this. • JAT 05:26, 20 September 2012 (GMT)
This also affects Lore (as with this edit) and Daggerfall (like here). Vely►t►e 12:55, 20 September 2012 (GMT)
  • The move function seems to be acting up. Two times after a move I just got a blank page and the move is only half done (looks a bit like a timeout problem). The move of File:SR-book-Illusion13.png shows up in my contributions, but not on the RC. In the second case while moving Skyrim:Master Illusion Text, a redirect for the page was created, but no redirect for the talk page (both page and talk page were moved though). --Alfwyn (talk) 14:32, 24 September 2012 (GMT)
  • I'm back again. Which is related to what is possibly another bug with the upgrade; when I first tried to log in (with the "Remember Me" button checked, if that matters), I was informed that I had cookies disabled, and I should try to log in again after enabling them. On checking, however, I found that (as I suspected, since other sites I use which make use of cookies were having no problem with storing them, so far as I'm aware), they were, in fact, enabled; as such, I tried to log in again, and, as is probably obvious from the fact that it's me posting, was allowed in at that point.--TheAlbinoOrc (talk) 06:23, 25 September 2012 (GMT)
    • That could be related to a similar, sporadic bug I've been getting. Every now and then (maybe once every 100 to 200 pages), the page will have weird formatting and display that I'm not logged in (screenshot). A refresh fixes this, so I'm just guessing that a packet or two is getting lost in transit. Perhaps you were just unlucky and hit that same problem on the login screen? • JAT 06:40, 25 September 2012 (GMT)
      • Just chiming in to say I've had the same experience as Jak. — ABCface◥ 13:47, 25 September 2012 (GMT)
  • A rather strange and obscure one is that the link for viewing user blocks adds underscores to usernames. I found this when checking Dagoth Ur, Mad God's current block status as a follow up to NigerianPrince2's comment, and was informed he wasn't blocked. Removing the underscores added by the link from the userpage fixed this and showed the current status. Golden SilenceBreak the Silence 23:55, 25 September 2012 (GMT)

A New Spam-Bot. Awesome.

So apparently since our blocking techniques worked against the old bots so well, they've changed their M/O. They now don't bother creating an account, and post as anonymous IP's on some random not-yet-created talk pages - often repeatedly. This one seems pretty persistent, creating the same pages 2 or 3 times in a row even after they're deleted. For all those that have been created more than once by the bot, I put protection on them so only established editors can create those pages again. Hopefully that should deter them somewhat, but my guess is they'll just find new talk random pages to create. Isn't there some sort of system in place that's supposed to prevent page creation by anonymous IPs or new accounts? And if not, why isn't there? Does that feature only prevent creation of article pages and allow talk pages for existing articles? (Would explain the recent crop of talk page creation.) I think page creation should be restricted to accounts (NOT IPs) with a minimum edit-count of, say 10. That would stop this one dead in its tracks. Also should run afoul of the keyword filter for new pages - every one of these contained the word "jersey", both in the text and the edit summary. If that's not in the spam filter list, it needs to be. Not likely to see that word used in a legitimate edit. TheRealLurlock (talk) 03:03, 24 October 2012 (GMT)

I think anonymous users should still be allowed to create talk pages, as many may do so legitimately. But we do need to do something about this, as it isn't new (it was present before, just not this badly, probably because the other types were still allowed) and is definitely worse now than before. Perhaps Jak can edit the AbuseFilter to add a keyword for this type of spam. The Targeted Spam Filter currently doesn't block "jersey" or "jerseys", so maybe it should. — ABCface◥ 03:20, 24 October 2012 (GMT)
I added "jersey". Assuming it catches substrings, "jerseys" is unnecessary. Not sure if that will also prevent people from talking about the state of New Jersey, but it's a risk I'm willing to take. (How often is there a legitimate reason to talk about New Jersey on this site anyhow?) Hopefully this will stem the current flow. Though if they start just spamming something else, we'll have to come up with another plan. TheRealLurlock (talk) 03:27, 24 October 2012 (GMT)
Spammers are both smart and stupid. Smart, as in they come up with new ways to spam, sometimes ways that we wouldn't have thought of ourselves. Stupid, as in they do it over and over again (as can be seen by Special:AbuseFilter/3 racking up over 2,000 hits in under a month), and as in they spam the same words and phrases. The filter is in most cases good enough, and is excellent for dealing with these kinds of situations (where spammers repeatedly spam a specific word or phrase). Should this somehow not work, however, I think it's a very bad idea to block talk page editing to existing users only. It is not in the wiki spirit to require people to create an account, and it's even less in the wiki spirit to require them to make ten edits before they can ask for help with a quest. It would do our site great harm to shut out anonymous users from asking for help, as that is one of the reasons why our site is so accessible - if you need help, you just ask for it, without logging into an account or registering an email or any of that crap.
Remember that spammers evolve very slowly. For instance, the pre-AbuseFilter wave of spammers was so big not because they were sophisticated, but because there were so many spammers. It's taken them nearly two months to figure out that they should try something else. There are only a limited number of avenues for spamming, and I'm confident that we can deal with most if not all of them, should the issue arise. • JAT 05:29, 24 October 2012 (GMT)
While many anons do start talk pages legitimately, we have help centers, a reference desk, active contributor talk pages, etc. Anonymous users with real comments/questions/concerns who try to make a new page can be guided elsewhere in a notice. They don't need to have the ability to create any kind of new page. I don't think stopping them from doing so can even be described as inconvenient, and I'm sure anons will understand it's a legitimate anti-vandalism limitation. It seems reasonable to me to restrict their page-creating privileges. Minor EditsThreats•Evidence 05:45, 24 October 2012 (GMT)
I agree with Minor Edits on this, I've had to revert and flag way too much stuff from Anons in the last 72hrs and have seen at least 10xs that much get dealt with by other users in the same time frame... I'd definitely say putting some sort of restriction on edits/creations that Anons can do would be a good thing. Lord Eydvar Talk|Contribs 05:47, 24 October 2012 (GMT)
I have to say again that I am against limiting anonymous users in this way — strongly against. I agree with Jak completely on his post here, for the reasons he stated and more. If the filter continues to do its job the way it has for the last two months, there isn't a reason for this at all. This is one day we have been hit like this recently, and now that there's a keyword added to the Targeted Spam Filter in place to prevent this type of spam, it's already been taken care of. There's no reason for this talk of limiting anonymous users this way. — ABCface◥ 06:00, 24 October 2012 (GMT)
The reason is deterrence. I agree with what Jak said, too, but we're almost encouraging spam if we leave "easy" routes open simply because they haven't been exploited extensively yet. I would rather that these [insert profanity here] simply give up instead of exploring new approaches again and again; that's more likely to happen if our response to them is sufficiently daunting. With a reasonable alternative for anons' contributions just one click away, I don't see how anonymous participation will be significantly interfered with or discouraged. And there's an argument for quality control, too: if someone decides not to add something simply because they have to go one extra page, odds are what they had to say isn't worth our time. Minor EditsThreats•Evidence 06:26, 24 October 2012 (GMT)

(←) Just wondering is there a way to add like a checkbox that needs to be checked/unchecked before edits can be submitted into the pages? Cause something like that might work... can't see a bot figuring out that it needs to check that little box to post. Lord Eydvar Talk|Contribs 06:32, 24 October 2012 (GMT)

(edit conflict) I do agree very much with Jak about the whole spirit of the wiki thing, but I also am a firm believer that as the people running the site, it is our duty to maintain the integrity of the site, and if that means blocking anon page creation for a few weeks, a few months, or even the next year, then I am all for it on a short term basis. All this spam is getting tiring, and since the spam bots can always start using new phrasing, I think it would just be easier to nip it all in the butt by preventing them from creating pages in the first place. Autoconfirmed page creation would stop the brand new spam bots and IPs from creating pages, since they wouldn't have the right amount of edits, as their edits come from page creation, so it seems like the most logical short term solution for me, until we can better determine a way to do this. And, for the legitimate new users who want to create pages, since unlike a bot, they can read, a notice saying to contact a mentor for assistance seems pretty reasonable. Eric Snowmane(talk•email) 06:38, 24 October 2012 (GMT)
As a user that likes posting anonymously, I have to say that I would disagree with blocking Talk-page creation from the anonymous crowd. If the filter as amended works the problem is solved. If it doesn't then...well...add Captcha to all create pages? Checkbox would be too easy - I think that was circumvented a few years back necessitating the creation of things like Captcha. Most of my anonymous postings have been questions about certain things that I felt needed clarification, but didn't require my online presence. Now, anonymous editing of article pages...now that I can get behind. RCWizard (talk) 07:41, 24 October 2012 (GMT)
I'm with the no-limiting-anons crowd here. As one of the few people who regularly deals with spam cleanup, I can't lie—spam is a pain, and I wish we had less of it. On the other hand, though, it takes literally a couple of seconds to deal with each instance, which is not that big of a deal. And honestly, even if we didn't have people around to delete spam on-sight and it sat for a couple of days, it isn't hurting anybody. I don't see anything here that The Almighty Filter and a few seconds' worth of button clicks doesn't already solve. ⇠eshetalk 13:25, 24 October 2012 (GMT)

Page Protection (2)

As a result of this edit, I'm wondering if that page shouldn't be at least semi-protected, if not fully. – Robin Hood↝talk 20:12, 26 October 2012 (GMT)

Stopping spam accounts from being created

I just had an epiphany. The reason the bots are able to create so many accounts is that they've figured out a pattern - Enter account name here, fill out captcha here, etc. The create account page is predictable and easy to crack. What if there were a way we could script it such that the fields you have to enter to create an account are in random order? A legit new user wouldn't notice the difference, because they'd generally only see that page once. And they could read the labels to figure out what info goes where. A bot wouldn't be nearly as clever, and might have a hard time figuring out which field is which because it's expecting them in a certain order. It's like constantly modulating your phaser frequency to get past Borg shields. (Or if you prefer a somewhat less geeky reference - like changing your radio frequency to prevent your enemies from jamming or intercepting your signals.) I don't know what it would take to make that happen, but if it could be done, we might be rid of these spam-bots once and for all. Well, the ones that create accounts anyhow. Wouldn't be much help for the anonymous IPs, but there might be other ways of dealing with that. We already require a captcha for posting links - what if that captcha were not always in the same place somehow? (E.g. Sometimes before the summary line, sometimes after, etc.) It's a barrier that's nearly invisible to humans but would totally flummox most bots. Anyone know what it would take to do that? TheRealLurlock (talk) 06:03, 29 October 2012 (GMT)

That is a brilliant idea, and I like it. Eric Snowmane(talk•email) 06:18, 29 October 2012 (GMT)
It's a great idea in theory, but in practice, all the controls are identified by name rather than what order they're in. Of course, that leads to the next obvious thing to do: change the names. Dave (or Neph if she comes back) would have to do that sort of thing. Alternatively, if we don't want to change one of the existing names, we could do what someone suggested somewhere else recently (don't remember where) and add an extra verification question...even a simple yes/no. Unless the bot creator specifically examines our site, that question would always fail for a bot...and if the bot creator does examine our site—which seems unlikely given how many sites these things run on—we simply change the name of that control again, or change the type of answer required or whatever. – Robin Hood↝talk 07:21, 29 October 2012 (GMT)
I'm glad this was brought up. I think one of the primary ways of stopping spammers we've ignored so far is simply making account creation more difficult. While I don't support making things like emails necessary or anything like that (and I don't see that really cutting down on spammers), adding a verification question seems smart. --AKB Talk Cont Mail 07:41, 29 October 2012 (GMT)
I think that maybe you should add email verification. I helped admin another forum that had about 10-30 obvious bot accounts created everyday (we even had captcha) but I can only recall 1 or 2 incidents of spam in the several years the site was running. As best as I could tell it was the email verification that stopped them from being able to post. That being said it should be easy to design a bot to get past email verification but at least until they do it would stop them.Ewolfg1 (talk) 00:45, 3 November 2012 (GMT)
Almost all of the new accounts are email verified according to multiple posts by Daveh, the sites creator. Silence is GoldenBreak the Silence 00:55, 3 November 2012 (GMT)

undoing legit comments/edits

Not sure this is the correct place for this so if there is a better page please let me know WITHOUT deleting my comment, I'm quite capable of moving it myself if you aren't once I know the correct place to put it. Since having created my account here I've noticed one very disturbing trend that is really pissing me off, mods on this site are undoing legit comments or page edits. Specifically I'm refering to today's undo'ing of my comment to a discussion about a glitch and me adding 1 sentence saying you can get a servant for the house in Skingrad to the house page. The glitch convo was 2 years old but since I have the newest official and unofficial patches and it happened to me then it's obviously still in the game and still relevant not to mention I had suggested a possible temporary fix to the glitch and yet my comment (on a talk page which is intended idk maybe for people to talk?) was undone the reason listed as "necropost". The servant thing (imo at least) is a pretty darn notable feature for the Skingrad house worthy of a total of 182 bytes of info (especially since the Chorrol house already had a sentence saying you couldn't get a servant for it), today I had my talk page created and edited by a mod and he put alot more than 182 bytes on it so I'm guessing your not starving for data storage. The internet was created for people to be able to share ideas and thoughts with others, why are some of your mods being so restrictive on the sharing of a very small amount of thought especially since my comments are in the appropriate areas?Ewolfg1 (talk) 01:24, 3 November 2012 (GMT)

The user who posted and undid your post is not a mod--he doesn't have any special rights on the site, though he is in a special sort of user group. Anyone is allowed to undo your posts or post on your talk page. 95% of cases where a person posts in a dead conversation, it adds nothing to the wiki, but as you brought up some new points to a persistent issue, there is no problem with that. Everyone makes mistakes, though.
We're not starving for data storage, no, but we like to avoid necroposts and idle chatter to keep the Recent Changes clean and the talk pages focused.
If you feel that a post of yours was removed in error, then please comment on the talk page of the person who removed it to clear up any confusion. If you feel that it truly is a trend, then more examples would certainly be welcome. I apologize for any confusion or frustration on your end. Vely►t►e 01:44, 3 November 2012 (GMT)
I make no apology for removing a post to a two year old conversation, that imo adds nothing, and your submission to the Skingrad house, which was made anonymously a year ago is still there, so why it is being mentioned I don't know. Silence is GoldenBreak the Silence 09:03, 3 November 2012 (GMT)
My Skingrad submission is still there because after Rpeh undid my submission I undid his undo and started a discussion on the talk page about why I thought the sentence should be there, and as for why it got mentioned I refer you to the 2nd sentence of my opening comment for this section. And please define what your planet means by "adds nothing" because on planet Earth if I come up with a possible solution to a glitch we define that as "adding something" the fact the discussion started 2 years ago means very little since the bug is still present today and there is no reason for me to start another discussion on another talk page when all the related info is already on the Sabine Laul talk page and as best as I can tell RobinHood70 (one of the 3 non-anoms who participated in the discussion 2 years ago) also thinks it's relevant because the discussion got added to the "questions that need answering" category due to my comment (at least that's the impression I got from his edit summary). Just because this is a wiki and everyone has the ability to edit/undo someone's submission that doesn't mean you have the right to do so. I have the ability to post on or undo a revision on almost every page on this site, but I haven't done so because I have no right to do so. And like I said in the summary when I undid your undo, this is a talk page quit being so damned restrictive on comments especially related comments. — Unsigned comment by Ewolfg1 (talk • contribs) at 10:08 on 3 November 2012
Well, you never explained in your newest post to that talk page that you had the newest patches. So all Silencer saw was another person posting that he'd had the glitch happen to him too, which doesn't add much to the conversation.--Skyrimplayer (talk) 12:02, 3 November 2012 (GMT)
When I was new to this wiki, the amount of undone talk page contribution surprised me too. Several other wikis have a clear stance on not removing posts of other people (wikipedia recommends showhide instead of removing). Then again this wiki has a more than the usual share of irrelevant talk page contributions, so it might just be something to get used to. --Alfwyn (talk) 12:41, 3 November 2012 (GMT)
@skyrimplayer On every other forum/wiki I've been on it is expected that people find out if they have the latest patch BEFORE reporting a bug not to mention the bug is NOT listed as having been fixed in any patch notes so why exactly should I mention I have the latest patches when no patch has fixed it and me saying I have the latest patch would therefore mean nothing? And for the 3rd time now I didn't just report I had the glitch, I also included a possible solution to the glitch that alone is adding to the conversation. EDIT Also if it's questionable if someone has the latest patch then it's fairly easy (and alot more politer) to simply ask if they have the latest patch instead of assuming they don't and deleting their comment--Ewolfg1 (talk) 20:29, 3 November 2012 (GMT)
If you have some important information to contribute, clearly indicate it in your talk page post, or edit the article itself. This isn't a forum, and talk pages are supposed to be used for improving the article. If you feel someone was too quick to revert your comment, contact them directly. Generally they have a good reason for doing so. If you just want to talk with others about your experiences with the game, consider heading over to the forums. —Legoless (talk) 20:49, 3 November 2012 (GMT)

Permanent protection for Lore:Gods?

This page is being targeted by "very nice site" vandals. This is not the first time. Can we get permanent protection for it? If anyone wants to make positive edits to it, signing in should not be a problem. It's a lore overview page that gets a significant amount of attention; registered contributors should be able to maintain it without assistance from the anonymous crowd. Minor EditsThreats•Evidence 02:54, 4 November 2012 (GMT)

Done. —Legoless (talk) 02:59, 4 November 2012 (GMT)

We Need A New Technical Admin

Note: I typed up a very long and convincing proposal (around 3,000 words), but my browser crashed before I could hit Show Preview :/ I'm just going to keep this one short and sweet.

The proposal is pretty simple. With Nephele gone and Daveh busy, we need another user with server access to help maintain the website. We've all worked hard, and the site is definitely in working order, but there are still some problems that direly need to be fixed. The search function is still broken, clear=none isn't working, and the site's CSS needs to be cleaned up. We still have a large amount of Outstanding Upgrade Issues that need to be fixed. There are a lot of things that can be added to the site as well, such as Hearthfire to CSList, and a Skyrim alchemy calculator (like the one we have for Oblivion). New problems will inevitably crop up in the future, and we need to prepare against those too.

I've discussed this with a few other users, and although there are differing opinions on how to implement this, there seems to be a general consensus that something has to be done. From what I've seen, there are two possibilities:

  • One or more users are promoted to admin and given server access, or
  • One or more users are promoted to a different user group which gives them server access, but does not make them admins.

This decision will be interesting. With the first option, whoever was nominated would have to be both skilled enough to work with the server, yet also meet the strict requirements for adminship. With the second option, we'd have users with more power than admins, yet are not themselves admins, which seems rather silly. We then have to decide who to nominate. Personally, I think there are three people that meet the qualifications for this: RobinHood70, Alfwyn, and I. All three of us are patrollers, competent editors, and skilled programmers. However, I'll leave that part for later.

It is critical that we fix the site's problems, and I believe that the best long-term solution is to give another user (or possibly more than one user) the rights to be able to work on the server and fix these problems. • JAT 06:11, 8 November 2012 (GMT)

3,000 words? Each part of Tale is only approx. 1500 words haha. On topic, I don't know the fancy technical aspects of it, but out of you three of you... I don't know Alfwyn's qualifications, and I know that, while you know your stuff, you've been applying for university and all these other things, so I have no idea how available you'd be for that kind of stuff. I'd have to side with RH70. He's been doing different code things a lot longer than you, and has more experience, plus he's at home all the time, so if he was feeling well enough on the given day, and was up to taking the role to begin with, he'd be able to be called on by whoever needs help. ES(talk•email) 06:22, 8 November 2012 (GMT)
I should make myself a bit more clear. Not to single you out Eric Snowmane, but right now, this is not a nomination. We're just deciding if we would even be interested in having a new technical admin. • JAT 07:20, 8 November 2012 (GMT)
(edit conflict) Just on a technical note, server access is a completely separate thing from any groups on the wiki. It would be silly, but there's no reason I'm aware of that we couldn't give Jimmy Wales server access, even though he doesn't have an account on our wiki (that I'm aware of). :) As Jak points out, though, anyone with full server access can make changes that even a Bureaucrat couldn't make, though I believe Daveh can limit access to only certain programs/areas of the servers (e.g., maintaining the CSList without having full access to the wiki files). Also, we need to keep in mind that even small changes on the server can potentially have far-reaching consequences.
So, as far as who should be given this access, all three of the users mentioned have points both for and against us. The biggest one against all three of us, as far as I know, is that none of us has more than passing familiarity with PHP, which would limit our ability to figure out how to fix some of these issues. For myself, while I'm willing, I'm probably also going to be the slowest to figure my way around due to the CFS, which makes it harder to retain new information or to concentrate for lengthy periods of time. On the flip side, though, I have at least a tiny bit of prior experience with site management and the tools involved. Dave would still have to do a lot of coaching before I felt comfortable making more than minute changes, though.
I guess that's the long way of saying that unless Dave is planning to dedicate himself to the wiki full-time, as he'd suggested a while back, then I agree, we do need someone else with server access. My first choice would be Alfwyn, if he's interested, but honestly, I'd be quite happy to see any of us with server access. Of course, I'd be even happier if Nephele came back :) but last I heard, she had a lot of other things on her plate. – Robin Hood↝talk 07:40, 8 November 2012 (GMT)
Just to get this out of the way, I agree with the sentiment. The administration does need more technically skilled members, which we're a bit short of as of now. However, was Daveh one of the users you asked about this? We've only ever have had one other user with any kind of actual server access, and that was his decision (though the community supported it). You're not asking for someone else to be made an administrator as Robin pointed out, but given more power than even Nephele has as far as I know. While I find myself leaning towards supporting someone being given server access on a temporary basis, I'm not really comfortable with the suggestion of any user being given that right permanently without it being Dave's suggestion. --AKB Talk Cont Mail 19:55, 8 November 2012 (GMT)
I have to agree with AKB here—this isn't necessarily a bad idea, but I'm not comfortable with it unless Daveh is, and I think it really has to be his call. If he's got someone in mind he feels comfortable giving server access to, then I don't see a problem with it. ⇠eshetalk 20:01, 8 November 2012 (GMT)
AKB: Nephele has full server access (see here). (In other words, any new user would have the same or less access than Nephele...it's entirely up to Dave.)
Also, something else to keep in mind is that we can split who can do what. For example, I'm almost at the point where I can update CS List (still need some programming on my end, but I'm getting there). I certainly don't need full server access to do that, just database access. Someone else could get file access to do PHP programming or wiki configuration changes. Nothing says it has to be one person doing everything. – Robin Hood↝talk 20:21, 8 November 2012 (GMT)

(←) I assumed her access was limited somehow, as UESPWiki:User Group Rights states " Only Daveh has full access to the servers on which UESP runs, including the ability to update and configure all of site's operating software. Nephele can login to the servers, view the site's software configuration files, and make some changes.". I guess Elliot may had been wrong when he wrote it, but I would of thought it would of been corrected down the line. Regardless, you can see my point even if my comparison was inaccurate. I assume that any user given this responsibility could also be limited, but it still worries me enough that I feel Dave is necessary in this. Thanks for notifying him, by the way. --AKB Talk Cont Mail 20:27, 8 November 2012 (GMT)

Yeah, I think that description is slightly inaccurate. Obviously there are some things that only Dave can do, like calling the ISP and asking them to make physical changes, but apart from that, I believe Nephele can do anything Dave can do. She's certainly done things before like changing PHP files, configuration files, installing extensions, rebooting the server, etc. And yeah, I figured the next step was to get Dave involved. – Robin Hood↝talk 20:37, 8 November 2012 (GMT)
A bunch of comments on various things brought up here so to keep it short I'll put them in point form:
  • I am indeed planning to work full time on the site next year which means I'll be much more available for support and development than currently. This doesn't really eliminate the need for one or more admins as I still have vacation, I have to sleep sometimes, and there are still a good two months left in this year when I've be mostly unavailable.
  • By "full access" I was meaning root which only I have and technically even I don't need root to do most of the work. Ideally there should be a few security levels available from shell access but the need and time required just has't been there.
  • Avron from the forums does have shell access although her work is limited to the specifically the forums.
  • Whom ever does get access doesn't necessarily need to be a shell/Linux guru as I don't mind people learning on the job (it is basically what I do anyways). On the other hand, having some more knowledgeable than me would be nice as well as they can point out areas that need improvement.
  • The biggest challenge in granting shell access is that you can very easily break the site. This should be readily apparent by the number of times I've broken things despite basically knowing what I'm doing and specifically not trying to break it. Part of this is better documentation (or actually documentation) on the site setup and the other part having a more robust site design (harder to do but everything can be improved).
  • Most the upgrade issues and other work that needs to be done is just software development. We sort of have a development environment setup on content3 which makes it easy to test things without breaking the site for everyone. We can easily setup one or more people to work on content3 and have the finished/tested changes deployed to content1/2 by myself or whom ever the new shell access is given to.
Daveh (talk) 21:54, 8 November 2012 (GMT)
I'm glad to hear that you'll be able to work full-time on the site - we all love being able to interact with the webmaster of this site, and having you here full time will be very nice. I don't think any of us would need root access - mostly just being able to change PHP files, configuration files, installing extensions, updating CSList, and the like. Using content3 as a test bed is a good idea. In addition, my desktop computer has Google Chrome, and one neat thing about it is that you can select an element on the web page and edit it, including any source files, and immediately see the results, allowing for quick testing.
Alfwyn, Robin Hood and I have been talking a bit, and we all agree that ideally, more than one of us would have server access. Not only would that allow us to use our different skills more effectively, but we'd be able to more easily collaborate on projects, and help each other out. Either two or three of us should have access - if only one of us does, then that'll decrease our effectiveness considerably. My opinions on our qualifications are:
  • RobinHood70 has some experience working with databases, but his main qualification is that he has a bot that's just about ready to be able to upload directly to CSList. He's also a long-time user of the site and well-trusted, and I'm confident that he'd safely use any new powers.
  • Alfwyn is an actual programmer (and the most skilled of us three), so he'd be able to pick up on the new programming language quite quickly, and expertly modify and create files. If only one of us received server access, then Alfwyn would probably be the best candidate.
  • I am the least skilled overall, but (although I really hate to toot my own horn) I learn really, really fast. In addition, because I only have 3 hours of classes per day, and homework only two days of the week, I'd also be the most available.
I suspect that if it came to a vote, people would vote in that order. If we decided that two people were best, and I was left out, then that's okay. The site's needs come before mine, and if the community decides that it's for the best, then I'll go along with it.
Also, a minor note, but from here on out, when I refer to server access, I mean access to the PHP files, configuration files, and ability to update CSList and whatnot. I doubt we would need shell access, and I'm certain that we do not need root access (both as a precaution and because we simply wouldn't need it). • JAT 06:41, 10 November 2012 (GMT)
Just want to say I appreciate all three of you identified so far, for being interested in contributing at a deeper level, applying your skills, and (where relevant) learning more. To mention just one of the reasons raised above calling for one or more additional people to have shell access, and one or more to have content3 development environment access, I think that just having as useful a search utility as possible, as fast as possible, will likely prevent some people from turning away from the site. I'm sure that most people who appreciate the unique strengths of our wiki won't just abandon us, but I can also imagine a significant number of people who feel even a tad frustrated with finding what they're looking for turning elsewhere quite quickly. It may be hard for those of us who love the wiki to see that, but I feel its a serious risk. I'd hate to see that happen.
With respect to what higher-level server access might mean in terms of roles or authority in the community, I think we need to wait and see what Daveh tells us about that when he has the time (maybe even the time to think about it), but I don't think that giving someone the tools/capability to perform admin-level activities is necessarily the same as making them admins or giving them permission to perform "admin only" activities. --JR (talk) 07:57, 10 November 2012 (GMT)
Addendum: For example, supposing that I gave a neighbor a key to my apartment in case of emergency, that does not mean that the neighbor has permission to look under my bed and examine my issues of "Skin Disorders of the Buttocks: A Pictorial Diagnostic Guide". --JR (talk) 08:02, 10 November 2012 (GMT)
I expect that if more than one of us is given shell access, we'll quickly split off based on our various pre-existing skills, though I think each of us would still have a lot to learn even within the areas where we have some skills already. In my ideal world, I'd like to focus on CS List and leave the PHP programming (i.e., things like the search functionality, fixing the icon clear parameter, etc.) to Alfwyn and/or Jak. If Dave would rather see only one person there and if I end up being that person, then I would prioritize the programming over CS List, I think.
Also, I should clarify that while I think I'm close to being able to upload data to CS List, a lot depends on how Nephele designed it as well. I can make educated guesses just based on what I'm seeing on-screen, but I could be completely wrong, in which case it could take a lot longer. I'll be in a better position to judge if/when I get a look at it.
As far as people's roles on the wiki, I mostly see the need for a technical admin as being necessary for things like CSS changes and protected templates. That, however, is an entirely separate issue from having server access, even though they do tend to go hand-in-hand. – Robin Hood↝talk 08:41, 10 November 2012 (GMT)
I think JR makes an important point. Having access to the database one could emulate admin activities, but it should not be done. I believe that shell access and the admin role can be separated, and documenting changes done, like Daveh does even now, will be important.
Having more than one with server access would mean there's always a backup available, and specific changes could be discussed on a technical level between them. A single person might often overlook quite obvious things. --Alfwyn (talk) 13:41, 10 November 2012 (GMT)

(←) Okay, so it seems there's general agreement on the fact that one or more people with server access are needed. Does anybody have any thoughts as to a nomination process? The only example we have currently is Nephele's request back in late 2007. Do we want to do it like that and have three separate nominations? Do we want to have a three-in-one nomination, either as a single vote or with sections where you can vote on each of us? Or should we just leave it all up to Dave? (I'm not in favour of that last one, simply because of the lack of precedent, but server access is a bit of a different beast from wiki role, so I can see an argument for it.) Lastly, are there any other names that haven't been mentioned so far who should be included? – Robin Hood↝talk 03:16, 14 November 2012 (GMT)

This process gives the prospective users more rights than anyone on the site, so while in the end, it's ultimately Dave's call, as only he can grant these permissions, I'd still like there to be some kind of community procedure involved. It's just nice to be able to think that each user is someone the community respects and knows will handle the power responsibly, rather than random users who say "Dave, these are my creds, may I have server access?"
I would also want each individual person who wants server access to have a separate nomination, so that the community can thoroughly scrutinize each of them, rather than a group as a whole, in order to have a better understanding of each individual user. Perhaps each request will be handled similar to an RfA? Each user makes a case for why they need the rights, and then they have to answer a set of hard, serious questions that will be used to judge the user's character and ability to take the role before each user can take a vote or otherwise place confidence in the user they want to receive access? ES(talk•email) 04:11, 14 November 2012 (GMT)
Actually, there was one other example, though rather than getting a new Bureaucrat, we ultimately ended up losing an Admin, so that might not be the best example. But it does give some other ideas of the types of questions that might be worth asking. On a side note, I briefly considered throwing my own hat into the ring - I am actually a professional programmer as well, in that a major game studio is paying me for it. However, web programming has never been one of my strengths, so I'm fine with letting others take the reins on this. (Plus I plan on applying to Bethesda at some point in the future, and if that ever works out for me, I'll probably have to leave you all or risk breaking NDAs and all that.) TheRealLurlock (talk) 04:22, 14 November 2012 (GMT)
In this case, I don’t believe in a public nomination. I have been an administrator for three years and I don’t have a clue what server access is, yet, if we put these three persons up for a vote, it will inevitably end up as an RfA, warts and all – simply because people don’t know what they’re voting for. I’m not saying everybody is as stupid as me, I’m saying that some decisions are too important for the rambling community. We are running one of the biggest gaming sites on the web and this should be up to Daveh as they WILL be his responsibility in the end. There’s a HUGE difference between administrator duties (now more than ever, actually) and technical maintenance and it’s overly important that we find the right persons for the job. I’d back up RH70, Alfyn and Jak for this task any day of the week, but a public nom wouldn’t benefit the community at all, for the above-mentioned reasons. There’s a huge chance a nomination will turn ugly, with the three nominees defending their previous Wiki actions endlessly, with someone who has no idea what they’re voting for.
I propose that Alfwyn, RH70 and Jak all send some personal information to Daveh and Cc the administrators and patrollers. As administrators, our job is to know the editors and their editing style, and patrollers should, at the very least, have an idea about who’s who on the Wiki. In short, this needs to be dealt with on e-mail, and between Daveh and the nominees. Administrators and patrollers can provide a bit of input, but in the end, this IS Daveh ‘hiring’ some assistants, and he can do what he wants. Also, there should be no confusing ‘this user is a server wizard’-userboxes, no mention of the server access anywhere – just an agreement between the site owner and the people with the access. They’re here to help out with the technical side of things, not polish their egos, and that’s a very important thing they all should agree upon. That’s my honest opinion on this matter – a triple-size public nomination will just lead to endless rambling, unimportant discussions about ‘who-took-wiki-breaks-and-when’ and all the usual stuff. Let’s leave it to the site owner. --Krusty (talk) 07:38, 14 November 2012 (GMT)

Server Access Break 1

Krusty, you make some good points, however, I am still preferential to at least some kind of Q&A, at minimum before users are granted server access. Granted, this kind of request has only happened once in the past, so there isn't a lot of precedent to follow, but in the spirit of the wiki, as Jak always likes to put it, we should allow at least minimal feedback on the issue so that the site's users know what's going on. This is a community driven site, so we need some kind of transparency.

I agree that a nomination process wouldn't be compatible with this particular request, but the Q&A aspect of the RfA process should be carried over in order to get to know what the user has in store for the future with their rights. Transparency helps ensure honesty, as everyone would know what to expect. They are, effectively, being granted super-admin rights, so they need to be users of the highest standing with the wiki community.

Lastly, the wiki is run on consensus, and while this isn't exactly an issue that can easily just fall to consensus, it still feels almost elitist to only consult a small percentage of the active user base over what needs to be done, which is why I feel like discussing each user's different aspects via an email, as you suggested above, is not proper. It goes against what the community as a whole is. We have plenty of regularly active users who don't have rights and have been around to know what's going on, and simply by that standard, would immediately be excluded from discussing a major change for the site.

I am quite tired, so I might not make a load of sense, and I will clarify my stance, if requested. I just wanted to say what I wanted to while it was still fresh on my mind. Essentially, despite being a "job" of sorts granted by Dave, I feel that some amount of transparency needs to be maintained, as community feedback is just as valuable as the feedback of you, me, or any other user of the site. ES(talk•email) 08:22, 14 November 2012 (GMT)

As I said above, I can see the argument for this to be between Dave and the three nominees, and honestly, it's a borderline thing for me. In some sense, it's very much like hiring new employees. On Wikipedia, it's done at the board of trustees level, whether the sysadmin is a volunteer or paid, and there's no public involvement. Similarly, on another social networking site I'm on, the job is advertised to the membership, it's conducted purely as a hiring process, and then the membership is informed afterwards of who was hired (who has not always been a previous member...sometimes it's been an outsider). Then again, it is a paid job there, so that's to be expected.
That said, we've previously done this as a public nomination, and in general, I believe that decisions on a wiki should remain public. If we want to make this Dave's decision only, I won't complain, but if anyone other than Dave is to have a say, then I think discussion should be public and transparent. If it's felt that regular users don't have sufficient knowledge or what have you, then we can always restrict comments to patrollers and admins, long-time users, technically knowledgeable users, or whatever else is deemed appropriate.
I don't think it necessarily needs to be at the level of a full RfA, though I'm not sure how else to approach it. I think questions, if any, should revolve around technical knowledge and trustworthiness, though it can be difficult to demonstrate either without posting an entire CV/life story, which I think is overkill. Separate Q&As or nominations, if any, make sense to me because otherwise, it's too easy to gloss over issues that should be raised when you're talking about a group rather than individuals. On the other hand, nobody so far has said "no, I don't think <username> should have access", so perhaps the above discussion is all that's really necessary and Daveh should just make the decision? Gah...I'm so confused!
Lastly, I'm not at all concerned if there's a userbox or not. I use userboxes to inform, not to brag, and I think Jak and Alfwyn are in the same boat...in point of fact, Alfwyn doesn't use userboxes at all. Categories or postings on User Group Rights are more than sufficient to indicate who does what. The User Group Rights page is probably a bit misleading, but I really don't see a need to split the page up just to accommodate a description of what a small handful of people do. Users who know their way around should have an easy way to remind themselves who can do what needs to be done, and for those users to provide a means of indicating their activity and probably a brief description of what functions they normally perform (e.g., database access, re-programming, settings changes, running maintenance scripts, etc.). – Robin Hood↝talk 23:45, 14 November 2012 (GMT)
I've given this matter a lot of thought (given that it's taken two weeks), and I've come to the conclusion that Daveh should make this decision on his own. I'm a huge proponent for the Socratic community, in which everyone has a say in everything, but this situation has no precedent. It is entirely based on maintaining the website itself, and is entirely outside of the community . The critical point is, though, that if it came to a vote, nobody would know what to vote for. Programming skill is subjective - we're all equally skilled at what we'd have to do to fix the website. Strength of character and dedication to the website also aren't problems - otherwise we wouldn't be here right now, offering to do this work for free. It ultimately comes down to what Daveh decides, so I say we just simply let him make the decision. It may seem less important now, considering that there is only one month left in the year, but these new rights are long-term. With them, we can repair the site and maintain it, and also add to it, by updating CSList, creating a Skyrim alchemy calculator, and adding various extensions.
I feel very conflicted, because I really believe in the community, but I think that this is an entirely different decision. As was stated above, if we go through the regular RfA process, it'll boil down to 3 ugly sets of bickering and petty arguments, all of which only divide the site and further delay actually fixing it. • JAT 05:55, 1 December 2012 (GMT)
I essentially agree with Jak, but I don't much care how it happens. I just hope it happens, for the reasons laid out at the outset of the discussion. This strikes me as appropriately being Daveh deciding who can/should help him with certain tasks that he is doing himself now. I don't see any problem with him asking for input, "publicly" or privately, if he wants it. Nor do I see anything wrong with people sharing thoughts or concerns, especially given that a certain level of trust and responsibility is called-for. I think Daveh can decide who he feels comfortable with. I guess he faces consequences at least as serious as any of us if Jak and/or whoever, has been secretly biding their time to get their hands on the server and destroy the wiki, and we have failed to uncover his criminal record as the creator of the MyDoom worm because someone who knew didn't get a chance to share their information on that.
It seems that we (people regularly involved in the wiki) should all know what the role entails, at least once it happens. That would just help us know where to direct any relevant issues/concerns. I don't think we need to be afraid of a discussion, because if people raise issues that seem irrelevant to the role, or are disrespectful, then the rest of us need to learn to object to that. If the people or person given some kind of server access is to be considered an admin, then I would guess that Daveh would want the regular RfA process, but I personally don't really care if he appoints someone. (I know that a number of people might, but I wouldn't.)
If enough of us think that some elements of the consensus process is negative, unnecessary, etc., then I think we just need to better communicate what we hope for and expect. We can't stop making decisions as a community just because it can be a messy business. We just have to do our best to make it better. --JR (talk) 06:40, 1 December 2012 (GMT)
This really shouldn't be a public decision, as very few people will be even able to ask relevant questions about their experience that a nomination will simply be pointless. It won't be about their skills as programmers (what we want), but about their more well known personal traits that aren't all that much important for the job they're asking for. And if they do go to a nomination, it might as well be an RfA for how it'll go and what rights they'd get if successful. Honestly, I felt that you guys should of went to Daveh first already, but that's definitely the only real way this will lead anywhere I imagine. If you want to loop in the admins and patrollers, feel free to. --AKB Talk Cont Mail 11:01, 1 December 2012 (GMT)

(←) Just to follow up on this, Alfwyn, Jak, and I all now have read-only access to the servers, so we can investigate issues, but not fix them (read: not inadvertently screw anything up <g>). Write access to the servers will follow in time, if/when we need it, and once we're all more familiar with how things are set up. I also have read-write access to the CS List and map databases, since that's what I'll be focussing on. – Robin Hood↝talk 03:26, 5 December 2012 (GMT)

Grateful to all three of you. Seems like a good step. --JR (talk) 08:42, 5 December 2012 (GMT)

AbuseFilter

I have three questions to ask about Special:AbuseFilter.

  1. I recently set up the Targeted Spam Filter to block the "Very nice site" spammers. If you find any "Very nice site" spammers get through the filter, any at all, please post a link to the edit so I can see it. I want the filter to block 100% of this spam. I don't mind so much if a couple of other spam edits get through, but I really want to block all of the "Very nice site" spam. It's been a nuisance to our site for who knows how long, and I'd like to see all of it gone.
  2. AbuseFilter has been having problems detecting hyperlinks. For instance, anything beginning with HTTP (in all caps) is not being detected, and numerous other links are getting through the filter. Judging by the related Community Portal topic, there is a major software error going on. Daveh, can you possibly take a look at this?
  3. I've gone through the logs, and of the 4,201 hits in the past two months, the Targeted Spam Filter hasn't thrown a single false positive, so I'm considering setting it to be able to block spammers on sight. I can have it warn then block, or just block. The advantage of warning then blocking is that if in the odd chance a new user just happens to have a spam word in their edit (for instance, by saying "I live in New Jersey") then they won't be blocked on sight. However, many spammers (particularly the "Very nice site" spammers) only try spamming once on the same page. I believe that when we're dealing with blocks, we should always err on the side of caution. However, are people comfortable with the filter having the power to block users? As long as we have a warning first, I think it would be safe to give the filter the ability to block, especially because it (so far) hasn't thrown a single false positive. • JAT 00:08, 13 November 2012 (GMT)
To point three, which is the only one of particular interest in me... I oppose having a filter blocking people.I would rather see a red banner reworded to say something to the effect of "Your (account/IP address) recently created [random URL to edit this revision] to UESP which has triggered our automated spam filters blah blah blah... Spamming isn't cool, and if this is a false positive, then feel free to ignore the notice blah blah." (Obviously, it would be a real notice and not mumbling nonsense like that) Just because it hasn't yet made a false hit doesn't mean it won't, and I would rather someone manually verify warnings than block on sight. Perhaps I am just one to look for the negative in things, but like you mentioned, I can almost see a new editor being blocked after the filter is added because their newly made userpage says "I live in Newark, New Jersey, and I joined UESP after buying Skyrim and this is a very nice site that I look forward to contributing to because (random rant about how we are a Bad-A TES site blah blah blah)". ES(talk•email) 00:48, 13 November 2012 (GMT)
It's already set up to warn the user, and if they try again, to disallow it. The problem is, after their edit is disallowed, they just try again. Many spammers will make 20+ edits before one of them manages to get past the filters. It would make much more sense to block them before they manage to successfully spam. Although I'd normally agree with you, the fact that the filter has been triggered over 4,000 times without a single false-positive is pretty indicative that this isn't going to be a problem. However, I could also set up a new filter, called "Lethal Spamming Filter", that warns then blocks users who use words that are irrefutably spam words (such as "Louis Vuitton"), yet leave potentially ambiguous words (such as "jersey") to only be warned then disallowed.
Also, it doesn't block the phrase "Very nice site" - you can see what phrase it blocks here. It relies on a very specific typo, which is why I'm trying to not make it obvious. • JAT 01:27, 13 November 2012 (GMT)
I'd also prefer that blocking only be done by actual editors (administrators and blockers, who are human) than the filter itself. With something like blocking, even for temporary blocks, I think it's important for an actual person to be the one taking this action. While I love seeing how much our spam issues have improved thanks to the filters, and I think the fact that the Targeted Spam filter in particular hasn't thrown a single false positive is awesome, I still think we need to err on the side of caution here and leave blocking to real humans. — ABCface◥ 02:44, 13 November 2012 (GMT)

Off With Their Head!

User:Dstebbins has been given way too many gentle pieces of advice and referrals to policy for way too long. The editor's talk page reflects a continual string of attempts by others to educate him or her as to acceptable behavior on the wiki since 2009. Recent edit summaries have referred to others as "dumbass" and a troll. I know that others are generally capable of taking care of themselves, but I'm asking for action on my part, because it's causing me a problem. (I'm quite sensitive and delicate, you know.) Although I'm not a patroller, I do spend a certain amount of energy trying my best to make improvements and suggestions where I can, and this kind of stuff is a waste of my time and energy. And, hopefully, action that's appropriate given that there have been so many repeated violations of policy, and after so, so many patient and nice suggestions on how to contribute in a positive way. Puh-LEEZE! --JR (talk) 05:10, 18 November 2012 (GMT)

I'd say to give him one last chance. He comes and goes, and each one is so so far apart that it seems wrong to punish him for such old offenses. If he continues being rude today or in the near future, then it would make sense to, but right now, I don't see it being necessary. Just my opinion. ES(talk•email) 05:13, 18 November 2012 (GMT)
OK, well I didn't really mean off with the head. Maybe just a finger. You've been around longer than me, so your perspective is probably better, but just out of curiosity, another chance before what? There's never even been an official warning. --JR (talk) 05:19, 18 November 2012 (GMT)
The offenses are only far apart because his contributions are far apart. When he bothers to give an edit summary, they're often offensive or combative in some way. Given how many unofficial pieces of "advice" he's received (and ignored), and the fact that his antagonism seems deliberate, I don't see any reason to continue tolerating it. I say a formal warning is justified at this point, and if there are further infractions (whether it's days or months from now, doesn't matter), a block would be appropriate. If he continues to act like a child, treat him like one, and issue a time out to correct his behavior. Minor EditsThreats•Evidence 05:26, 18 November 2012 (GMT)
Consider someone like Jak. Last time I checked his user page, he was apparently still a minor. The thought of an impressionable youth being exposed to filth such as the term "tr*lling" just breaks my heart. Supposed he becomes numb and desensitized to such language. It's only one step from that point to experimenting with porn sites and getting an infection. Stop the madness, I say!!! --JR (talk) 05:54, 18 November 2012 (GMT)
I agree, it's inappropriate, and he's had several informal warnings, so I've added an official warning to Eric's recent post. – Robin Hood↝talk 06:27, 18 November 2012 (GMT)

Sortable tables - aren't.

Not sure when this happened, but I've recently noticed that tables which should be sortable aren't anymore. The weird thing is they're sortable when you edit and preview the page, but then when you save it and view it normally, the sortable features are gone. I'm using the latest Firefox (17.0 - was using 16.0.2, but upgraded just now to see if it would make a difference - it didn't.) on Windows 7. No fancy plug-ins disabling Javascript or anything. (I usually have No-Script, but it's generally disabled for UESP, and to be sure I disabled it completely, and it didn't help.) Is this just me? Or is it affecting everyone? TheRealLurlock (talk) 05:07, 29 November 2012 (GMT)

Can you provide a link to a specific example? I just checked the Child page you just edited and it works fine. Also using the latest version of Firefox, but on Windows XP. — ABCface◥ 05:09, 29 November 2012 (GMT)
Okay, it gets weirder. When I visited Skyrim:Child just now, the sortable features were there the first time. Hit refresh, and they're gone again. Edit the page with no changes and save, and they're back. Refresh again, gone again. Tried doing the same on Dawnstar:Magic, though, and I can't get them to appear under any circumstances except edit and preview. Doing the dummy edit and save doesn't work, nor does any amount of refreshing, purging, hard-refresh, etc. It's bizarre... TheRealLurlock (talk) 05:14, 29 November 2012 (GMT)
If I recall correctly, part of the sortable tables are Javascript-based. Try deleting everything in your monobook.js page and see if the sorting returns to normal. (And just for the record, both pages work fine on multiple refreshes for me.) – Robin Hood↝talk 06:19, 29 November 2012 (GMT)
Seems to have worked - I was using Jak Atackka's sidebar code in there before, but it was just copy/pasted and possibly an old buggy version of it. Now I've just done an include from his page directly and it works. (That said, if we're going to be using this as a standard script option for everyone, it might be better to move it somewhere where it's not just JA's script but the whole site's...) TheRealLurlock (talk) 13:26, 29 November 2012 (GMT)
As soon as Dragonborn is added to the sidebar, I'll clean up the code and then move the code to MediaWiki:collapsible_sidebar.js • JAT 17:06, 30 November 2012 (GMT)

Patrollers should be Blockers

Firstly, I'd like to mention that the default maximum time a blocker can block is only 3 hours, which is hardly enough time for an admin to get on and change it. I'd like more time for blocks.

Secondly, although I'm in IRC most of the time, and I will immediately address the concerns of someone who's reverting vandalism, I rarely ever catch vandals before someone else does. I want to say active patrollers, who are already deemed responsible, they should all get their blocker license automatically without any discussion. Perhaps give that authority after a few weeks or months of patrolling in order to let them get used to the other duties first. I think this will help reduce spam by creating more coverage during times when admins are sleeping or busy, but it will also help reduce work needed by admins, assuming they wont still need to extend each block at a time. Lukish (talk) 08:58, 30 November 2012 (GMT)

I wouldn't have any issue with this, especially if there's a time in between to get the feel for patrolling (say, 30 days?). Also, the maximum time is four hours, though you have to specify that yourself rather than choosing from the drop-down menu. — ABCface◥ 15:57, 30 November 2012 (GMT)
Technically, it's 4 hours, but 3 hours is one of the default choices for blocking, so that's what we usually select. You can always type in "4 hours" if you want to make it just that much longer. Remember that you can re-block if necessary. Also, keep in mind that when blocker rights were first set up, it was intended that they be given out to any long-term editor if an admin wasn't around on an "easy come, easy go" basis.
That all being said, I wouldn't mind if we increased the maximum time to 6 hours. The only trick is that I'm pretty sure that right now, Dave is the only one who can make that change unless/until other people get server access. As far as patrollers getting access, I'd say that as long as they've done well in the position and there are no significant lapses in judgement, blocker rights should be given on request to any patroller who wants them. I like ABCface's idea of a 30-day minimum period, though, just to be on the safe side. – Robin Hood↝talk 18:23, 30 November 2012 (GMT)
In regards to the maximum block length available to blockers, I did have a situation on Nov. 17 where I had to reblock someone three and a half hours after I blocked them the first time. That's rarely a concern, in my experience, and Krusty took care of it mere minutes later. But it might be better to give blockers a block time of five or six hours so admins have ample time to take any necessary further action and to better deter offenders like that who may try to wait out their block. At the very least, adjusting the default choices to include "4 hours" would be helpful.
In regards to giving patrollers temporary blocking rights, it seems to me there are four things Daveh should be comfortable with for this proposal to work. First, the number of people with blocking privileges is less than 20. That number would go up to around 55-60 (although many patrollers are inactive). Second, every current patroller would be given blocking privileges. Third, it would be taking away the decision on who becomes a blocker from the admins and (more or less) giving it to the masses in patroller nominations. Fourth, every prospective patroller from now on would also have to be judged competent for temporary blocking rights. Minor EditsThreats•Evidence 20:33, 30 November 2012 (GMT)
I am all for extending the rights of blockers, but the patroller rank is given out like cake. You just need a few hundred edits that don't suck, and you need to know what the Recent Pages page is. The ability to block a user is a big deal, and I think it should be left to people trustworthy, not necessarily any patroller. There are plenty of patrollers and prospective patrollers who I would trust as such, but wouldn't necessarily know if I would trust with the ability to block other editors. And, as M.E. said, we would triple the number of people who can do it, which is an incredibly excessive number of blockers for a wiki of our size. Yes to extensions, but No to granting the right to patrollers by default. ES(talk•email) 20:44, 30 November 2012 (GMT)

(←) I agree that we do not need to extend blocker rights to all patrollers. We currently have six rather active ones, filling out the ranks will not add much benefit as the UESP almost always has eyes on it that can block now. More importantly, vandalism isn't that huge of an issue right now. Take a look at the block log, you'll see that blocks for vandalism are rather rare. The primary target for blocking right now are spammers, the one kind of issue that blocker rights simply won't due that much to help with. While I would definitely consider any active patroller for blocker rights (it is already pretty much a guarantee that you'll get them if you're already a patroller) if they would request them, I don't think there is any need for conscription when vandalism isn't that much of a problem right now.

Also, I'm fine with increasing the length of blocks blockers can make as well. When I was a blocker, that was one of the things I desperately wanted (along with the ability to block talk page access, but that can't be given as it would also require blockers to be given access to protection rights (which would be giving them enough administrative responsibilities that they might as well do an RFA), as explained here). --AKB Talk Cont Mail 03:25, 1 December 2012 (GMT)

I think the points made about making active patrollers into blockers automatically (or even after a 30 day waiting period) are good ones, and agree that this isn't really a good route to take for those reasons. Anyone can request to become a blocker at any time, and an administrator can grant those rights if they see fit. Nothing needs to change in that regard.
However, it's been a couple weeks without further input, and I do think that extending the maximum time for blockers is something we should act on. All six people in this discussion explicitly stated that they'd be okay with extending the blocking time, so can we go ahead and make this happen? I think six hours is a good amount of time, as it was thrown around a little bit and seems a reasonable balance between too much and too little. — ABCface◥ 04:20, 18 December 2012 (GMT)
I made a request to Daveh to change it. This is that hugely important, but it's better to be safe then sorry. --AKB Talk Cont Mail 00:41, 20 December 2012 (GMT)
This has now been updated. I've also updated the times offered in the drop-down menu to offer 6 hours as one of the default times instead of 3 hours. – Robin Hood  (talk) 20:08, 29 December 2012 (GMT)

Protected Archive

Just a little request, I've gone ahead and archived Easter Eggs and it needs to be protected][Respect the wind][ (talk) 15:59, 1 December 2012 (GMT)

Done. —Legoless (talk) 16:02, 1 December 2012 (GMT)

Random Page Not Working

I clicked on the Random Page button, only to be returned with this message "Sorry! This site is experiencing technical difficulties.

Try waiting a few minutes and reloading.

(Can't contact the database server: Unknown error (10.2.212.15))

You can try searching via Google in the meantime.

Note that their indexes of our content may be out of date."

I'm not sure what is causing this, but I'm bringing it up here as this error has lasted a few minutes and I'm not sure if this is an isolated incident or not. --AKB Talk Cont Mail 14:34, 2 December 2012 (GMT)

I can't access it either - so not an isolated incident. --Krusty (talk) 15:05, 2 December 2012 (GMT)
I've had this problem since I woke up at about 8:30 EST, just for some added information.--Catmaniac66 (talk) 15:56, 2 December 2012 (GMT)
It was working fine for me just until now. I'm getting the same screen as you guys.--Skyrimplayer (talk) 15:58, 2 December 2012 (GMT)
Same here. It might have something to do with the recent upgrade, as the entire site was down. We should wait a little longer to be sure though.--Br3admax (talk) 16:02, 2 December 2012 (GMT)

(←) That's more than enough people experiencing the same issue to send this forward, actually. I'll ask Daveh to look into it. --AKB Talk Cont Mail 16:09, 2 December 2012 (GMT)

And now its working for me XD--Catmaniac66 (talk) 16:18, 2 December 2012 (GMT)
Dang it! It worked for me a few seconds ago, and now it isn't working again. Weird...--Skyrimplayer (talk) 16:20, 2 December 2012 (GMT)

(←) It may be related to outage issue we had briefly this morning from the database drive having no free space. Purging and doing a forced reload of the page seemed to get it working again for me so I'm guessing the various caches had cached a "bad" copy sometime during the outage. Let me know if this doesn't fix it for everyone or if the problem persists. -- Daveh (talk) 16:25, 2 December 2012 (GMT)

Bypassing my cache has fixed it for me, thanks. Silence is GoldenBreak the Silence 16:33, 2 December 2012 (GMT)
It fixed it for me as well. Strange that it didn't work when I tried that previously, but it's nice having it working again. Thanks! --AKB Talk Cont Mail 17:08, 2 December 2012 (GMT)
This issue is occurring again for me, the first time I click it after opening my browser I just get a white page. If I hard-refresh, it works. Also, I was one of the people experiencing recent watchlist oddness as well- I'm not sure if the issues are related. — ABCface◥ 17:50, 11 December 2012 (GMT)

Limit Skyrim Page Creations

Private discussion lead to the conclusion, that it would probably be a good idea to prevent inexperienced users from creating Dragonborn articles in the Skyrim namespace. We did limit page creation (but no talk page creation) to auto-confirmed users when Skyrim was new (AN discussion). I propose to limit the creation of articles in the Skyrim namespace till January 15th, 2013 - around that time the PC version is probably out and all important pages will have been created in the Dragonborn namespace. New users will be able to use UESPWiki:New_Page_Requests for page creation requests. Back then we limited page creation in several other namespaces too, but I don't feel that this will be necessary this time around. --Alfwyn (talk) 14:30, 3 December 2012 (GMT)

Just to clarify, but this is only blocking page creation in the Skyrim namespace. New users will still be able to create talk pages for Skyrim, and page creation in the Dragonborn namespace will be unresticted (at least for the first few weeks). The sole purpose of this is to prevent inexperienced users from creating articles in the Skyrim namespace that belong in the Dragonborn namespace. I am all for this. • JAT 14:44, 3 December 2012 (GMT)
Adding my formal support for this suggestion. —Legoless (talk) 21:10, 3 December 2012 (GMT)
Same. — ABCface◥ 21:12, 3 December 2012 (GMT)
+1 ES(talk•email) 21:13, 3 December 2012 (GMT)
Me too, I'd propose adopting this approach for all new content in "new" gamespaces, but let's leave that til later. Silence is GoldenBreak the Silence 21:18, 3 December 2012 (GMT)

Dragonborn Last Minute Preparation

I was going to post this in the above discussion but since its quite bulkier then that one, I split it into its own topic. The above topic only mentions a single thing we need to do, we had many ideas on the table that need to be known and implemented. That's the reason we occasionally discuss things privately, to get our thoughts in order before going public. Regardless, here is a list of things we should do with an explanation for each action:

  • Semi-protect articles in the Skyrim namespace. This protection is intended to avoid people adding content to the incorrect pages in the Skyrim namespace. As an example, this protection will stop users from adding new items to Skyrim:Artifacts as they should go on a Dragonborn version of that article (reminds me that we never set up a SI Artifacts article, now that I think about it). The only problem is that we'll have to stay on top of updating the Skyrim namespace with relevant links, where appropriate (as in, linking to the Dragonborn Artifacts page from the Skyrim Artifacts page). While I'm unsure of when to unprotect the Skyrim namespace, a week or a fortnight should do with any luck.
  • Block page creation in the Skyrim namespace. This is to direct people towards the Dragonborn namespace, should they accidentally try to add to the articles in wrong place. With this move, we can cut out accidental edits in the Skyrim namespace almost entirely. It'll be one less issue to deal with on release day. Skyrim should be protected immediately, with the page creation protection for the Skyrim namespace ending with the Dragonborn namespace's protection (see below). Just for reference, this is what we did for Skyrim's release. We'll just be doing that, minus the other namespaces being protected. MediaWiki:Titleblacklist-otherns should also be updated.
  • The Dragonborn namespace is to be left open to page creation initially. As this is another expansion being released on the Xbox first, (What, did Beth forget to get Microsoft a holiday present, and they decided to give them another period of exclusivity for their next expansion as a last minute gift?!?) our ability to create pages will not be as automated as it will be in the past. This once again means that the hardest and earliest work is going to fall to the Xbox players out there, sadly. Once we feel that all necessary pages have been created, the Dragonborn namespace will be locked. The purpose is to avoid duplicate articles on the same topic, and avoid pages on irrelevant or unimportant topics from being made. While it's a bit unclear of when we'll need to lock this namespace, hopefully it'll be able to be closed to page creation within a week or two. I can't see it not being done by the new year, at the most.

Implementing these actions will solve a lot of the lesser problems that we don't need to deal with when getting a new expansion pack in our hands. However, the bigger ones (actually adding and improving content) remain. As this is once again an Xbox exclusive, and its released on a weekday, and its released a few weeks before the holidays and a lot of people are busy, documentation and page creation are likely to start off slower than desirable. We must also keep our eyes open for news relating to the PC and PS3 release dates. With Dawnguard, there was no notice of when they were going to release it for the PC, so we must prepare for them not providing any once again. As we only have a few hours to get all of this done, any comments must be provided immediately. --AKB Talk Cont Mail 21:20, 3 December 2012 (GMT)

Support to all of the above pages. Would something be appropriate for lore, since the above tweak from Nephele last year mentions it? Granted, several pages already exist, like Lore:Solstheim, Lore:Raven Rock, etc, so it's not quite so urgent, but there's always the few helpful anons who like to try sticking game related material in there. I hope, and would like to imagine, that nothing would need doing there, but as a first thought, something related to Lore might not hurt, so that our lore writers would have a little more room to maneuver without a mess happening. Even without playing (or even intending to play it), several Lore-relevant articles already appear necessary, like the new Dunmer settlements, the other Dragonborn (Mirak(sp?) can't bother to look) all will undoubtedly need work done in that space.
Like I said, it's just a thought, and I'd like to imagine it to be completely unnecessary, but it doesn't hurt to put alternate ideas on the table. ES(talk•email) 21:44, 3 December 2012 (GMT)
I agree broadly with all of the above. I have reservations as to semi-protecting Skyrim, mostly because I don't see the need. However, as I said above, I feel this is something that should become standard policy for new Games and DLC that requires a namespace. I think that Lore should be new page locked, and probably semi-protected too, as pages such as Hermaus Mora, Alessia, Raven Rock, House Telvanni, etc., will be "targeted" by roaming well-intentioned editors looking to keep us at the top of the pile. I say that this time we do what we can, and learn from our experiences with any of the actions that don't go as well as planned. Silence is GoldenBreak the Silence 22:32, 3 December 2012 (GMT)
I've edited the black list to once again restrict Skyrim with the day almost over and it not being done yet, or there being much of a need for Skyrim articles. I'm not sure about lore as there may be many genuine and desired editions made to it. I'm unaware of a way to protect entire namespaces from editing at once besides a database lock (which I'm unsure if it's possible to do that for a specific namespace), so it'll have to wait until someone more knowledgeable then I can take a look at it. --AKB Talk Cont Mail 01:42, 4 December 2012 (GMT)

Access to MediaWiki Space

I've re-run the maintenance script that clears page protections in MediaWiki space, and it appears to have cleared the editing blocks from pages like MediaWiki:Common.css for patrollers, as was originally intended. Now we can all work on the CSS files. Yay, more work! :Þ – Robin Hood↝talk 02:06, 6 December 2012 (GMT)

spambot

I believe User:91.236.74.114 may be a spambot, as it created a nonsensical/irrelevant page about blogging in an obscure subpage. ThuumofReason (talk) 21:40, 17 December 2012 (GMT)

It's already taken care of :). Thanks, though! ⇠eshetalk 21:51, 17 December 2012 (GMT)

Policy

Since you can't undo a page creation what is the correct thing to do for a spam page? Speedy deletion tag? Even a user page? Warn that user that made their userpage a spam link? I've been away for a while and could use a reminder. As evidenced by the fact that this probably isn't in the right place either XD--Catmaniac66 (talk) 05:47, 24 December 2012 (GMT)

Just replace the content with {{Speed|spam}} and that should do it. Minor EditsThreats•Evidence 06:02, 24 December 2012 (GMT)
Thanks! Again it has been a little while. I figure blanking is still a good measure to do concurrently as well.--Catmaniac66 (talk) 06:05, 24 December 2012 (GMT)
Yes, blanking is a good idea, all the more so if it has external links in it. Oh and this seems as good a place as any...after all, it is the admins who have to delete the spam. :) – Robin Hood TALK 07:52, 24 December 2012 (GMT)
Minor and Robin are right. If you want to read the policy for your own review see our Deletion Policy. If you feel a bit rusty and want to really go over all the policies and guidelines again, see Policies and Guidelines. --AKB Talk Cont Mail 01:17, 25 December 2012 (GMT)


Prev: Archive 28 Up: Administrator Noticeboard Next: Archive 30
Retrieved from "https://en.uesp.net/w/index.php?title=UESPWiki:Administrator_Noticeboard/Archive_29&oldid=2293184"