User talk:Daveh/Archive 2009

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

PM's

- Could you please check your PM's on the forum? I tried sending you some emails, but for some reason it seems you didn't get them. Thanks, Codex 19:24, 5 January 2009 (EST) - :Daveh only pops in from time to time. Direct questions to Rpeh or Nephele if applicable.Temple-Zero 19:30, 5 January 2009 (EST) - ::I know, but this requires someone with admin rights on the forum, and he is the only one with it. Codex 20:25, 5 January 2009 (EST)

Condoning Piracy

It seems you are the owner of this site so you should know you have a user called Daedryon who is posting comments that could seen to be endorsing piracy. First, on the Oblivion:Technical Support page (the comment has since been removed) after which he was warned. He then repeated the offence here.

I'm sure you are aware that web sites and forums have been found to be responsible for illegal activities discussed on them. This comment should be deleted and the user banned from your site. You should also consider reporting him to law enforcement and the Federation Against Software Theft. 207.62.217.252 12:29, 7 January 2009 (EST)

Rename request

The higher ups have requested i change my name, please change it from "M'aiq the liar" to "Poopskin" which is my name on the main forums.

-m'aiq the liar 22:47, 17 January 2009 (EST)

Forums (4)

Hi Daveh, I know you logged onto the forums a few days ago, but could you please log on again soon to upgrade my account? Thanks. --Vargon 15:30, 20 January 2009 (EST)

Vargon is no longer going to become a moderator due to time constraints.--Ratwar 20:41, 22 January 2009 (EST)

More ad issues

When I went to see the changes on your talk page today, I kept getting a security warning from the page and it would refresh about every 5 seconds or so (which made it difficult to investigate and block, as I'm sure you can imagine). The link at the bottom of the page where the ad appears was http://google-adservice.com/gx/Zdx3XUBBOaviddF/. Don't know if that'll help or not.— Unsigned comment by RobinHood70 (talk • contribs)

I just got the same message while browsing the forums. I'm running Firefox.--Ratwar 17:14, 20 January 2009 (EST)

More Requests

Hi, Daveh. Sorry to add to the list of requests here on your talk page, but I wanted to make sure you were aware of two requests on the Administrator Noticeboard that require your attention:

• Please help: A request to install the ConfirmUsersEmail extension.
• Patrollers and External Links: A request to add patrollers to the list of trusted users who are exempt from Captcha checks for external links.

If you could find the time to do these tasks, it would be appreciated. Thanks! --Nephele^Talk 23:04, 21 January 2009 (EST)

I put this here because I don't expect anyone would have any objections to it; adding external images does not require a capitcha, which could be very dangerous if anyone decided to take a ride on the naughty side. Is there any way you can add a capitcha to this? --Tim ^Talk 20:55, 22 January 2009 (EST)

Sorry for the long delay in getting this done. I am around doing stuff behind the scenes and checking the site regularily. I've fixed that one users with an email issue manually for now. Patrollers should be immune to the captcha (haven't tested). External images should trigger the captcha just like an external link (confirmed via testing). If there's another way to imbed external content that bypasses the captcha let me know. -- Daveh 12:50, 1 February 2009 (EST)

Adding an external image through a userbox still gets through. I think your captcha test for external images generally works.--Tim ^Talk

Funny bug

I didn't know where on the UESP to send this to, but I was playing Morrowind today in Vivec and I jumped from the second floor of the foreign quarter canton building onto the top of a gondoliers head, so that I stood ontop of him. When he realised I was there and said something it was really sped up and high pitched. Once I got off him it was normal again, quite funny. I've done it twice now aswell. Sorry if you already have this up on your site :)

Database Bug

Yeah, Necromancer's Moon is throwing mysql errors to people who aren't logged in, regardless of browser. Anyone that logs in is fine though. --Ratwar 20:06, 3 February 2009 (EST)

It seems fine now unless other people are still having a problem. Since it was non-logged in users having the problem I'd guess the Squid cache hit the page and got a DB error and was just serving that. -- Daveh 17:12, 5 February 2009 (EST)

It cleared up later that night (once the activity went down).--Ratwar 18:12, 5 February 2009 (EST)

We got a second problem with it on Oblivion:Orintur today. Different symptoms (just a blank page, no error), but after purging, it came up fine, so it would seem to have the same root cause. I don't know much about server software, but since both of the problems were reported by the same guy, it may be a sign that there are a lot more of these happening that we just don't hear about.--Ratwar 01:24, 9 February 2009 (EST)

The site is definitely slowing down in the evenings (from my POV). It seems that from about 4pm (server time) performance drops noticeably - especially at weekends. Given that Alexa is showing site activity dropping, this seems odd. Is a drive filling up again or do we, perhaps, need to defragment a database? From past experience I'd guess that the drop in performance is related to the problems people are seeing. –Rpeh^{•T•C•E•} 16:47, 9 February 2009 (EST)

(addendum) This edit from Temple-Zero shows it isn't just me. Additionally, I'm getting feedback in IRC that the CAPTCHA/Patroller problem is still happening. Could you take another look when you have time? –Rpeh^{•T•C•E•} 16:51, 9 February 2009 (EST)

We had another server outage today on the entire site. Not sure whether or not this is related to the previous problems. In the past we just let this type of thing slide, but then you spoiled us with decent performance for a few months. --Ratwar 21:20, 19 February 2009 (EST)

I've seen a few temporary slowdowns/outages during the past week but have not figured out the exact cause. It is none of the normal suspects and I'll be poking around the server during the next week and see what I can turn up. If time permits I may order and setup another content server as it seems this is where almost all of the problems seem to be. The squid1 and db1 servers typically run under 1% CPU load with plenty of memory while content1 is almost always 50% or more CPU. -- Daveh 10:05, 21 February 2009 (EST)

I don't know if you saw this on the Community Portal? On at least two occasions where the site was slow at a usually fast time, I spotted what was almost certainly a spider trying to download the whole site. On one such occasion, somebody came into the IRC channel to comment how slow the site when he was trying to download the whole thing. ISTR you spotted people doing this in the past, pre-squid. Is there anything in the Squid logs pointing to a suspect? –Rpeh^{•T•C•E•} 10:13, 21 February 2009 (EST)

The couple of times I noticed the site was slow in past week or so I didn't notice any obvious abuse like this, but that may have been because I was observing the aftermath. Currently there is no limits on the squid to prevent this sort of thing (haven't figured out exactly how when I tried). I'll take another look at that and see if that can prevent issues in the future. -- Daveh 22:22, 21 February 2009 (EST)

Cite Extension Update

When you get a few minutes, could you update our Cite extension to the latest version? Version 1.11 supports groups of references, which is something that has been "wish-listed" as part of the debate on referencing out-of-game lore. Groups would enable us to have separate sections for in-game and out-of-game references, which would help make things clearer and also avoid having to repeat the OOG warning on each book. Thanks. –Rpeh^{•T•C•E•} 06:28, 22 February 2009 (EST)

Can't Edit Whilst Logged In

I don't know if you're changing anything at the moment but I can't edit whilst logged in. Every time I save it tells me the site has lost session data, and logging off and on again doesn't fix it. Things were working fine a couple of hours ago. —Rpeh 10:35, 28 February 2009 (EST)

And it's not an isolated case, I have the same problem. -Gez 10:47, 28 February 2009 (EST)

Yes, I was playing with the PHP session path and had some file permissions setup wrong. Editing works for me now although you may have to log out and back in. Let me know here or in IRC if you still get this or any other errors. -- Daveh 10:57, 28 February 2009 (EST)

banned?

hi. i dont have windows mail, so this was only way i could contact. i tried to log onto the forums, and it said i was banned. i have recieved no messsages or warnings i am aware of, and i have been very careful not to break any rules. can i get an explanation as to why i was banned? i dont wanna make a fuss, but i feel it was uncalled for

thanks Darthblaze99 15:51, 2 March 2009 (EST)

My best guess is that your User account isn't blocked but that the IP with which you access the site and the forums has been blocked in the past. --SerCenKing 15:56, 2 March 2009 (EST)

i am the only one to ever visit this site with this computer. but i am not banned anymore, whether it was a bug or one of you guys unbanned me, thank you so much. i am extremely grateful

thanks!!!!Darthblaze99 16:03, 2 March 2009 (EST)

If you were banned, there would be a notice about it on your talk page. Most likely, your IP was caught in a range that was banned. Or your ISP passed you through a proxy that is banned. Or you have dynamic IP and coincidentally got for a time an IP that was banned. There can be plenty of ways to be caught in an IP block. --Gez 16:09, 2 March 2009 (EST)

Except it sounds like this was a problem on the forums not on the wiki; accounts on the two parts of the site are separate, and bans are done completely independently.

This sounds like an old problem that we've had in the past when the servers have been reorganized: users get out-of-date copies of forum pages -- so instead of seeing the main forum page tailored for your account, you might end up seeing the main forum page as it was just displayed to a blocked user. Were you using an up-to-date link to the forums, i.e., were you connecting to http://forums.uesp.net ? If you have any old bookmarks to the forums, they should all be updated to be forums.uesp.net links. If this problem did happen even when using forums.uesp.net, please let us know, because then it could be an indication that our recent server upgrades had some unintended side-effects. --Nephele^Talk 17:05, 2 March 2009 (EST)

Code Updates

You've obviously seen the news at the admin noticeboard. On the offhand chance that you're interested in getting started, I've uploaded the first set of files to content1. This contains the updates to convert ActiveUsers into a true, standalone extension. It does not do any of the fancier updates advertised on the admin noticeboard; those are all being done by the UespCustomCode extension.

The new ActiveUsers code is all in my home directory on content1, in edits/ActiveUsers . There's an INSTALL file there (edits/ActiveUsers/INSTALL) with the details of what needs to be done. Also, if you need the vanilla versions of some of the mediawiki 1.10 files (after the extension is installed), I'm putting clean copies of any relevant files into edits/mw10.

Hopefully that's enough explanation, but if not, let me know! --Nephele^Talk 22:06, 15 March 2009 (EDT)

OK, the second, more complicated extension, UespCustomCode, has been uploaded, again to my home directory on content1, in the edits/ directory. And, again, there's an INSTALL file (edits/UespCustomCode/INSTALL) with details of what to do. This is the extension that includes the promised fixes and tweaks, along with a lot of code reorganization.

Hopefully since you're familiar with the extent of our customized code, you're not expecting this extension to magically clean up everything overnight. Because, if so, you'll probably be somewhat disappointed ;) The process of disentangling our customizations from the core code is going to be a work in progress for a little while yet. What I've aimed to accomplish is:

• Where it's possible to completely move the UESP customization into an extension, I've done so.
• Where it's not possible to completely move the code, I've moved as much as possible. Therefore, in the mediawiki file multiple lines of UESP customization have been replaced by a single function call.
• But where I know that the UESP customization is going to be made obsolete by upcoming mediawiki changes, I've just ignored that code (i.e., left the mediawiki file in its current customized, non-vanilla state), and not even bothered to try to figure out how to clean up the file.
• Furthermore, where I think that mediawiki should make our customizations obsolete (i.e., where we're fixing a recognized bug in the mediawiki code), I'm working on getting mediawiki to make the change. Assuming that it will happen, I'm again ignoring our current customized file.

What that all means is that at this point the extension only allows three mediawiki files to be restored to vanilla versions (all related to our heavily-customized search features). Three other files have been cleaned up, so they are closer to vanilla, but not there yet. And on the particularly-annoying side of things, I've also had to add tweaks to two previously vanilla files -- but in both cases, those tweaks will be unnecessary after the next upgrade. Then there are another dozen-plus files that aren't being touched at this point (because our customizations will be or should be made obsolete).

In the not-too-distant future, however, we should be able to do much better. Assuming that I can successfully pester the mediawiki folks and get my set of bug fixes incorporated into the core code by MW1.15, then after upgrading to MW1.15 we'll be down to just three non-vanilla files left in the mediawiki directories -- with just 29 lines of code, total, added to those three files (specifically, Parser.php, Sanitizer.php, and MonoBook.php). If I can muster enough motivation to continue submitting code patches to mediawiki, I think it may eventually be possible to reduce that even further -- at least for two of the three files, adding some extension-friendly features into mediawiki's code would benefit wikis other than just UESP.

So hopefully by keeping to a long-term perspective, the switch to an extension will seem worthwhile ;) Also, I'm hoping that the actual installation shouldn't be too much work -- the only edits you have to make are to LocalSettings.php, otherwise it's just moving files around. And checking pages on the site a few times along the way to make sure nothing has exploded! As always, let me know if you have any questions or problems. My schedule is a bit strange this week, but I'll check the site as often as possible. --Nephele^Talk 00:52, 18 March 2009 (EDT)

Great stuff! I've been wanting to do something along these lines but never had enough time to devote to it. I should have time to look at it this weekend sometime. Thanks! -- Daveh 10:04, 19 March 2009 (EDT)

I've posted a slightly updated version of UespCustomCode on content1. I've also posted a preliminary version of yet another new extension, MetaTemplate (see here) -- just on the offhand chance that the other two extensions go so quickly and smoothly that you're motivated to do another ;) Again, it's got some instructions at MetaTemplate/INSTALL. Also I'll be in IRC most of the day if you do start tinkering with some of this stuff and have questions. Or if you don't get to it until later, if you give me a heads up I'll try to make myself available in IRC then. --Nephele^Talk 12:41, 22 March 2009 (EDT)

Sorry for the delay...didn't have time this weekend but am looking at things now. ActiveUsers has been updated on content1. I assume you're aware that to test things you need to change the site's URL from www.uesp.net to content1.uesp.net, otherwise you'll randomly hit content1 and content2 (which hasn't been updated yet). Am looking at UEspCustomCode now...will see how far I get tonight.

Another quick note relating to content2: the site files (i.e., everything in /home/www/uesp.net/) is just a copy of everything on content1 (I'm almost sure, will double-check). So once the upgrade on content1 is done it is a simple matter to rsync the changes all at once. -- Daveh 21:47, 25 March 2009 (EDT)

Updating as I go for the UespCustomCode work...

• Directory moved (cp -r UespCustomCode works fine)
• Minify script run
• Wiki.php updated
• LocalSettings.php modified. Note that I currently disabled $configdate to prevent the site from overloading during the peak hours. Will reset tomorrow morning. This will only affect anonymous users.
• Updated Skin.php, MonoBook.php, Parser.php and Sanitizer.php.
• Restored SearchEngine.php, SearchMySQL.php and SpecialSearch.php.

Done, and nothing's on fire...yet. -- Daveh 23:26, 25 March 2009 (EDT)

Thanks, Dave! Things look good so far -- although I only just got back from dinner and a long day at work, so I can't say I've looked too closely yet ;) There was one inconsistency on Shivering:Sandbox, but it was fairly superficial (the code you added was working properly, but I'd then messed up a wiki version of a file; I just got rid of the now-unnecessary wiki version). At this point, other editors are probably better judges than me of whether or not things are working -- I've stared at some of these pages so many times that I'm going cross-eyed. --Nephele^Talk 00:23, 26 March 2009 (EDT)

I didn't review all your code very much but I didn't have any issues installing things and haven't noticed any obvious errors on the page or in the error logs. As usual just let me know of any problems or additional changes. -- Daveh 00:29, 26 March 2009 (EDT)

There seems to be something odd going on with searches -- the "go" button is working, but standard searches don't seem to be finding any matches. This hasn't happened on my test wiki, and I'm not sure what would be different on UESP. I'm having a hard time right now figuring out what's going on, but my brain should be working a bit better tomorrow when I'm not so tired. --Nephele^Talk 01:08, 26 March 2009 (EDT)

I may have a theory about what's going on with searches, primarily based on the fact that there should only be one bit of code that has changed in the section of processing that is messing up: the queryMain function in UespSearchMySQL.php. Basically, I'm guessing that query is being processed differently on UESP, perhaps because UESP is using MySQL 4.0.27 but I'm using MySQL 5.0.37, coupled with the possibility that the query is running into obscure differences between text searches using MyISAM and InnoDB tables.

Techno-speak aside, I've posted a revised version of UespSearchMySQL.php in my edits/UespCustomCode directory. After installing it, you could try comparing the two following searches:

• content1 version, currently coming up empty
• content2 version, correctly finding multiple titles and multiple articles

For good measure, it's probably best to do Ctrl-F5 on those pages to bypass caches.

If that still doesn't work, my next suggestion is primarily to narrow down what's happening: delete (or comment out, if you're feeling less dramatic) the entire queryMain function from UespSearchMySQL.php. The code will end up just using the default version of queryMain from the parent class; the "fix" that gets removed in the process is the fix that prevents Description and Author pages from showing up in searches. After that either: the content1 search above will work, but just list too many pages (which is an improvement over the current situation); or, the content1 search will still come up empty, in which case I'm back to square one with debugging ;)

--Nephele^Talk 13:23, 26 March 2009 (EDT)

Updating UespSearchMySQL.php seems to have done the trick. -- Daveh 15:10, 26 March 2009 (EDT)

Thanks! It's a relief to know what was causing the problem.

One minor issue when you get around to messing with content2: could you check the clocks on content1 and content2? It seems like they might be out of sync. It's only by one or two minutes, but it causes some confusion in recent changes or page histories because edits will end up listed out of order (i.e., a fix to a new paragraph [1] appears to be added one minute before the paragraph itself is added [2]). --Nephele^Talk 15:56, 26 March 2009 (EDT)

OK, one more problem... and this time it's definitely a SQL4 vs SQL5 problem. For now, I think it's best to disable the customized version of Special:Lonelypages; you can do that by commenting out the one line starting "$aSpecialPages['Lonelypages'] =" in UespCustomCode.php (line 182 by my count). It will take some work on my side to figure out a way to write the SQL query that would be acceptable to SQL4 -- if it's even possible. --Nephele^Talk 16:46, 26 March 2009 (EDT)

Time issue fixed (hopefully) by making sure ntpd was starting on content2. -- Daveh 19:51, 26 March 2009 (EDT)

I've posted a new set of UespCustomCode files in the usual place. This includes an update to UespSpecialLonelyPages to tackle the above problem, a bug fix for this SQL Error, a tweak to defaultsort (see here), and a potential fix to our perennial problems with large categories. The following is a list of files that have been changed; if you want to copy them one at a time, the provided order should work well for copying. Or just copy over everything from the UespCustomCode directory at once:

• UespSpecialLonelypages.php
• UespSearchMySQL.php
• UespNamespace.php
• UespCustomCode_body.php
• UespCustomCode.php
• mw10_modified/Parser.php (which needs to overwrite the w/includes version of Parser.php)

One thing to check a few days after installing these changes is whether there's been a noticeable drop in cache usage: I've turned off cacheing for all category pages. I doubt that category pages are a significant fraction of page views, so I don't think it should really change things too much. Furthermore, overzealous cacheing of category pages is causing problems with multiple reader complaints. Nevertheless, it's always good to check.

Also, there's one other suggestion that I made on the admin noticeboard, namely an alias for the Tamriel namespace, that requires a change to LocalSettings.php. It's probably best to do this change when you're ready to also activate all these changes on content2 -- because otherwise the differences between the two content servers could be really confusing (OK, they're already pretty confusing when trying to test out these code changes, but with the Tamriel change the confusion is more likely to be noticed by the site's readers). What needs to be done is:

• add the following lines (for example, after the wgExtraNamespaces definition):

$wgNamespaceAliases = array('Tamriel' => 130,
                            'Tamriel_talk' => 131);

• change the first two lines of the wgExtraNamespaces definition to:

        array(100 => "Tamold",
                101 => "Tamold_talk",

This takes care of all the identified issues with UespCustomCode, so hopefully this will be the last necessary update for that extension. As for the next extension, MetaTemplate is ready (when you're ready, that is!). In particular, there shouldn't be any MySQL4 vs MySQL5 discrepancies with any of that code. --Nephele^Talk 16:48, 30 March 2009 (EDT)

• Tamriel namespace changes done on content1 and 2.
• Code changes updated on content1.

-- Daveh 23:28, 6 April 2009 (EDT)

Thanks! Checking around it seems that all the changes worked. I'm particularly happy to see that the category fix is working (of course, only on content1). The only change I haven't tried to test here on UESP is the defaultsort change, because it would be pretty tricky to reliably check with the two content servers doing different things -- but I have tested it on my test wiki. --Nephele^Talk 00:36, 7 April 2009 (EDT)

Rpeh pointed out some new problems, so yet again, new code. The files that need to be updated are:

• UespCustomCode.php (mainly to update notes and version)
• UespNamespace.php (the real fixes)
• UespMonobook.php (some minor changes purely for my convenience, but might as well keep all copies in sync)

Also, at this point I think the major features in UespCustomCode are pretty stable. These latest tweaks are just in new functions -- so they won't affect any readers until we decide we want to start using the functions. In other words, I'm pretty comfortable with adding the new code to both content1 and content2 -- but it's your call :) --Nephele^Talk 11:58, 7 April 2009 (EDT)

• Latest three updates done on content1.
• content2 wiki code copied from content1. Both should be identical now.

-- Daveh 19:53, 7 April 2009 (EDT)

Thanks! I just wanted to also point out that the MetaTemplate extension is also ready for installation -- in part because Rpeh keeps bugging me about when MetaTemplate will be made available ;) In a nutshell, it's an extension that introduces a lot of new features that can be added to templates -- some of which should improve site performance, some of which should make our templates more powerful, and some of which should simply make our templates less confusing. It's sitting in my edits/MetaTemplate directory, and has an INSTALL file with full details on what's necessary to install it -- although the installation is pretty simple and shouldn't take more than a few minutes to complete.

This extension is still somewhat experimental, and probably will continue to gradually be improved. In case that's a cause of concern, I don't really think it should be:

• There's a minimal chance of unexpected effects on the rest of the site:
  • The features are all implemented as true extensions, and therefore do not require any modifications to Mediawiki code.
  • The features are only enabled if specifically requested on a given article (using the new tags and parser functions added by the extension), so they'll have zero effect on the site until templates/articles are modified.
  • We're planning to do a lot of tests of the new functions before adding them to articles -- but we can't start those tests until the functions are available on the site. Thus the interest in getting the extension installed sooner rather than later ;)
  • I've done about as much testing as I can on my test site, so I don't think delaying implementation on the site any longer will increase the extension's stability.
• Although the extension is likely to be modified/improved with time, that won't mean a unending stream of requests for you to update the extension:
  • Since the extension doesn't affect readers yet, there should not be any urgent need to fix any identified problems.
  • I don't want to release updates any more frequently than once per week.
• The extension works with our current Mediawiki version -- no other upgrades or preparation are necessary before installing the extension.
  • In fact, MetaTemplate will not work at this point with MW1.14 or MW1.15 -- if you were hoping to upgrade mediawiki in the near future, I can get the necessary changes made to MetaTemplate. MetaTemplate now works with both MW1.10 and with up-to-date Mediawiki, so there will be no problems with upgrading mediawiki after the extension has been installed (just check the INSTALL notes for some core mediawiki files that need to be changed).

Let me know if you have any questions! --Nephele^Talk 16:54, 11 April 2009 (EDT)

There's a really minor followup change that I just realized is needed, namely adding the following line to LocalSettings.php

$wgStyleVersion= '64'

That's necessary to let everyone know that the .css and .js files have been updated; until it's done, I can't safely clean up a ton of duplicate css and js in the site's Mediawiki versions of the files. It needs to be done on both content1 and content2. Thanks! --Nephele^Talk 22:29, 17 April 2009 (EDT)

One more fix is necessary to deal with this bug. I've placed new versions of UespNamespace.php and UespCustomCode.php into edits/UespCustomCode; they need to be copied to both content1 and content2. Thanks. --Nephele^Talk 17:02, 20 April 2009 (EDT)

• Updated UespCustomCode extension on content1.
• MetaTemplate installed on content1.
• $wgStyleVersion updated on content1.
• content2 synced from content1. See below for an issue encountered after doing this.
• $configdate reset on content1 and content2.

-- Daveh 20:31, 23 April 2009 (EDT)

Issue: The above updates seemed to work fine on content1 but after syncing content2 there was an issue. Nothing is displayed with the error:

   [Thu Apr 23 20:59:06 2009] [error] PHP Fatal error:  Unsupported operand types in /home/www/uesp.net/w/languages/Language.php on line 1745

Nothing seems wrong on content1 and content2 is just a direct copy of content1 (as I've always done). The offending line is just:

   $this->namespaceNames = $wgExtraNamespaces + $this->namespaceNames;

Nothing seems wrong with $wgExtraNamespaces and it is the same on content2 as on content1. Still looking into it but thought it might be something obvious to you and not myself (not yet anyways). -- Daveh 21:05, 23 April 2009 (EDT)

A little more.... Reverting to the previous Wiki version on content2 has no effect. It still gives the same error code. -- Daveh 21:19, 23 April 2009 (EDT)

Fixed: Although I'm not sure of the exact cause. The issue was the memcache was stale on content2 and $this->namespaceNames was returning NULL. Manually forcing the cache to be invalidated once in Language.php got things working again. -- Daveh 21:32, 23 April 2009 (EDT)

Thanks, Daveh! At first glance, everything looks good. And maybe the stale memcache is also at the root of the image issues. If nothing else, content1 and content2 now agree on the status of a few of the problem images (although they now both agree that the images are missing, instead of both agreeing that they're there -- but that's consistent with the fact that there was never a meta-data entry for those problem images in the database; I'll work on fixing that now that the inconsistency between the servers is fixed). I'll try to keep an eye out for any new image problems over the next few days; hopefully there won't be any more! --Nephele^Talk 22:54, 23 April 2009 (EDT)

Ughh.... Now the problem seems to be occurring in reverse: content1 is ignoring the database information, whereas before it was content2 that was ignoring the database information. Since the problem is happening on content1 this time around, I might have some more luck diagnosing what's going on, so I'll root around for a while. --Nephele^Talk 23:17, 23 April 2009 (EDT)

Name change

Hey, I was wondering if I could get my name changed to fallenangle. If that name is not available, then fallenangle2350 should be. So, would you be willing to do this for me?

"Angle" or "Angel"? -- Daveh 11:58, 28 March 2009 (EDT)

Angel, my bad. lol Jesus lover^{•T•C•E•JS•} 13:08, 28 March 2009 (EDT)

Done! You are now known as "Fallenangel". -- Daveh 23:23, 6 April 2009 (EDT)

Urgent: Possible Disk Space Problem

We're having problems with the latest images uploaded to the site, and the most likely explanation that I can think of is that the partition used for images on db1 or content2 is full (and I can't login to either of those computers to see what's going on).

Specifically, the problem is with Image:TR4-place-Abecean_Ocean.jpg -- the last image uploaded to the site. If viewed on content2, content2 claims that "No file by this name exists" -- although it shows that the page has a file history:

• content2

On content1, the image displays without any problems:

• content1

I've tried purging the image on both content1 and content2, but purging didn't work

So the database clearly thinks that the image exists, but the image is missing on content2. The only reason I can think of for a missing image (especially after a purge) is that there is not enough space for the image file. Although your last file space check shows enough total space on both db1 and content2, it's not clear whether the partition specifically used for images has enough space. If you could check that sooner rather than later it probably will prevent a lot of problems if anyone tries to upload even more images. Thanks! --Nephele^Talk 13:24, 6 April 2009 (EDT)

The image is "there" on content2. The current setup has the physical /images storage on content1 with it being shared via NFS on content2. So unless the NFS share breaks everything on content1 has to be on content2. Eventually I may move the images store to its own server and shared by NFS to all content servers.

I'm not sure why the Wiki on content2 thinks the image isn't there. No immediate ideas but I'll look into it. -- Daveh 14:12, 6 April 2009 (EDT)

Hmm... quite a mystery, then. The version of the image that actually is supposed to be shown on the image page is the thumbnail, but that also is being seen by content2. One oddity is that the 800px image is actually coming out as a 799px image, but I tried artificially copying the file to an "800px-" name, and it still didn't work. I'll root around in the code a bit to see what content2 is really checking when it decides that the image doesn't exist. --Nephele^Talk 14:23, 6 April 2009 (EDT)

Would any of your code changes affect the images? I haven't updated content1 with your most recent updates and content2 is still running the original version with none of your updates. -- Daveh 15:51, 6 April 2009 (EDT)

I haven't done anything that should affect images -- other than the one patch you installed years ago, but that should be running on both content servers (plus it's only relevant to thumbnails, and I don't think content2 is even getting as far as recognizing thumbnails). A really remote possibility is having configdate unset on content1 but set on content2. It mainly comes to mind just because my test codes get error messages about it. Plus it ends up trickling down into obscure parts of the code that check caches, and so it could theoretically cause differences between the two servers.

Overall, I'm still baffled, and about to give up for now. But first to summarize what I've been able to decipher from the code:

• The only place that generates the "No file exists by this name" message (ID 'noimage') is ImagePage.php, in openShowImage(). That message is generated if the "$this->img->exists()" test fails.
• That tracks to Image.php, where the exists() function just returns the value of the image's fileExists flag (after loading the image, if that has not yet been done).
• Between caching, shared images and other options, there are several places in the code where fileExists can get set.
  • However, for content1's settings (in particular, if $wgUseSharedUploads is false), fileExists should ultimately only be determined by whether or not the image has an entry in the database's image table. Specifically, loadFromDB() queries the database; if it finds a row of data, it sets fileExists to true, regardless of whether or not it can find the file on disk. I'm assuming that query must return the same result on both content1 and content2. I also tested the query myself with a bit of test code, and the query returned a row of data. So I don't see how the loadFromDB() function can possibly do anything different on the two content servers, nor how it could set fileExists to false.
  • For content1's settings, the only other way to set fileExists is from the cache values of the image's metadata -- but that's just going to be the same as the values originally determined by loadFromDB(). If there's a problem with the cache, it should just skip reading the cache and do the original load again. In other words, again, we're back to loadFromDB().
  • There is another load function, loadFromFile(), that sets fileExists based upon an actual check for the file on disk (the standard PHP file_exists() function). But loadFromFile should only get called if $wgUseSharedUploads is true -- which it's not. Or if the database entry needs to be upgraded -- which it shouldn't (it's a new entry, plus the DB entries that it checks should all tell it no upgrade is needed). Even if loadFromFile() were to be called, it seems that it should find the file -- based on our ability to see the image on content2 -- unless there's some error in the settings for $wgSharedUploadDirectory or $wgUploadDirectory (i.e., if the local paths are being set incorrectly -- even though the URL paths are correct), or if somehow hashed directories have been turned on ($wgHashedUploadDirectory=true or $wgHashedSharedUploadDirectory=true).

So the only incomplete grasping-at-straws quasi-explanation that I can find right now would be if $wgUseSharedUploads (and probably a couple of other $wg image-related variables) are set differently on content2 than content1. Or some other difference on content2 (different version of Image.php or ImagePage.php?) None of which would explain why this single image would be a problem.... So, baffled ;) --Nephele^Talk 16:24, 6 April 2009 (EDT)

Nothing obvious is set differently on content2 than on content1. I also couldn't find any logged errors related to the page. I re-uploaded the image and it seems to work now. Hopefully this is a "one-time" error because I have no idea how this sort of thing could happen. The only thing that comes to mind is some library version that is different on the two content servers but even that is a long shot. Let me know if you or anyone else sees any other bugs like this. -- Daveh 20:05, 6 April 2009 (EDT)

Yep, I agree we probably just have to wait and see what happens with the next batch of images that get uploaded. And cross our fingers ;) --Nephele^Talk 00:38, 7 April 2009 (EDT)

Just in case this is related... I view thumbnails at 300px width, and when I go to Oblivion:Cloud Ruler Temple, I get this image. That's actually a thumbnail for the previous image rather than the current one. The same happens at 150px and 200px but not 100px or 250px. It might not be relevant but I thought I'd mention it. –Rpeh^{•T•C•E•} 13:28, 7 April 2009 (EDT)

Whatever is going on there is really old -- the revised image was posted in August 2007. Checking file dates on the server, the 100px, 180px, 250px, 800px, and 1024px thumbnails were generated after the new image was uploaded, but the other thumbnails were all older (120px, 200px, and 300px, and 319px from February 2007; 150px from Aug 15 2007). So the bad thumbnails were generated from the previous image and simply never got replaced. Loading a new image should have triggered a purge of the image thumbnails, but it didn't; after the image upload I think the only request that would trigger a purge is explicitly purging the image. I went ahead and purged the image, and everything functioned as it should: all the thumbnails were cleared out, and new ones using the correct image were automatically generated each time I pulled up a page that used one of the thumbnails. (Sorry, in the process I've destroyed all evidence of the problem -- but it was the only way to test whether there really was a problem).

At first I was thinking perhaps the original problem occurred was even before thumbnails were fixed, but thumbnails were fixed in October 2006. So that's not the reason. However, at this point, it's pretty hard to guess what else might have prevented the thumbnail purge. I'd guess it was just something transient -- connection timed out, server rebooted, job queue got cleared, etc. Since purge did what it was supposed to, I don't think there's any real problem with that image. --Nephele^Talk 14:36, 7 April 2009 (EDT)

That's weird. I must have purged that image a dozen times... Anyway. It's definitely working now. Thanks! –Rpeh^{•T•C•E•} 14:41, 7 April 2009 (EDT)

(outdent) Just had the same problem with this image. It's okay now, but it's still a bit odd. –Rpeh^{•T•C•E•} 14:15, 8 April 2009 (EDT)

Here's another even stranger one. This image doesn't, apparently, exist. Now take a look at the page that uses it - this one. For an image that doesn't exist, it shows a reasonable color balance for a tricky inside shot, methinks :)

I looked at the server status pages for the two servers during this recent bout of uploading. Content1 was fine, but content2 was absolutely maxed out. Perhaps that has something to do with it? –Rpeh^{•T•C•E•} 14:55, 10 April 2009 (EDT)

Hmm. While typing that one, the image suddenly appeared. Delay in copying from one server to the other? –Rpeh^{•T•C•E•} 14:55, 10 April 2009 (EDT)

Sorry - another update. That previous image, and this one both exist as images, but the actual image page doesn't. Look at either one and you'll notice that the "file" tab at the top is red. Clicking the (blue) edit button gets a message that the page doesn't exist yet. –Rpeh^{•T•C•E•} 14:59, 10 April 2009 (EDT)

Well, at least it's possible to create those pages to fix the problem. (I left the other one alone on purpose.) --Gez 17:35, 10 April 2009 (EDT)

Except creating the page just masks the problem; it doesn't really fix anything. If you scroll down on Valna's page there is still no "File History" section of the page; it still lists that no revisions of the image have ever been uploaded (compare, for example, to a non-broken image). And it doesn't change the real underlying problem, which is that according to the database neither of those images exist. I just ran some test SQL queries on content1, and they showed that there is no entry for either image in the database's image table. So somehow the image upload managed to save the file itself to disk, but did not manage to write the metadata for the image to the database. I'll poke around a bit more, but I doubt there's too much more I can find out -- especially if the actual upload happened on content2, since I can't see any of the logs for that server. --Nephele^Talk 17:51, 10 April 2009 (EDT)

Of course, I then immediately notice something else ;) These two images are another case of content1 and content2 behaving differently. The content1 versions ([3], [4]) both say that no such image exists (although the image definitely exists in the image directory on content1), whereas the content2 versions ([5], [6]) both display the image, but with no file history.

There has to be some difference in image settings on content2. Based on what I tracked down with the first of these problems, content1 is doing what it's supposed to according to the image settings: checking the database to find out whether the images exist, and not doing any checks after that. In all of these cases, content2 is not relying solely upon the database information, which only happens if $wgUseSharedUploads is set to true on content2 (whereas on content1 it is definitely set to false). --Nephele^Talk 18:00, 10 April 2009 (EDT)

Content2 is using an exact copy of the Wiki on content1. Just checked to confirm and $wgUseSharedUploads is indeed false on content2. Still not sure what is happening. -- Daveh 20:58, 10 April 2009 (EDT)

To help figure out what's going on (or at least narrow down the possibilities a bit), I put together a script that dumps out the final settings being used by the wiki for a whole bunch of image-upload related variables. The script is in my "other" directory on content1 with the name "imagestat.php"; you should just be able to run it by typing "./imagestat.php" once you're in the other directory. It might be useful to see what the script generates if it's run on content2, and specifically whether there are any obvious differences from what happens on content1.

Also, I made another script that I've been using for testing specific images a bit more user-friendly, it's in "other" at "testsql.php". You can use it to directly query the database to see whether a particular image exists in the database, either using an exact image name or a SQL 'LIKE' expression. If you just type "./testsql.php" it will provide some examples of how to use the command. --Nephele^Talk 15:52, 11 April 2009 (EDT)

(outdent) Got another one. On content1 it works fine; on content2 there's a page but no image. At least it's not just me! –Rpeh^{•T•C•E•} 02:56, 12 April 2009 (EDT)

And more: Lothanis map on content2 works, Lothanis map on content1 doesn't; and inversely Grurn on content1 works, but not Grurn on content2. --Gez 17:01, 24 May 2009 (EDT)

I re-uploaded the map directly to content1 and Grurn directly to content2, which seems to have fixed both problems, but there may be other cases that need fixing. –Rpeh^{•T•C•E•} 23:34, 24 May 2009 (EDT)

FYI, you don't have to actually re-upload the images any more. Based on this followup to this problem, Daveh added a a code fix so that any image oddities can now be fixed by purging the image on whichever server has the problem. In other words, if Image:TR3-map-town-Llothanis.jpg is incorrect on content1, then you need to use this URL to force it to be purged on content1. That will fix the problem without any need to re-upload the image. --Nephele^Talk 23:55, 24 May 2009 (EDT)

Forums robots.txt

It looks like we don't have any robots.txt file to limit the googlebot/yahoo crawler/other search engine bots from flooding the forums with mostly unnecessary requests -- and it seems that the bots to have a tendency to really hit the forums with a lot of requests. After checking to see what other phpbb sites have done for robots.txt file, I think the following would be a good start for UESP:

User-agent: *
Disallow: /faq.php
Disallow: /groupcp.php
Disallow: /login.php
Disallow: /memberlist.php
Disallow: /modcp.php
Disallow: /posting.php
Disallow: /privmsg.php
Disallow: /profile.php
Disallow: /search.php
Disallow: /templates/
Disallow: /admin/

Crawl-delay: 10

This should be placed in the file /home/www/uesp.net/forums/robots.txt

It will still allow the bots to scan the actual forums and threads -- just stop them from trying to access a bunch of pointless stuff, like private messages, memberlists, member profiles, control panels, etc. And hopefully some of the robots will respect the crawl-delay command and stop making 50 requests at the same time. --Nephele^Talk 13:16, 16 April 2009 (EDT)

Also, I think the IP 192.31.106.34 needs to be blocked in iptables. Three times today content1 has become nearly completely unresponsive -- I couldn't even get a server-status report for nearly ten minutes. On two of those occasions, when I did finally get a server-status report 192.31.106.34 was using dozens of connections to forums.uesp.net (44 this last time around), nearly all of which had been connected for multiple minutes -- they ended only being closed when the server forced the connections to time out. I can't believe it's a coincidence that this particular IP (which reverse DNS's to a proxy server) dominated the server-status report on two separate occasions where the server stopped responding. --Nephele^Talk 01:57, 17 April 2009 (EDT)

Same thing just happened again, also for around 10 minutes. This time it was 192.91.171.42 with 47 connections. That's the same company as before (Nephele's IP resolves to proxy1a.external.lmco.com; mine to proxy1d.external.lmco.com - to save you doing the lookup).

Would it be possible to give admins access to the iptables file? Not through the wiki I know, but through ssh? It's frustrating to know what is happening but be powerless to stop it. –Rpeh^{•T•C•E•} 09:00, 17 April 2009 (EDT)

And again. Content1 was out for the count. This time it was 192.31.106.34 again. –Rpeh^{•T•C•E•} 09:45, 17 April 2009 (EDT)

Okay, this is beginning to look like a concerted attack. There have been a lot of connections recently from 24.199.158.10 and 78.159.112.179, both of which have some form as open proxies according to Google. In general, I'm getting about 50/50 forums vs wiki split on server status pages at the moment, when normally it's more like 1/25. The two lmco IPs are by far the worst offenders, though. –Rpeh^{•T•C•E•} 09:58, 17 April 2009 (EDT)

I added the forum robots.txt this morning and just banned 71.233.232.133 on content1 due to taking up a bunch of connections related to the forums. I'll see if there's any easy way to prevent this sort of thing without breaking anything. Currently squid1 is only working with the main UESP site. All the sub sites (dungeonhack, the forums, EQWiki, etc...) are still directly connected to content1 (was much easier setting up the cache to work with only one site and the UESPWiki is 99% of the connections anyways). So any connection abuse like this can mess things up whereas on the main site the squid handles the abuse much nicer. -- Daveh 16:59, 17 April 2009 (EDT)

Just thought I'd let you know that the IP range 192.31.106.30 - 192.31.106.39 has been blocked. The continued requests stalls the entire forum, and makes it completly inaccessible. -Codex 15:12, 22 April 2009 (EDT)

Image Uploading Problems

This is something of a followup to this discussion. I've done a lot of image-uploading today and there are definite problems with content2.

At apparently random intervals, uploading an image causes some kind of lock that completely fills up content2 and causes the upload to take about 5 minutes instead of a few seconds. Take a look at the recent upload logs. You'll see that most of the time, I was uploading two or three images per minute (which in itself is slower than it used to be) but then there's suddenly a large gap. For instance, the gap between Image:TR3-npc-Garnos Otheril.jpg and Image:TR3-npc-Garath Duril.jpg is six minutes. During that time, my browser was "loading page" and content2's server status page was showing a full list of W entries - mostly on /w/images files.

This evening I uploaded another few images and the same thing happened. This time I saved a copy of the status page to illustrate the problem: you can see it here.

None of this was caused by me slamming the server with a dozen simultaneous requests. I was pressing "Upload", waiting until the upload completed, and then waiting five seconds before doing the next one. In contrast, when it came to saving the updates to the wiki pages to use the new images, all updates were complete in seconds.

To summarise: there's definitely a problem, but I have nothing like enough knowledge of wiki software to suggest anything else. I'm sure I'll be taking more shots soon, so if there's anything else you would like me to check if it happens again, please let me know. –Rpeh^{•T•C•E•} 12:54, 18 April 2009 (EDT)

This is partly a follow up to my last posts under Code Updates, but I figured I'd move the discussion of image problems to a more appropriate place.

I'm one step closer to understanding the various image problems now, after creating some php code that's loading the image and allowing me to directly test what the wiki thinks is going on and why. The upshot is: it's the cache... again ;) What appears to be happening:

• Before today, when content1 tried to load Image:TR3-npc-Brelyn_Dreloth.jpg, it checked the database, which told it the file did not exist.
• Content1 cached that information about the image.
• Every query about the image on content1 now goes directly to the cache -- where it finds an entry for the file, but that entry says the file doesn't exist. It never asks the database for information, because it thinks its found the information in its cache.
• The same thing happens on content2, except when I re-uploaded the image, the upload was processed by content2. At which point, content2 knew it had to update its cache.
• Meanwhile, content1 has no idea its cache is out of date. I've tried purging the image a couple of times, but content1 is ignoring the purge request. I'm guessing that it's rejecting the purge request because it thinks the file doesn't exist, so thinks there's nothing that needs to be purged (I'll investigate this part of things a bit more).

So I'm guessing something like this has been happening in various forms with these image issues -- any "strange" information is coming from the cache, and we're unable to force the cache to update. Longterm, I think the problem with being unable to purge the cache is a non-issue, because I know that mediawiki has majorly revamped how images are processed in recent versions -- perhaps in part because of this type of problem.

As for why a problem even pops up in the first place, I have a reasonable guess, especially in light of Rpeh's comments above about content2 getting overloaded and image upload requests occasionally timing out. Basically, if an image upload is being processed by content2 and content2 is getting overloaded, then it either takes a long time for the image metadata to get saved to the database, or even the image metadata never gets written to the database (at server db1). However, content2 is successfully able to write its cached version of the image metadata -- which it then continues to rely on, no matter what we do. If content1 is asked to find the image, then it asks db1 for information, and db1 tells content1 the image doesn't exist -- content1 caches that information and similarly then insists on believing its cached info. It's very possible for content1 to be asked to find the image while content2 is in the process of saving the image -- the request to generate the page shown at Image:TR3-npc-Brelyn_Dreloth.jpg at the end of the upload process is sent to www.uesp.net (rather than being sent to the same server that did the upload), where there's a 50% chance it goes to the other server.

Backing up one step closer to the root of the problem, part of it is content2 getting overloaded. On the other hand, that's something that always has the potential of happening, for whatever bizarre, unpredictable reason. The bigger issue is that the timeout ends up not being a temporary problem, but instead triggers a permanent mistake in the image data that we're unable to fix, even if we purge the image. As I mentioned above, I'd bet this has been fixed in newer versions of mediawiki. It's possible I can find a code hack in the meantime -- some way of making a purge request really empty out that image's cached metadata (at least on the server where the purge request is processed). --Nephele^Talk 00:19, 24 April 2009 (EDT)

Hopefully last post on this subject for tonight ;)

First, for anyone who is trying to reconstruct my posts from tonight, Image:TR3-npc-Brelyn_Dreloth.jpg has been fixed on content1 by one of my behind-the-scenes tests: when my php code forced a cache update, it did what it should have all along.

Second, I've posted an updated version of ImagePage.php at /home/nephele/edits/mw10/ that should fix this problem. Right now if it thinks the image doesn't exist, it completely skips the image-specific steps of the purge. I just added a single line forcing it to purge the metadata cache even if it thinks the image doesn't exist (it doesn't do some of the other purge steps, because I assume there was a reason originally why they didn't want those steps done without an image; if those steps needed to be done, a second purge should take care of that processing).

Third, this isn't fixed, even in MW1.15. However, it seems pretty obvious that it should be: if you explicitly tell an image to purge itself, it should force a purge, no matter what it thinks the image status is. So I'll pass it along to them right now.

--Nephele^Talk 00:44, 24 April 2009 (EDT)

Updated ImagePage.php on both content1 and content2. -- Daveh 09:19, 24 April 2009 (EDT)

Oblivion

Moved to User talk:24.215.155.6 --Nephele^Talk 21:28, 20 April 2009 (EDT)

Forum Spam

There has been quite alot of spam on the forums lately, and we have a discussion going about ways to stop spambots before they can register (Link). Would it be possible to add a plugin that requires email confirmation, or a question that needs to be anwered correctly in order to register? -Codex 19:26, 21 April 2009 (EDT)

New Code Updates

The latest version of UespCustomCode has been posted on content1, which should fix all of the search issues you pointed out, along with a handful of other tweaks. The top of the INSTALL file gives details on what needs to be done to update the code -- which basically amounts to "copy everything over". --Nephele^Talk 00:17, 28 April 2009 (EDT)

In case you missed this post, I wanted to point it out again: the updated version of UespCustomCode is still ready to be installed. Until it's installed, it's basically impossible to do searches on the UESPWiki namespace and we're going to continue getting incorrect categorization (as evidenced by multiple bogus categories in Wanted categories). There are a handful of other fixes and new features included in the update. Any chance you could find some time to copy over the new files?

Also, I sent you an email last weekend, which hopefully hasn't gone missing amidst the junk mail ;) Let me know if you have any feedback! --Nephele^Talk 21:06, 20 May 2009 (EDT)

Please don't kick me out.

I love your site and visit it often and I don't want to get kicked off. I added an excerpt to the general discussion page asking for additional content to help me with the game and felt like I was belittled for being confused. An administrator took issue with me, continued to heap on the abuse sounding like an elitist all the while and now I am afraid he is going to kick me off the site. What can I do to stay in good graces. I will not post ANYTHING to the site again if that will keep me on. Please advise... Thanks. — Unsigned comment by 67.181.190.29 (talk) on 1 May 2009

If "You're always welcome to contribute. Just don't insult people while doing it" ([7]) is "heaping on the abuse" and "sounding like an elitist", can I ask for 40,000 other cases to be taken into consideration? Your original reply to Nephele was insulting and I pointed that out, but at no stage has anybody threatened you with blocking. –Rpeh^{•T•C•E•} 10:44, 1 May 2009 (EDT)

I'm not adressing you, I am adressing the host of the site and asking that he read the articles in question in their entirety. I have been corresponding with some other users here and we have examples of other uses of "high-handednesses" being used here.

Here is just one example. -- — Unsigned comment by 67.181.190.29 (talk) on 1 May 2009

I'm just a script monkey (on a good day)...I'm perfectly fine with Nephele's and Reph's comments on the issues. Note that you can sign your comments using ~~~~ (four tildes). -- Daveh 17:23, 1 May 2009 (EDT)

Updating ProtectSection

As outlined on the Admin Noticeboard, I've made some changes to ProtectSection that should really help to prevent editors from endlessly making edits like this or this to effectively make protected text disappear. There's a really good chance that about 20 hours from now we're going to get another round of these edits, so I think it would really help if this new code could be installed fairly quickly.

The new code is at /home/nephele/edits/ProtectSection.php and just needs to be copied to w/extensions/ProtectSection.php (overwriting the existing file that's there).

The only complication (because of course there always has to be a complication) is that the updated code relies upon a hook that doesn't appear until MW1.12. In other words, there's a second file, /home/nephele/edits/EditPage.php, that has to be copied to w/includes/EditPage.php. All that I'm doing is copying in some code that appears in an up-to-date version of the file, effectively semi-upgrading it to MW1.12. I tried to find some ways around this, so that you wouldn't need to change yet another mediawiki file, but any other way leaves huge loopholes where editors could easily circumvent the protect tags. Also, this change isn't necessary because of my tweak to the code, but rather it's necessary as part of fixing some bugs in the code that editors have previously complained about, that I figured I'd also get fixed while I was messing about with the protect tags.

Let me know if you have any questions. Thanks! --Nephele^Talk 21:26, 6 May 2009 (EDT)

Would it be a good time to consider upgrading the Wiki to the latest stable release? -- Daveh 12:56, 8 May 2009 (EDT)

Perhaps.

I'd been thinking that waiting until Mediawiki 1.15 is released might be beneficial, because I'd thought that 1.15 would incorporate some of UESP's bug fixes. However, as it turns out, even though version 1.15 is being prepared for official release, they're basing 1.15 off a somewhat older version of the code, that happens to predate any of our bug fixes being incorporated into the code. Furthermore, 1.15 is probably still a few weeks away from being ready. Not to mention, that I'm not aware of any new "must-have" features that have been added to 1.15.

So my current guess is that there's no advantage to waiting for the next release, in which case version 1.14 is already available, and also pretty stable given that no bugfixes/security fixes have needed to be announced in the last three months. If you've got time to do an upgrade, I think it would be worthwhile. By the end of the day I can make sure that all of our code is completely ready for MW1.14 -- which is mainly just a matter of making sure that all my files on content1 are up-to-date (including, for example, posting the MW1.14 versions of all the Specialpage files that I've already been using). --Nephele^Talk 13:55, 8 May 2009 (EDT)

OK, I think the code is ready for MW1.14. I'd suggest updating UespCustomCode and MetaTemplate first (they'll continue to work with MW1.10; however, the updated code has a few more tweaks in preparation for MW1.14). As for the mediawiki code, I've added some notes into UespCustomCode/INSTALL about what specifically needs to be done to incorporate UESP's core code modifications (under "Updating Mediawiki to 1.14"). I've bundled all of the mediawiki code changes, for all of the extensions, into UespCustomCode.

If you're wondering what we get out of the upgrade, I've started to jot some notes on new features at User:Nephele/Sandbox/1 -- there are a lot of things we'll probably find useful, most notably the ability to rename images. In the process, I also scanned the release notes for the upcoming MW1.15 and confirmed that it won't contain anything equally noteworthy; so I don't think there's any real value to be gained by waiting for MW1.15. --Nephele^Talk 03:21, 9 May 2009 (EDT)

Jesus Lover

I was on the wiki when i clicked this link Jesus lover i dunno whether this is my bad but i don't think thats meant to happen... — Unsigned comment by 84.66.75.106 (talk) on 12 May 2009

Are you the user called "Fallenangel", formerly known as "Jesus lover"? If so, you can move your old page (and talk page) to your new name. If you're not sure about how to do that, please feel free to ask me (or anybody you like!) to do it for you. –Rpeh^{•T•C•E•} 16:20, 12 May 2009 (EDT)

Forums - Posting Links

Recently, we've noticed that new members with less than 10 posts can post links to YouTube as well as the wiki. Has someone changed something recently, or has this always been the case? I just think it's quite strange how YouTube seems to be an exception to the "no links" rule. Thanks in advance! -Vargon 19:26, 15 May 2009 (EDT)

I think it's been the case for a while. But I just went ahead and removed youtube from the list. --Nephele^Talk 01:58, 2 June 2009 (EDT)

Forum bots

There has been a noticeable increase in appearances on the server status page for forums.uesp.net recently, along with several periods where content1 has been inaccessible through heavy usage. A few checks on the s-status page this morning showed that forums accesses were taking around 40-50% of the server slots, rather than the more typical 1-2%.

In particular there were a number of accesses from 194.135.105.175 and 66.249.65.72, which Google identifies as known spammers. Is there any way (short of iptables) that such addresses can be tamed? At the moment they are causing major problems on the wiki at certain times. –Rpeh^{•T•C•E•} 04:17, 20 May 2009 (EDT)

We just had another one: 192.35.35.34 (an open proxy) caused an outage lasting around 10 minutes. Switching to a load-balanced model for the two servers may help a bit but then again it might just take both of them down. Since there seems to be a glut of these bots at the moment, it might be simplest to go for an IPtable solution at least for a few weeks. –Rpeh^{•T•C•E•} 16:31, 21 May 2009 (EDT)

193.190.78.1 has just been clogging up the server and still has 24 connections open. I know I now have access to the server but I just discovered that I can't SSH out from work due to our useless proxy server that also stops me viewing our interactive maps. Could you or Nephele do the block? I'll be able to do it myself in about 5 hours. –Rpeh^{•T•C•E•} 08:03, 11 June 2009 (EDT)

Making Progress

Thanks for the new server abilities :) I've been making some progress, although I will admit that "be careful what you ask for" has come to mind a few times ;)

However, there are two things I wanted to mention:

• wgFileCacheDirectory on content2 was set to the non-existent directory /tmp1/cache. I changed it to /tmp/cache, which makes content2 much happier. However, that means that LocalSettings.php is now different on content2 from content1. Should content1 also use /tmp instead of /tmp1? Or is there some other preferable configuration?
• Following up on Forum Spam, I'm thinking we may want to install Advanced Textual Confirmation (which is the more up-to-date version of the plugin recommended by Josjie in the above-mentioned thread). It's available for phpbb2. If you agree, I think I can do the basic steps of installation. However, I'd really like to splurge on the $29.95 to get a standard license instead of just the free version (as you might have gathered, I'm not too fond of unnecessary error log messages, which is one limitation of the free version). Any chance our bank account can afford it?

Thanks! --Nephele^Talk 12:54, 2 June 2009 (EDT)

• Once upon a time /tmp was on its own small partition so I had to move things off to /tmp1. Since this is no longer the case we should be able to move back to /tmp for consistency.
• If you think the standard version is worth I have no problem investing in it.

-- Daveh 14:22, 2 June 2009 (EDT)

Mysql Warning

I've been scanning the wiki database for errors. The first problem I went ahead and repaired. But the second problem I've encountered isn't quite so easy to fix:

+---------------------+-------+----------+--------------------------------------------------------+
| Table               | Op    | Msg_type | Msg_text                                               |
+---------------------+-------+----------+--------------------------------------------------------+
| uesp_net_wiki5.text | check | warning  | Datafile is almost full, 4101778380 of 4294967294 used | 
| uesp_net_wiki5.text | check | status   | OK                                                     | 
+---------------------+-------+----------+--------------------------------------------------------+

It is just a warning right now, so hopefully it means it isn't causing any problems this second. However, it probably is going to become a major problem soon... I'm just not sure what needs to be done to fix it. Once I've finished the rest of the scans I'll do a bit of research. Also, I'll try to be in IRC as much as possible today in case chatting might help. --Nephele^Talk 15:29, 6 June 2009 (EDT)

OK, looks like the problem isn't too hard to fix. It just requires running an ALTER TABLE statement on the table -- which might tie up the database for a little while (one forum mentioned several hours -- hopefully that's a very liberal estimate!).

Here's the mysql manual page on the problem. I'm pretty sure our problem is "You are using a MyISAM table and the space required for the table exceeds what is allowed by the internal pointer size". The problem is not an operating system constraint, as proven by the fact that the wiki database dump I just created on db1 is 4.4GB in size. Therefore, we should be able to more than double the maximum allowed size using:

ALTER TABLE uesp_net_wiki5.text MAX_ROWS=1000000 AVG_ROW_LENGTH=10000;

So should I bravely dare to wreak havoc? Or would you rather have the honour, after creating a somewhat better backup than my quick database dump? I think it can wait a day or two (we're at 96% capacity, with more than 100MB still available; it should take a few weeks to create 100 MB of content, I'd hope). I'm just very very relieved i happened to stumble across this now, before it actually triggered problems :) --Nephele^Talk 16:17, 6 June 2009 (EDT)

It would be good to do this sometime in the early morning when traffic is lower. I would wait until sometime early next week, Monday or Tuesday morning unless there is an immediate need for more space. Feel free to do it yourself, just post a message here before you do it (as will I if I get to it first). -- Daveh 17:39, 6 June 2009 (EDT)

I'm starting the process now. --Nephele^Talk 04:32, 12 June 2009 (EDT)

And it's done already! Not too bad as far as time required, and only a few queries seemed to be slowed down while it was running. --Nephele^Talk 04:46, 12 June 2009 (EDT)

Thanks...to be honest I had completely forgot about it. -- Daveh 12:03, 12 June 2009 (EDT)

No problem. It just took me a while because I didn't have a chance to do anything until last night. Also, did you happen notice these two posts about some chmod/chown requests that need to be done? Thanks! --Nephele^Talk 12:24, 12 June 2009 (EDT)

phpsessions

Thanks for the new directories! But /tmp/phpsessions is stale on content2 right now ;) Ignore me if you're already in the processing of fixing it. But in the meantime it's nearly impossible to edit pages if the request goes through content2. --Nephele^Talk 20:15, 6 June 2009 (EDT)

Yah, oops. Just fixed it before I got this. Thanks. -- Daveh 20:20, 6 June 2009 (EDT)

Thanks :) The fun of messing with a live site while hundreds of people simultaneously try to use it! --Nephele^Talk 20:23, 6 June 2009 (EDT)

Minor Issues on content2

I just stumbled across some minor configuration issues on content2...

1. I'm not part of the admin group. This should be the simplest to fix, and is probably the most important, too (because then I can work around #2 and #3)
2. When the directories were ported over to content2, any files I had owned on content1 were assigned to userid 522, which doesn't exist on content2. If the group issue is fixed, then I can at least modify the files again, but I still won't be able to change ownership. Places where I'm aware of 522 files are
   • oblivion/maps and subdirs
   • oblivion/map.0 and subdirs
   • oblivion/simap.0 and subdirs
3. There are assorted broken symlinks, also created when everything was ported over. Many are my fault: on content1, I created a bunch of symlinks to /home/uesp instead of /home/uesp.net/www. If #1 or #2 is fixed, I can fix the broken symlinks that are my fault. Or alternatively it might make sense to create the /home/uesp symlink on content2. I'll do a scan for other broken symlinks and let you know if there are any others I can't fix.
   • The only remaining problem symlink is the phpAdmin link in /home/www/uesp.net -- I'm guessing it should just be deleted, but I wanted to check with you first.

Thanks! --Nephele^Talk 21:23, 7 June 2009 (EDT)

I've been trying to preserve the user and group ids on all servers but must have forget about it when I created your account on content2. I've changed all 522 files to the uesp UID. Most files in the uesp directory have the uesp:uesp, uesp:admin or nephele:uesp user/group. You're a member of all the uesp/admin group now on content2 so you should be able to fix anything but let me know if you find something you can't access/fix. -- Daveh 21:48, 7 June 2009 (EDT)

Thanks! If at some point, you'd like to re-number me on content2, feel free :)

Some even less important tidbits on content2:

• I'm also not part of the apache group...
• ...which means that between your fiddling and my fiddling I've lost the ability to delete two temporary directories that I just created :P Specifically, I can't remove oblivion/map.ex or oblivion/simap.ex . They're not causing any problems, but they are completely redundant.

Hopefully, I'm done fiddling for the night! --Nephele^Talk 22:29, 7 June 2009 (EDT)

I've added you to the apache group on content2. I think I know how to change your uid but I'll double check and do it some other time. -- Daveh 23:01, 7 June 2009 (EDT)

New Patroller

Hi Daveh! SerCenKing has just completed the nomination process to become a Patroller. Could you please make the necessary changes whenever you get a chance? Thanks! –Eshe^talk 15:43, 12 June 2009 (EDT)

Almost missed this...but done now! -- Daveh 14:40, 16 June 2009 (EDT)

Upgrades and Upgrades

First, Mediawiki upgrades. I've put together a full set of php and configuration files for MediaWiki 1.14, in the /w14 directory on content1. I opted to take the ambitious route for the upgrade: upgrading the core mediawiki files, upgrading all extensions, adding new extensions, and making some configuration modifications, all at the same time. I'll post some more detailed information about what all has been done shortly.

The next step for the installation is:

• Running the update script: php update.php --aconf ../AdminSettings.php from the /w14/maintenance directory [8]. This will alter the uesp_net_wiki5 database schema, but the changes are backwards compatible with MW1.10 (I've been running MW1.10 and MW1.14 side by side on my test wiki for months now, without problems).

Would you prefer to run the update script, or should I do it? If I'm going to do it, when would be a good time (in particular relative to upgrades)? For example, 4:30 am Saturday night (Sunday morning) right after the weekly backup? Once the update script has been run, it should be possible to check the new configuration and see whether everything is working. Once we're comfortable with the 1.14 setup, we can then get the /w14 directory copied over to content2 and switch both servers to MW1.14.

There's one other change that would be very helpful as part of the upgrade:

• Installing ImageMagick on content2. It's already available on content1 (/usr/local/bin/convert being the most important executable), and I've used it successfully (for example, all of the new forum avatars were created using ImageMagick). However, I can't find it on content2. Using ImageMagick would allow PNGs to be resized; it would also allow animated GIFs to be resized. Furthermore, one of the extensions I'd like to install, ImageMap (part of an even older request ;) ), also needs ImageMagick. It's not a critical need (the upgrade can still be done without ImageMagick), but it would be very nice to have :) (It may be possible to just copy the files from content1 to content2 -- but in that case it's probably best to just tar all of /usr/local, since there are required files in share, lib, and include.)

Second, phpBB upgrades. I'm thinking that we should upgrade the forums to phpBB3. In particular:

• phpBB is no longer providing support for phpBB 2.0.x, and even mods for phpBB2 are no longer being maintained (the mods and all forums related to 2.0.x mods are being put into read-only mode).
• phpBB 3.0.5 (the current stable release) has upgraded captcha. It also provides some additional tools (e.g. custom profile fields) that can further help to control the spambots. It's possible that, if we upgrade, Advanced Textual Confirmation won't even be necessary -- if not, then ATC can still be added.

I've checked the requirements for phpBB3 and we appear to have everything we need (i.e., mysql and php versions are OK). There's also built-in support for conversion from phpBB2 to phpBB3 (overview and details). Are there any other issues that you're aware of that might make a forums upgrade impossible or impractical?

If a phpBB upgrade is possible, then there's the big question of how to go about doing it. First, I'm thinking I want to get the wiki upgrade complete before tackling another major upgrade, so I'm not proposing any immediate actions; I just wanted to start the discussion now so that the big decisions have been made by the time I'm ready to do some real work. It looks like I can do most of installation steps, as long as you don't have any objections to me creating the admin account for the new forums (I'd set it up with all the same parameters as the phpbb2 account, then you would just have to change the password). The new software is installed to a new subdirectory (e.g., /phpbb3); phpbb3 also uses a separate database from phpbb2. Therefore it should be possible to take the time to get phpbb3 fully working and configured, while leaving the phpbb2 forums fully operational; the forums should only need to be put into read-only mode when we're ready to make the final switch, at which point the up-to-date forum database contents would be copied from phpbb2 to phpbb3. So, basically, should I just try to tackle as much as possible, or are there are any parts of the process that you'd like to do or that you think you'd need to do?

Thanks! --Nephele^Talk 14:41, 13 June 2009 (EDT)

I can easily install ImageMagick content2 this week.

As for everything else. When I have previusly upgraded the wiki/forum the basic steps were:

• Create a copy of the content (db copy and new static folder).
• Run through the upgrade process on this copied content. This should catch most issues.
• Once you're ready for the actual upgrade...
• Lock the content ($wgReadOnly for the Wiki, lock the forums)
• If you're paranoid you can backup the database after locking and before the upgrade.
• Do the upgrade.
• Double-check and then unlock everything.

Depending on what you are familiar with or have done already you may be able to skip some steps. Especially with the Wiki it helps to do it early in the morning or late at night. The forum is small enough it doesn't matter too much when its down (assuming the upgrade is relatively quick to perform).

Right now, besides the ImageMagick, you're fine to do the wiki/forum upgrades as you see fit. I can easily do things but won't unless you need or want me to. Also note I'm around for the next two weeks before I'll be away for four weeks (June 28 to July 26) for a combination of vacation and work trips. -- Daveh 09:08, 15 June 2009 (EDT)

Thanks! Hadn't occurred to me to create a copy of the wiki database ;) I'm proceeding to do that right now, so hopefully the MW1.14 test installation can start to be tested later today. It'll probably be a week before my schedule makes it possible to do the real upgrade. I'll also see how much progress I can make with the forums before you disappear! --Nephele^Talk 15:39, 15 June 2009 (EDT)

No problem. I've installed ImageMagick on content2. Feel free to install the ImageMap extension if/when you think it worthwhile. -- Daveh 17:29, 15 June 2009 (EDT)

It All Makes Sense...

I see. You are the creator of UESP. Well, thank you. The information on this website has helped me greatly, and I wish to give some as you have done. I will contribute whenever I see a chance. If there is ANYTHING that I can do, let me know. Please.

I'm not too experienced with all of this just yet, but perhaps if you give me a small assignment, I can finish it.

So yea. Hope I can help and thanks again. --Kitsune 15:59, 18 June 2009 (EDT)

Another New Patroller!

Hi again! Mr. Oblivion has also successfully completed the nomination process to become a Patroller. Thanks! –Eshe^talk 14:23, 21 June 2009 (EDT)

Done! -- Daveh 17:52, 21 June 2009 (EDT)

some glitches/bug on using console with Vampirsm

Discussion moved to Oblivion_talk:Vampirism.

a question if any one can help

(moved to Oblivion talk:Downloads#a question if any one can help)

Moving Forward

Moving forward (I hope) from our recent series of outages/crashes/backup problems/etc., I have a few ideas about changes that would help the site. All of which, of course, are things that you would need to do ;) Next time you're home for a few days, perhaps?

• db1
  • Obvious top priority is getting the hard disk replaced; I'm assuming you'll schedule a time with iWeb. As far as I'm concerned, the sooner the better.
    • A larger hard disk would be a very good idea -- not to be a broken record, but we're back up to 90% (and even got up to 99% during the database recovery).
    • If the hard drive can't be replaced until next week, perhaps a reboot of db1 on Friday would be good? Just in case any errors have been accumulating during the week?
  • Tweak backup scripts. I've put possible new versions at /home/nephele/scripts. Changes: forums are being backed up; wiki is being backed up daily again, but using only a fraction of the disk space; attempted to fix weekly copies of all dbs. Could you simply copy the three scripts to the right places?
  • Tweak mysql. Even when db1 is horribly overloaded, it's only using 10% of its memory -- that's total, for all processes on db1. mysql should be told to use some of the 90% that's never used. So I've set up a new copy of my.cnf in which: key_buffer_size=1024M (25% of system memory); innodb params are turned on; table_cache=4096; various other buffers increased. This should increase memory used by mysql ~3-fold.

• content1 and content2
  • memcached should be shared between content1 and content2. Having separate, individual memcached on each server is causing various wiki problems (out-of-date system messages; contributes to our ongoing image problems). I'll dig up some links/details later.

• all servers
  • Could we request that iWeb put all of our servers on the same network subnet? Every request from squid1 (72.55.137.132) to content2 (174.142.39.4) must be going through a half-dozen network switches; then another half-dozen from content2 to db1 (70.38.12.115). Similarly, every image request on content2 has to be sent to content1 (72.55.146.206); the pointless network hops cannot be helping with whatever image-related problems we're having. If our servers were all on a single subnet (e.g., 72.55.137.*), our inter-server traffic wouldn't have to go through any switches/hubs. From our point of view, it should help site performance; from iWeb's point of view it should save them gigabytes of internal network traffic daily.

--Nephele^Talk 00:48, 21 July 2009 (UTC)

We need to get the maximum number of mysql connections increased -- right now, whenever db1 gets too busy (i.e., during backups), the site's producing the now-all-too-familiar "UESPWiki has a problem" pages. The version of my.cnf that I had tweaked (and which was based on our previous my.cnf file) is still available; I re-uploaded it to /home/nephele/edits/. That's probably a better starting point for our new my.cnf file (even if you think some of my changes should be undone). --Nephele^Talk 08:19, 5 August 2009 (UTC)

Just noticed your original message now. Good comments, thanks.

• There's definite room to improve the performance and efficiency of the database backups. The best solution will likely be a mix of all options (binlogs, full dumps, slave mirroring, and iterative) as its better to have too many than too few. Right now its just a simple daily full dump with live mirroring on backup1.
• Changing the memcached to be shared should be simple. Just change memcached to listen on the server ip instead of localhost and update LocalSettings.php to match. Will check into it.
• Will ask about getting the servers changed to the same subnet. This will undoubtably cause some downtime. Exactly how much depends how the ISP handles it and communicates with me about it.
• I haven't played with db performance settings at all as I didn't have any time when I was restoring db1. I'll revert to the previous performance settings in your saved my.cnf. The update phpMyAdmin on db1 also shows some good performance indicators on its status page (note the root password for logging in is different than the localhost root MySQL password now).

-- Daveh 14:46, 7 August 2009 (UTC)

New Admin

Hi Daveh. We have a new victim ready for the joys of admin-hood. Timenn has passed the community approval test, so if you have no objections please can you give him the usual admin rights of sysop and checkuser? He already has cartographer and map. Thanks. –rpeh^{•T•C•E•} 06:57, 27 July 2009 (UTC)

Done! Sorry for the delay...missed this message during my travels. -- Daveh 14:37, 7 August 2009 (UTC)

Test (Ignore)

1234 --Daveh 19:12, 1 August 2009 (UTC)

New Servers

This is a bit of a sidebar so I'll ask here rather on the admin noticeboard...

A few weeks back we had a user on IRC offer a server to UESP. Not knowing whether this was wanted or even possible, I suggested he contact you directly. I don't know if he did, but if the ISP don't mind and you're interested shall I chase it up? –rpeh^{•T•C•E•} 20:07, 4 August 2009 (UTC)

I did talk with him a bit but I'm hesitant to "accept candy from strangers" if you know what I mean. Right now we have more than enough money generated from ad revenue to cover server expenses in the forseable future. I'd prefer any core server to be completely under my/our control. Having donated secondary servers might be an option (content mirrors, backups, geographic caches, etc...). -- Daveh 20:30, 4 August 2009 (UTC)

I want one!

I'd love to have a uesp.net email address! --GK^Talk2me 20:08, 6 August 2009 (UTC)

I would really like an e-mail adress as well! Krusty 14:38, 31 August 2009 (UTC)

Ooh, me too! Thanks Daveh :) –Eshe^talk 00:03, 1 September 2009 (UTC)

Upload of larger file

Dave, I was hoping to upload a file (a zip archive), but it exceeds the 2MB threshold allowed for uploads on the wiki. I do understand the reason why size is restricted (besides the possibilities for abuse, keeping history for large files would get quite onerous), but the file in question (documented at General:DOSBox helper) isn't overly large (just shy of 3MB) and I don't expect it to change very much, nor grow in any significant way when it does.

Would it be possible to accomodate me somehow? Besides that visitors would have more confidence in a file hosted locally it would also be useful to have a file history, and to not have to worry about my personal Web site going down and so on. JKing 21:59, 9 August 2009 (UTC)

I just looked to see whether I could help, but unfortunately I can't -- Daveh has to make the changes. The problem isn't the wiki software configuration (where I can make tweaks), but rather php.

Daveh -- in php.ini, upload_max_filesize needs to be increased (currently at default value of 2M). Check this mediawiki page for details. --Nephele^Talk 06:46, 10 August 2009 (UTC)

Would it be a better idea to upload the file straight to the web server rather than store it on the wiki? –rpeh^{•T•C•E•} 07:10, 10 August 2009 (UTC)

Actually, upon further consideration it occurs to me that I can instead elect not to include the patches for Daggerfall and Battlespire and rather download them from UESP on first run. It would be somewhat messy and would raise the requirements to "definitely need an Internet connection", but that's not much of a requirement these days, especially considering the source. This should bring the file size down to a paltry 200kB or so. :P JKing 12:29, 10 August 2009 (UTC)

Removing the patches sounds like a good solution for now. If/when Daveh has a chance to adjust the settings, then you could upload the complete file.

I think uploading the file through the wiki is best: as JKing originally said, the wiki's history system for the file is useful, and future updates are much easier. In terms of server requirements, wiki storage minimizes those requirements, since wiki uploads are on a shared disk (any other type of upload would have to be done separately for each content server).

As for the 2M limit, it's really just an arbitrary default introduced to PHP years ago (i.e., when hard disk, memory, and bandwidth availability were less). upload_max_filesize can easily be increased as high as 8M without any problems (past 8M, there are a few other defaults that would also need to be increased; much larger values, e.g. 2 GB, are used by some servers). --Nephele^Talk 19:12, 10 August 2009 (UTC)

I'll take your word for it, but I've seen elsewhere that the file-handling of MW is rubbish and that's why they had a max filesize. The long-outstanding task about redesigning the DB to handle mods better doesn't fill me with confidence either.

In this case, the original file (if it's the one I was testing) is ~4MB. Without patches it sounds reasonable to store it in the wiki; without... I dunno. –rpeh^{•T•C•E•} 19:22, 10 August 2009 (UTC)

The max filesize doesn't come from MW -- it comes from php -- so I fail to see how it has relevance to MW. --Nephele^Talk 19:34, 10 August 2009 (UTC)

No need to get snippy. The fact is the other sites have complained about the way MW handles uploads. If that's no longer an issue then fine. –rpeh^{•T•C•E•} 19:39, 10 August 2009 (UTC)

tribunal main quest walkthru

(Moved to Tribunal talk:Main Quest#tribunal main quest walkthru)

Evony Adverts

Please can you block all of these? They are the most hated adverts on the net and you really shouldn't be encouraging them. Priam 21:09, 27 August 2009 (UTC)

OpenSearch is broken in Firefox

Hello, I'm not sure who to contact in regards to technical issues, I hope this is going to a right person.

UESP appears to serve the /w/opensearch_desc.php stuff just fine (I can download the XML file just fine), it shows up in Firefox search engine drop-down list as 'Add "UESPWiki (en)"' with icon and all, but I get an error message in Firefox when I try to actually add it as a search engine ("Firefox could not download the search plugin from: http://www.uesp.net/w/opensearch_desc.php"). I've tried this on both WinXP Fx 3.5 and Debian Iceweasel 3.5. Both blow up mysteriously. Unfortunately I'm not sure if this happened before the wiki upgrade or not... --wwwwolf (barks/growls) 14:01, 31 August 2009 (UTC)

It looks like something is outputting an extra newline or two before the actual content. This doesn't matter for the regular web page but for the XML file I assume it is complaining about the file not starting with <?xml.... I'll see if I can track down the issue. -- Daveh 16:26, 31 August 2009 (UTC)

Yes, extra newlines were causing the problem; I fixed them. However, the resulting opensearch is basically useless. Although it claims to search multiple namespaces, in fact it only searches the first provided namespace -- in other words, the main namespace which contains no real articles. I tried to rummage around in the code to see if the search could be made somewhat less useless, but I couldn't make any sense of what the code was doing. At the moment, I'm tempted to just disable the entire opensearch feature, because it's always going to significantly less useful than the site's real search function. --Nephele^Talk 05:31, 1 September 2009 (UTC)

TES3 Corprus Update

Discussion moved to User talk:Rawrx2.

User Group Rights

In the light of the mugging taking place here, please remove me from the Administrator, Map User, and Cartographer groups - at least for now. I would request that I be kept in the CheckUsers list as the "evidence" against me seems to be based around CheckUser information and I would like to be able to see the evidence for myself. While you're at it, you should probably remove RoBoT's Bot status and disable my server logins, since I appear to be nothing more than a vandal who can't be trusted. –rpeh^{•T•C•E•} 08:45, 10 September 2009 (UTC)

On further consideration, please remove everything and make it permanent. I have no interest in staying in the nest with the vipers. –rpeh^{•T•C•E•} 16:15, 10 September 2009 (UTC)

Blog

I'd like to try my hand at writing a bit for it.--Ratwar 01:26, 1 October 2009 (UTC)

I think I'd be interested too. Anything I write would be considerably less technical (as in probably not at all technical), but I do enjoy a good blogfest :). While I'm here, I'd still love a uesp.net email address if you have a chance ;). –Eshe^talk 01:38, 1 October 2009 (UTC)

I will join in the fun as well. I might do a series on how to make templates... who knows? And I would like an e-mail address as well if that is possible. Thanks Daveh! –Elliot ^talk 01:41, 1 October 2009 (UTC)

Hi all, I'm 17, preparing to study Geography at university, I have palyed all the Elder Scrolls games but ironicaly never got very far through Morrowind. I would be interested in doing a review of Morrowind through the eyes of a new player (almost like a gmes diary if you will) making comparisons between it and Oblivion, Daggerfall and Arena. I enjoy modding, having released a few 'house' mods already and working on a large quest based mod with my team. Finaly it would just be fun to write something other than my essays and the novel I'm currently working on. Thanks for your consideration. - Aias Aias 21:08, 10 October 2009 (UTC)

Hi again, Daveh. I'd love an account for the blog, too, if'n ya don't mind.  ;) --GK^Talk2me 04:29, 11 October 2009 (UTC)

I've registered; my username on the blog is GK. --GK^Talk2me 04:26, 14 October 2009 (UTC)

I'm interested in blogging, Daveh. Mutated 22:33, 11 October 2009 (UTC)

Update: -- Anyone interested in blogging that I haven't given account to can register as a new user on the blog. Then just let me know your UESP blog user name and I'll change the account priviledge to let you post new topics. -- Daveh 00:22, 14 October 2009 (UTC)

Hi Daveh, I was just perusing the blog as I do, and I wondered if it might be a good idea to have a link on the blog's homepage that takes you back to the wiki? There might be one there and I haven't seen it, and if so I apologise. It's just that when you've been perusing for a while, the 'back' button just isn't convenient! 217.41.23.17 10:30, 13 October 2009 (UTC)

Good idea...thanks! -- Daveh 00:22, 14 October 2009 (UTC)

I'm registered on the UESP Blog, my login there is also Mutated. Thanks in advance for this opportunity! Mutated 01:10, 14 October 2009 (UTC)

I registered and my username is Cactus, as on here. I'd be interested in writing. Just in case you've no idea who I am, I'm a Moderator on the UESP Forums under the same name. ~ Cactus 14:15, 27 October 2009 (UTC)

I'm registered too. Same name as this Volthawk 17:50, 6 November 2009 (UTC)

Way to go

Just voicing my joy that the site is back up, well done. Dlarsh^{(Talk,Contribs,E-mail)} 23:58, 14 October 2009 (UTC)

Thanks, although if I had checked it just before I went out I would have fixed it 3 hours ago. I guess I better not go out anymore...;) -- Daveh 00:02, 15 October 2009 (UTC)

Wait! Who told you you could go out?!?  ;) --GK^Talk2me 00:20, 15 October 2009 (UTC)

TOR trolling

In light of Nephele's disappearance and the continuing use of TOR to troll on our wiki, you may want to check out this discussion if you haven't seen it already. I don't have enough knowledge of networking to know if it's a viable counter-measure here, but I think you'll have a far better understanding of it than I do. Thanks! —Robin Hood (Talk • E-mail • Contribs) 22:24, 22 October 2009 (UTC)

Free Publicity

I don't know whether you have heard this or not but i made an account just to make sure. Anyway, UESP was mentioned in the article Lore Masters in the most recent issue of GameInformer. (issue 199, November 2009) and i think that is news worthy.

Nice, thanks for the heads up on this! -- Daveh 00:55, 27 October 2009 (UTC)

User Name

Considering the amount of users with M'aiq related names and to avoid confusion, I would like my user name to be changed to Mudcrabs-More-Fearsome-Than-You -M'aiq the Liar ^Talk 00:21, 20 November 2009 (UTC)

It's done. Your username is now Mudcrabs-More-Fearsome-Than-You. --Timenn-<talk> 13:36, 20 November 2009 (UTC)

Inappropriate Google Ads

I just received this after editing Eshe's talk page. My relationship with Eshe notwithstanding it's still probably not fair to have that kind of thing appearing on her talk page. Please could you take a look? –rpeh^{•T•C•E•} 00:58, 21 November 2009 (UTC)

Oblivion Map

I think this one's in your department, as it doesn't seem to be a problem with the template. If you look at the previous version of Ra'sava Camp and click on the "view on map" link, you'll see that you only get the zoomed out view of the entire map. If you go to the current version, where I've specified the mapname parameter in place of the default {{PAGENAME}}, everything works fine. It appears that the map itself is not picking up, or not handling, {{PAGENAME}} correctly. As far as I know, that makes it a behind-the-scenes map problem, not something we can address. Thanks! —Robin Hood (Talk • E-mail • Contribs) 23:30, 3 December 2009 (UTC)

Its something to do with the escaping of the "'" in the previous version. The current version seems to escape it correctly as "Ra%27sava+Camp" while the previous version has "Ra%26%2339%3Bsava+Camp". Perhaps something to do with a template escaping it twice. I'll see if I can figure it out. -- Daveh 02:59, 5 December 2009 (UTC)

Thanks, Dave. Elliot suggested that it might be something to do with {{PAGENAME}} itself, since one of his templates that had a sub-template exhibited similar behaviour. —Robin Hood (Talk • E-mail • Contribs) 05:03, 5 December 2009 (UTC)

Just as a reference: "Ra%26%2339%3Bsava+Camp" expands to "Ra'Bsava+Camp". Something is converting the "'" to the HTML character code "'" when it should be "%27". -- Daveh 15:01, 5 December 2009 (UTC)

Vampire Cure Glitch

Discussion moved to Oblivion:Vampire Cure#Vampire Cure Glitch

Requesting Changes

Hey Daveh! The site has reached a consensus to implement some things on the site in order to fight vandalism a little harder (the discussion can be seen here). So to summarize:

• Set $wgAutoConfirmAge to 4 days and $wgAutoConfirmCount to 10 edits.
• Set $wgRateLimits to 20 edits over 6 minutes and implement the Vandal Brake (you will need to contact rpeh and Nx about the code)

The rest can be taken care of by the administrators. If you have any questions or inquiries, feel free to ask. –Elliot ^talk 12:01, 11 December 2009 (UTC)

Great...I'll make the changes tonight sometime. -- Daveh 12:49, 11 December 2009 (UTC)

I've made the configuration changes but is there are documentation on the Vandal Brake? I found the source but no specific documentation on what it does and how to install it properly. -- Daveh 00:48, 12 December 2009 (UTC)

The vandal brake is... lacking... in documentation. The three pages are here, here and here. The third of those three has all the messages and should give you an idea of what it does. Basically, it acts as a way of slowing disruptive users down rather than banning them outright. The idea in this case is that it will allow patrollers to stop massive hits on the site without usurping the block privs of admins. Two variables in VandalBrake2.php define the length of time for which the brake lasts: $wgVandalBrakeConfigAnonLimit and $wgVandalBrakeConfigUserLimit, so different limits can be set for anons and registered users. Users can be "paroled" at any point by somebody with the necessary rights, removing them from the vandal bin.

If you need more, I can chase the writer. From personal experience, it's a good addin and works well. –rpeh^{•T•C•E•} 01:07, 12 December 2009 (UTC)

Phantom Page

Hi Dave. If you get a minute could you check Special:UncategorizedPages and see if there's a problem with the database that's causing "Lore Books" to appear? It's definitely in the list but clicking on it gives the message "The database did not find the text of a page that it should have found, named "Lore Books" ."

There have been a couple of other similar things in the past caused by namespace issues that Nephele fixed (we had a phantom Shadowkey:Potions appearing for a while in Wanted Pages even though Shadowkey:Potions is fine). –rpeh^{•T•C•E•} 20:02, 16 December 2009 (UTC)

Prev: Archive 2008

Up: User talk:Daveh

Next: Archive 2010