UESPWiki:Administrator Noticeboard/Archive 12

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

De-adminship for inactive admins

I'm gonna start this off by saying a few things.

• (A) I am not trying to single anyone out with this.
• (B) I am not trying to start a huge flame war
• (C) I'm hoping we can all discuss this in a professional manner, instead of just having a bunch of admins come in and shrug it all off, and then have this discussion end up dying and going ignored

Ok, I've noticed we have some good admins on this site, namely Rpeh, TheRealLurlock and Nephele, occasionally Wrye, and sometimes Ratwar, although I barely see Ratwar around. However, we have some people who, despite being inactive for quite some time, still remain admins. Wrye was originally going to be one of them, until I went and did some User contrib checks and saw he was semi-active. (I thought we had more admins, but I was wrong, and I've only found 2 who are inactive/semi-active.)

I'll start off by listing Ratwar (click his name to view his contribs). He's made sparse edits and only pops up to join in on administrator discussions. He doesn't really help this wikia at all, other than his occasional news post, or voting in an RFA.

Eshe is very inactive, yet she remains an admin. What gives?

Basically, what I'm trying to say is, we should institute some sort of policy or what-have-you for inactive admins, and removing the admins rights if, hypothetically speaking, they do not make an edit for more than __ days, or something like that. Also, a security should be put in place to make sure that if an admin appears to be inactive for quite some time, they cannot simply come back, make one edit, appear to be active, then disappear for weeks on end again. Now, I know we don't have that many admins here, however, this can be counteracted by promoting a deserving Patroller or Mentor to Admin, and then promoting a regular user to Patroller.

Questions? Opinions? Daedryon^{•T•C•E•} 00:03, 22 December 2008 (EST)

We've already had this discussion, it's up a bit under #Things_that_Need_to_Happen. My opinion is a no. The "if they do no harm, leave them as they are" rule seems fine. Unless if they come back and they obviously show that they have no ability or knowledge relevant to the wiki, then we might delete them. As to the people you mentioned, Ratwar is fine. Could be going through a tough stretch, might not care too much, but he is around. He knows what he is doing. I still value his opinion. I haven't seen Eshe since I stopped editing a while back. So I don't know about her.

As a side note, maybe we should delete them from the list of administrators, or at least put them into a separate group so new members or users needing help won't get confused. --Tim ^Talk 00:16, 22 December 2008 (EST)

Nice to get some input from a Patroller. (not being sarcastic, btw). So this has already been suggested? O.o Wow. My bad! My bad everyone! Daedryon^{•T•C•E•} 00:21, 22 December 2008 (EST)

Hmm. I see now that the Administrator page does show inactiveness. So as long as this is kept up to date, I don't imagine anything will need to change. --Tim ^Talk 00:33, 22 December 2008 (EST)

Why are you surprised by it already being suggested before? It's in the middle of this page, finished in October. There haven't been many other, if any, discussions on the topic prior to this, however (I should know, I archive all discussions). Ratwar should not be de-adminned. He is doing his job. Participating in discussions and watching over the community are admin jobs. Sure he supervises more content than he writes, but he is still "active" (although you can't really see it from the lack of physical "edits" the software records). As he said, you generally only get to know him if you have been acting bad. Despite being a college student (I'm in high school and I still find the work overwhelming at times), he takes the time to check on discussions and recent major events. Eshe.... I haven't seen since she became an admin. I hope she'll drop by and let us know what's up. Also, this is an Administrator Noticeboard. If you are looking for the consensus of the ENTIRE community, including Patrollers, you should have used the Community Portal. Vesna 15:39, 22 December 2008 (EST)

Yes, I realized that shortly after I posted this. Daedryon^{•T•C•E•} 15:44, 22 December 2008 (EST)

Well, appear to be a bit late to this discussion, but it didn't make it to the active discussion area of the Community Portal, so I didn't see it until now. Plus it never seemed to gain enough steam for it to reach my ears in the chatroom. Still, I feel pretty obligated to defend myself, as my name was not thrown into the discussion last time around.

I am not the most active administrator, but when I do appear, I tend to get things done. Over the last year, I've helped GuildKnight become an administrator, played a central role in renaming the Tamriel Section to Lore, and started some activities to clean up Oblivion:Roleplaying. No, I'm not here every day, but when my opinion is needed, I tend to appear.

I am not the type of person that can do large number of similar edits. That just isn't my bag of tricks, and this has been compounded by the fact that I had a particularly tough semester last fall. I just didn't have the time for the site. Of course, I would argue that not being here every day is actually a good thing. I can provide an outside position.

Finally, I will reiterate my position expressed above that there is no reason to de-admin inactives. It doesn't protect the site, and can deprive the site of experienced problem solvers.--Ratwar 18:51, 4 January 2009 (EST)

Response to Ratwar and a policy discussion

Mhm, that's a good reason Rat. However, I have something to say about that. If this place had more admins, and actually had more successful RFA's, instead of shooting good editors down, we'd be able to start a policy for deactivating admins if they've been inactive for over...say...4 months or so?. However, on the flipside, we don't have as many good contributors with alot of edits (we do have quite a few with over 1500 edits, as seen in Active Users.), but an RFA hasn't come up yet for some of them. Another thing I have noticed is the inactivity of some of those users.

Another problem is the edits needed to become an Admin/Patroller/Mentor. It's kinda hard nowadays, what with the Bloodmoon project being finished, and us already having almost everything Oblivion-wise. The only things left that could get an editor the needed edits is the Mobile games. The only thing I can find to do that I'm actually good at would be the cleanups.

With that being said, I think the policy should include vandalism reverts, as that is the one thing on the site that alot of people can actually do. When I put my name on the Mentor list, I included good reasons why I'd be a good mentor, as my knowledge on Oblivion and Morrowind is excellent. However, minutes later, I was shot down by Rpeh, with the reason stating "You only have around 90 good edits, once you remove the userpage edits, the talk page edits and the minor reverts". I found that rather stupid, as I have a good 680+ edits under my belt, and I was going to try for Patroller, except I've only been here around 7 months.

From where I'm sitting, if revert edits aren't allowed, I'm not going to have much of a future here on UESP, and I might as well just quit right now and not sit through several failed RFA's, patroller requests, and/or mentor applications. Some things need to change. We're losing alot of members, because of this problem, and also because of the tenacity and ego of some of our mods.

From User:Hoggwild5: I found the environment here with some of the admin staff on UESP to be a bit....stifling

I have to agree with Hoggwild, even though he hasn't edited since mid-2007, and went and created his own Elder Scrolls Wiki. Sometimes, the staff can be abit stifling, and sometimes even remove some edits based on stupid things like "bad language" (since when is "hell" and "god damn" bad language?). Well, before I bore you to death, I'll end this by saying things need to change. _{Prince of Madness}^Daedryon 21:30, 4 January 2009 (EST)

Truthfully, I don't think an edit # is necessary. I say that administrator and patroller privileges should be given to those who have the ability and the consensus support to do tasks. Administrator rights should be given to people who can appropriately delete pages, block users, create categories and templates, and have the support of the community. I agree with Daedryon that with the ordinary user (those who edit Morrowind and Oblivion) they would have the ability only to revert and maybe add tiny details. So, maybe we need to have a activity policy or even have trial-admins/patrollers to make sure that users are suitable for higher positions. Having more patrollers and admins than are necessary doesn't seem like too big of a deal.

My reason why I haven't made an RFA (hopefully a Request for Adminship because if not I'm making myself look dumb) is that I don't think I need administrator privileges to make Daggerfall better. However, I do plan on learning some of the stuff that admins need to know sometime between now and when I finish with Daggerfall. Also, dealing with this comment, "I found the environment here with some of the admin staff on UESP to be a bit....stifling" , I say "Indeed". I remember both Aristeo and Hoggwild leaving to create their own wiki because they felt the administrators were stifling then, but now.... I'd have to say it's gotten progressively worse. There are fewer and fewer administrators and users willing to talk on IRC, and many of the users who I've seen in the room a year ago and two years ago have disappeared. I remember conversations every night, but now, I'm lucky if one person shows up to chat. I have chatlogs to prove this if needed. --Tim ^Talk 22:28, 4 January 2009 (EST)

Yeah but see, alot of vandalism happens nowadays, mainly bot vandalism. And tentatively, I don't see any patrollers around usually. I also dont know what tentatively means. We need a good deal of patrollers with rollback nowadays, especially around midnight (-5:00 GMT Toronto, Ontario time) which is when I dont see any administrators online, and is also when most vandalism occurs. I myself am the perfect candidate as I'm unemployed currently, I'm usually always here, whenever I'm not randomly hanging with my friend, and I always revert vandalism. But this isn't about me, this is about the policies and how stupid they are with their requirements, and also the little admin problem. _{Prince of Madness}^Daedryon 23:02, 4 January 2009 (EST)

Before this just turns into a gripe-fest about events that occurred more than two years ago, would it be possible to first stop and figure out what exactly is being proposed as a change that needs to be made to the current wiki? Is this about the number of edits necessary to be a mentor? Or is it about the requirements to become an admin? Because right now it just seems to me like a lot of completely different facts are being thrown into the blender, leaving me very confused about what exactly is being discussed. So for now, let me just focus on what I do understand, which is the facts about what current policy does (and does not) say:

• The requirements for admins, patrollers, and mentors are different and are independent.
• Becoming an administrator does not have any fixed requirement in terms of number of edits.
  • Only patrollers and mentors have fixed requirements in terms of numbers of edits. The reasons behind those requirements have been discussed at length on the appropriate pages (UESPWiki_talk:Patrollers, UESPWiki_talk:Mentor Program). The admin noticeboard is not the place to discuss revisions to those requirements. Any continuation of previous discussions should be done in the same place where those previous discussions were held.
  • There is nothing in the current requirements stating that reverts do not count towards either mentor or patroller edit counts.
  • You do not need to be a mentor to become an admin.
• Sorry, but I really have a hard time being sympathetic to a claim that it's impossible to find constructive edits to make to the site. Especially after I just spent a good part of the last three days doing nothing but followup on recent edits. There's a Task List with multiple incomplete tasks. There are categories filled with lists of pages that need to be edited for one reason or another. Making a constructive edit does not mean creating new articles; it simply means improving an article. And of the thousands of articles on the site, I'm willing to bet that I could see some type of constructive edit that needs to be made on nearly every one of those articles.
• If the only reason that you're contributing to the site is because you want to become an admin, then you are contributing for the wrong reason. In my opinion, you should be contributing to the site because you want to improve the wiki. Improving the wiki does not require that you be an admin.
• Patrollers do not have rollback capabilities. Rollback capabilities are not necessary to undo vandalism. Every editor on the site has access to the "undo" button used by patrollers to undo vandalism and other inappropriate edits. If you want to undo vandalism by bots, your help would be welcome. But you don't need any special tools to be able to do so.
• This is a discussion about the wiki. Participating in IRC is not a requirement to contribute to the wiki; participating in IRC is not a requirement in being made a mentor, patroller, or an admin.

So, in the spirit of trying to be constructive, could we perhaps identify what exactly is being proposed and how (or even whether) that proposal is a change to existing policy? --Nephele^Talk 00:11, 5 January 2009 (EST)

Ok so if Reverts do count, why the hell did Rpeh shoot me down instantaneously, with the reason I gave above.

• I've deleted you from the list of mentors for the moment. One of the criteria is "User must have made at least 200 constructive edits outside "User" and "Talk" namespaces." Once you take out your User, Talk and Image edits, plus those that are "Undo"s and small edits to correct your own mistakes (spelling, forgetting to sign and so on), you have fewer than 90 edits. You'll need to make many more substantial edits to game spaces before you can join the Mentor Program. –Rpeh•T•C•E• 05:55, 1 January 2009 (EST)

I know for a fact I've made over 200 vandalism related reverts, or less. Added on with my recent cleanup edits, I have over 200. Therefore, I'm reapplying for a mentor position as I am very wise when it comes to Oblivion. I've actually forgotten about what my main proposal was. Something to do with edit requirements for Patrollers and Mentors, not including reverts, as was told to me by Rpeh. _{Prince of Madness}^Daedryon 00:19, 5 January 2009 (EST)

Slow Connection

For the past week or so I've found the wiki increasingly hard to access (even on weekdays). Problem became worst today, when I began receiving several error messages (cache = root, or the like) as well as "unable to connect". My connection is fine. Is it the server, or the (apparently severely) increased traffic due to the holiday break? Just wondering, as it is making patrolling hard. Vesna 13:24, 23 December 2008 (EST)

Nevermind. It is fine now! Vesna 13:30, 25 December 2008 (EST)

Patrollers and External Links

I've recently noticed that patrollers suffer from the box that requires you to type in letters and numbers in order to put in an external link. I was wondering if the patrollers could be removed from the group who get these? --Tim ^Talk 01:21, 5 January 2009 (EST)

Well I suppose that any patroller's opinion on this is going to be slightly biased anyway, but I'd still like to state my opinion.

The entire point of becomming a patroller is that you can be trusted to make good edits which do not need double checking by other users. The ReCaptca is designed to catch people or bots who are spamming external links onto pages; an activity which the patrollers are hardly going to try. - Game Lord^{Talk|Contribs} 09:17, 5 January 2009 (EST)

Patroller's should now be immune from the captcha. Let me know if that is not the case. -- Daveh 12:41, 1 February 2009 (EST)

I still seem to get it. - Game Lord^{Talk|Contribs} 08:20, 2 February 2009 (EST)

Indeed, I get the same. --Tim ^Talk 16:54, 9 February 2009 (EST)

Anonymous Users

I propose that we add a limit for the amount of posts anonymous users make per day. The amount would be around 5. If an anonymous user tried to edit after writing 5 edits, it would show a page asking them to make an account. I see a few benefits to this:

• Users spamming who cannot change IP's quickly would be hindered, forcing them to make an account.
• Bots, though they normally do not make 5 edits per IP, would also be hindered similarly.
• Users who make 5+ good edits per day would be more likely to create an account.
• Users who make 5+ edits on a page would be likely to make an account, then we'd be able to help them with editing.

Input please? --Tim ^Talk 11:21, 5 January 2009 (EST)

I don't see any real benefit. Being an anonymous editor has more disadvantages to the editor than to UESP, so why should we care so much if someone chooses to edit anonymously? Forcing vandals to create an account just leads to the creation of tons of pointless accounts -- yes, vandals really will create accounts if they are forced to do so, as was very apparent back before the site allowed anonymous editing. Furthermore, there are some editors who are prevented from logging into UESP by their internet service provider (most notably Chaos Monkey, who made hundreds of contributions to the site, all anonymously). Why should we lock out those users completely?

Even more importantly, there is the technical question of how it would be done. Unless there is an existing mediawiki extension to do this, implementing it would require a ton of work by someone knowledgeable in PHP and mediawiki software. Which at this point normally means either me or Daveh. Personally, I'd rather be spending that time actually contributing something constructive to the site. --Nephele^Talk 12:03, 5 January 2009 (EST)

It's very easy for people to change IPs. They would probably change their home IP or use a proxy to make edits if they wanted to remain anonymous. I don't see a compelling reason to limit edits by unregistered editors. I think all anonymous sessions should be confirmed via a good captcha though, and captchas should be disabled for registered users. Lukish_ Tlk Cnt 17:17, 5 January 2009 (EST)

I see no reason why bots couldn't make a user and spam, so the capitchas should stay for regular user (kind of mixing 2 topics are we?). But I guess I didn't know that people couldn't log in due to their ISP, otherwise, I wouldn't of made the suggestion. --Tim ^Talk 18:53, 5 January 2009 (EST)

Captchas should be required for making an account, and confirmation from a valid email account. I'm pretty sure that would stop most bots. A good captcha would be needed too, meaning one that couldn't be simply decoded by a program. Lukish_ Tlk Cnt 19:39, 5 January 2009 (EST)

I agree with Lukish. On the subject of vandalism, I still don't understand why we attempt to give vandals a second chance. I'll admit, I used to be a Wikipedia Vandal. I know what they're thinking. We shouldn't be giving them a second chance. If it's an IP that vandalizes, we should block it instantly. As for people using proxies to get by the 5 edit limit, we should also visit Proxy.org, make a Sandbox page, and visit every proxy, signing the page with each one. We then gather each IP and permablock it. In the case of users who vandalize, we do the regulation warning. If it happens once more, we block. We should NOT be giving IP's and vandals second chances when they vandalize, just because a few admins (not naming names) think that the IP's will change their ways and start contributing. _{Prince of Madness}^Daedryon 07:07, 6 January 2009 (EST)

Hear it from a nameless non-admin then. I don't think we need to permanently block IP addresses the first time. There are very few IP editors that return after one week and continue vandalising. Furthermore, many IPs are dynamic, or the users behind them change. A good example of that last one is Volanaro, a productive editor who worked from school, and had the good fortune that he created his account before his schoolmates managed to get their school's IP adress blocked. --Timenn < talk > 09:06, 6 January 2009 (EST)

Quite right Timenn. In fact, I can't get on the forums at school because there's an IP ban for the school. Anyway, why are we still discussing this, since Nephele is quite right that there are people who can't log on due to their ISP. The only thing I would want to make sure of dealing with anonymous users is that they are kept anonymous by administrators. (which, I believe we do have such a policy judging by an above conversation)--Tim ^Talk 13:23, 6 January 2009 (EST)

Blocked

Hey guys,

This guy really has gotta be blocked. Thanks. http://www.uesp.net/wiki/User_talk:192.173.40.175 --Playjex 00:03, 1 February 2009 (EST)

Done. Thanks! --GuildKnight^Talk2me 00:25, 1 February 2009 (EST)

New Range Block

I've blocked the range 192.173.40.0/24 (blocks 192.173.40.0 to 192.173.40.255) for a period of one week. For the past couple of days I'm sure you've noticed a particular type of vandalism on the site. Two IPs (192.173.40.218 and 192.173.40.175 came from the same IP and I decided a range block was in order to preempt more attacks. If another admin finds this has blocked innocent users from editing, please feel free to unblock without consultation but keep an eye out for more vandalism. –Rpeh^{•T•C•E•} 05:13, 1 February 2009 (EST)

I've expanded that to 192.173.40.0/22 to catch the latest IP - 192.173.42.148. One more week from today. –Rpeh^{•T•C•E•} 11:46, 2 February 2009 (EST)

Sorry, but I'm just curious, what's a range block? --Playjex 12:51, 2 February 2009 (EST)

Most blocks target one account or one IP address. A range block is a way to block multiple IP addresses at once. The first one blocked all 256 IPs from 192.173.40.0 to 192.173.40.255; the latest one blocks the 1024 IPs from 192.173.40.0 to 192.173.42.255. I hope not to have to increase the scope any more than that. For more information, see the Mediawiki site here. –Rpeh^{•T•C•E•} 12:56, 2 February 2009 (EST)

Thanks for the info and link.--Playjex 13:00, 2 February 2009 (EST)

Rpeh, the ISP for the range seems to be Northeastern State University. Their entire range is 192.173.32.0 - 192.173.63.255, so if we still have problems, let's just block that whole range.-Ratwar 14:56, 2 February 2009 (EST)

Follow up: He just popped back in from 12.40.34.88, that's owned by Buford Communications. That range is 12.40.34.0 - 12.40.34.255.-Ratwar 18:06, 2 February 2009 (EST)

Protection on Oblivion:Speechcraft

I've just given Oblivion:Speechcraft permanent semi protection. A look at the protection log for the page shows that we've had problems with bot-style vandalism on this page for some time. I was initially going to go for another month of protection but since it doesn't seem to have any effect I decided to make it permanent instead. Just thought I'd point it out. –Rpeh^{•T•C•E•} 03:24, 4 February 2009 (EST)

Out-of-game and unofficial resources

While checking out Lore:Heart of Lorkhan‎, I noticed that popular theories and unofficial material was in the article. As we know, the ideas about the Stones and Towers originated from materials that were not published by Bethesda. Yes, this material was made by developers (some and not all; many times just for fun, as in the case of that Vivec play), but they weren't released in any game or official, published source (as of now). We're not going to say that Vivec blew up Azura and banished her to Oblivion. As seen in the final product of Oblivion, Bethesda scrapped those ideas in favor of the Oblivion Crisis; there aren't any armies of returning Aylieds or Azura seeking revenge in the final product. Really, I don't think we should accept these unofficial sources just because the majority of people at the Imperial Library says so. Here at UESP, we use undisputable facts, not fan-theories about the Dwemer transforming into armor for some robot. --Michaeldsuarez ^{(Talk)/(Contribs)} 23:19, 8 February 2009 (EST)

Resolved. UESPWiki_talk:Lore#Once_More_Unto_the_Breach... Temple-Zero 23:27, 8 February 2009 (EST)

As Temple-Zero has already mentioned, there has been a substantial change in the policy within the lore section. If you wish to discuss that, you're welcome to do so on that page. Anyways, I would say that the UESP is still NOT using fan sources. Michael Kirkbride is a former developer, and did some contract work for plugins for Oblivion. Therefore, I would say that his writings do carry some weight here. Of course, the games do and will continue to have the final say on what is actually canon, but I see no reason to not allow information from an informed source such as MK. --Ratwar 23:54, 8 February 2009 (EST)

Wish that I was there for that. As a editor for Wookieepedia, I believe that only official sources published by the company (Lucas Arts in the case of Wookieepedia) hold weight. I really don't see a reason to worship every word that comes out of MK's mouth; he's not the ultimate authority of The Elder Scrolls. It really should count if it was within the games, rather than a bunch of forum posts. Anything he made outside of the games should in theory hold as much weight as a fan-fic made by you or me. Yes, Mike created many facets of lore, but that's not really a good enough excuse. In the end, you're giving this unofficial material credit for having MK's name on it. --Michaeldsuarez ^{(Talk)/(Contribs)} 00:11, 9 February 2009 (EST)

Load Balancing

As some of you may know I'm in the process of adding additional content servers (well, at least one more) to allow a load balancing configuration. Most of the site slow response time issues in the past year have simply been due to the one content server receiving more requests than it can server (CPU limited). Load balancing will currently just be done at our single Squid cache server which sees about 99% of all incoming traffic.

I just enabled the load balancing to use the content1/content2 servers and immediately saw a huge drop in server load. I'll be leaving in enabled for at least this weekend while I'm able to keep a close eye on things.

If you see, or you hear of, any issues, errors, etc... let me know via IRC or my talk page so I can see if they related to the new setup or not. -- Daveh 13:26, 28 February 2009 (EST)

One issue I've noticed so far is that some pages (like Tes3Mod:Tamriel_Rebuilt/Her_Hands) have display issues when being served from content2. I'm not sure of the exact cause but I'll continue to look into it. It may be because the MediaWiki file cache on content1 has not been rebuilt in a while but that will have to wait until a lower traffic time. -- Daveh 10:21, 1 March 2009 (EST)

Shadowkey Searching

I just noticed that there's no option to include the Shadowkey namespace in searches at the moment. Please could one of the uber admins with permissions to add things to the search please add that one? Thanks. –Rpeh^{•T•C•E•} 13:51, 8 March 2009 (EDT)

Code Updates

I'm in the final stages of testing a significant set of updates for the site's PHP code. Before passing the code to Daveh for installation, I wanted to doublecheck whether there are any updates that I've overlooked.

The primary purpose of this update is really just improved code maintenance for the site (read: it should hopefully be much easier for Daveh to upgrade our mediawiki code, so we're no longer a year behind in mediawiki updates and forced to use out-of-date versions of extensions). This became an even greater issue on the site when Daveh expanded to multiple content servers, since any upgrades need to be applied on each server separately.

However, amidst all of the code reorganization I've also tried to add in any code requests of which I was aware. That includes:

• Adding Shadowkey to Special:Search
• Removing captcha checks for patrollers
• Tweaking indentation on the site's sidebar, to make it look like this. I am not using the tweak suggested by Ratwar -- in other words, this will not force the entire sidebar to be written in wiki code (which would make us lose some sidebar features, in particular some that appear in upcoming mediawiki versions and that I've retrofitted into our current code). Rather, it will simply make it possible to have extra indents added for list entries such as Shivering Isles. Based on my memory, and from reviewing the failed tests on the Sidebar page, I think that's the only feature we need added to the sidebar -- but if there are reasons why we need more extensive customizations of the sidebar, let me know.
• Performance improvements for the site's search engine. The biggest improvement is completely invisible to readers (my previous sloppy coding meant that the "Go" button was probably requiring 250-odd separate database calls; I've consolidated that all into a single database call). In addition, though, I have also opted to implement a suggestion I made here (under "Tweaking the wiki search engine") a long time ago: using the sidebar search button will result in a title-only search for the requested term. To do a full-text search, you'll have to use the search button on the search page. My feeling is that eliminating a significant chunk of CPU processing every time a reader uses the search box is worth the minor inconvenience on those few occasions when someone actually wants a full-text search. But, again, if others disagree, speak up now (or forever hold your peace ;) ).
• Making our site's logo and skin more "official" -- so that every time the site hiccups, pages don't revert to the site's old logo and standard mediawiki color scheme.

I'm also adding a few new features in this round of updates -- for now, just sticking to some easy-to-implement features:

• Making it so that Orphaned pages automatically skips any disambiguation pages. In other words, this entire page can be blanked -- or converted to a better purpose, such as describing when disambiguations should be used, and how they should be used.
• Adding some new UESP-specific magic words and parser functions:
  • {{#sortable}} that provides the sortable version of any text (e.g., "{{#sortable:A page title}}" would print "page title, A"). Putting this into PHP code means that it can be done much more efficiently than is possible with templates -- particularly important for a function that is likely to end up on every page on the site.
  • {{CORENAME}} that always returns the snippet of {{PAGENAME}} that is relevant for category sorting. In other words, CORENAME would print "Port Telvannis" if it's called from any of Lore:Port_Telvannis, Lore:Port_Telvannis/Description, Tes3Mod:Tamriel_Rebuilt/Port_Telvannis, or Tes3Mod:Tamriel_Rebuilt/Port_Telvannis/Description.
  • {{SORTABLECORENAME}}: same as {{#sortable:{{CORENAME}}}}. I put this into its own magic word because I'm hoping it will be possible to use SORTABLECORENAME universally on the site (in every trail template, summary template, description page, etc.), in place of our current medley of PAGENAME, SUBPAGENAME, SORTABLEPAGENAME, SORTABLESUBPAGENAME, etc.
  • An assortment of improved namespace-related magic words. These should fix the shenanigans we need to go through for Shivering Isles on every summary template. And even more dramatically fix the shenanigans we're going through with adding Tamriel Rebuilt into templates. I'll provide full details once the new extension is in place, making it much easier to show how it works.

The upshot of this whole post is: are there are other needed fixes that I've forgotten? Or implications of these changes that I've overlooked? In general, are there any last-minute changes that I should make to this chunk of code before asking Daveh to install it? I'm hoping to have the code ready for Daveh within the next day -- although tweaks will still be possible after that. --Nephele^Talk 14:32, 15 March 2009 (EDT)

Wow. While you're fixing everything that's wrong with the site, could you take a look at my sink? It's been draining a bit slowly of late and I think the U-bend might need clearing. :-p

That looks like a pretty comprehensive list of things I can think of that could be improved at the moment (and it included several I didn't realize could be improved). In particular, the thought that the {{SORTABLE*}} templates will be implemented on the server rather than in wiki code is a welcome one. I always considered them a necessary evil that would - with any luck - become obsolete with time. I can imagine several pages being much faster with that one change.

From a reliability point of view, I imagine there's a relatively easy rollback if things don't work well in prime-time? I'm not casting aspersions on your code, but as somebody who has had their fair share of "Well it worked on my computer" moments, I've learned to be safe rather than sorry.

Lastly, thank you for spending the time on fixing these irritating little - and not so little - problems. The site should be much faster and much easier to maintain with these in place. –Rpeh^{•T•C•E•} 15:53, 15 March 2009 (EDT)

The kitchen sink will be part of my next overly-grandiose extension-that-fixes-everything-on-the-wiki :P

One of the (many) motivations behind this list of changes was my sneaking suspicion for why the site keeps getting slower even though page hits are decreasing: our pages keep getting more complex. In other words, each page request probably requires more CPU than it did a year ago. The SORTABLE templates are probably one culprit. Not that there's any flaw in the templates (in fact it's a pretty remarkable piece of template-writing), but there's a reason why regexp functions are so popular. A single PHP regexp function can replace three layers of templates. The downside is that any future changes need to go through Daveh -- for example, if we realize there's another pronoun that needs to be skipped.

The changes are being implemented as a mediawiki extension, which means that the vast majority of the code is turned on/off by a single line in the site's LocalSettings.php file. Most of the individual changes are turned on/off by one or two lines of code in the extension's main file. Basically, rollbacks with this code will be much easier than any previous code changes we've made to the site. (I've also tested the code far more thoroughly than any of the other code changes I've forwarded to Daveh -- most of my past changes were basically PHP code that hadn't even been compiled yet; now I've got a test wiki running where I can get as close as possible to checking what will happen when Daveh implements the code).

The most significant source of code changes with this update will actually be reverting a lot of our current customized php files to the vanilla mediawiki versions, or very-near-vanilla versions. (After this is all done, I'm hoping to have only about 20 lines of hard-wired custom code changes to a total of 4 standard mediawiki files, whereas right now we have at least 1000 lines of custom code modifying some 25 standard mediawiki files). Rolling back those code changes would be less trivial (although never difficult: I've added all the old code to my SVN server, and I'm sure Daveh has his own backup systems, too). But really all that means is that the worst case scenario is that if the new UespCustomCode extension was completely disabled, the site would revert to a vanilla mediawiki site. Fewer conveniences, but safe and non-buggy (or at least, any bugs wouldn't be my fault!)

In any case, I'm also putting together a fairly detailed set of step-by-step instructions for Daveh (that's the main thing I need to work on today) so that he knows what he's doing as he installs the extension and can test each change as it takes effect. In other words, yes, I've had my share of oops! moments, too, so I've tried to anticipate the unexpected ;) --Nephele^Talk 16:46, 15 March 2009 (EDT)

Site traffic has been roughly steady over the past year. Its been a little hard to tell since we've moved to using the Squid cache and now the two content servers. Just looking at the Google Adsense numbers, for example, gives the same average the past two weeks as last year (around 440,000 ads served/day). The recent performance bottleneck was definitely the content server where the MediaWiki pages are generated from scratch. Its possible that all the various templates used contributed to slowing the site down, although exactly how much I don't know (we could profile it but at this point its more effort than its worth).

These new changes sound good and will hopefully make it much easier to upgrade MediaWiki. I noticed recently its up to v1.14 while we're still using v1.10. While we don't necessarily have to always have the latest version its good not to get too far behind. -- Daveh 20:09, 15 March 2009 (EDT)

One potential reason to upgrade sooner rather than later is that extension-related features were majorly revamped in v1.11. The upshot is that nearly all extensions now require MediaWiki 1.11 (including, for example, the requested update to the Cite extension).

On the other hand, there's also one reason to wait until 1.15: I'm working on getting a set of our code modifications added into the vanilla MediaWiki code (since the code is fixing a bug that MediaWiki's been aware of for three years now). But we can work around that issue if you want to upgrade to v1.14 --Nephele^Talk 23:29, 15 March 2009 (EDT)

Will my newly-created custom sidebar still work after the sidebar indentation tweak? --Gez 17:01, 15 March 2009 (EDT)

Mostly :/ An advantage of the above-mentioned decision to stick with a minimal tweak to the sidebar (instead of changing to a completely wiki-code version) is that the sidebar will still be pretty similar to what wikimedia expects. The only problem is that your existing .js code won't remove any of the new, indented entries in the sidebar. But it's possible to tweak your .js so that it will be able to handle those entries, too -- I'll work out the necessary tweaks when I get a chance. --Nephele^Talk 18:18, 15 March 2009 (EDT)

I have mixed feelings about the change to the search functionality because I think the title-only functionality will be quite helpful in its own right, never mind the reduced number of database results that that'll cause (and as a DBA, I'm all for smaller result-sets and fewer hits <grin>). It'll just be annoying when I really do want to do a full-text search. I was going to suggest a toggleable option for it near the search box somewhere, but I'm concerned that it might make things too cluttered, so I'll let you decide on that one. :) --Robin Hood (Talk • E-mail • Contribs) 18:25, 15 March 2009 (EDT)

Hmm... how about replacing the current "?" button with a "More options..." button that simply takes you to Search? It requires an extra click, plus it's really just the same as clicking "Search" without entering anything in the box, but it's more obvious and covers more possibilities. As for the "?" button, I'm not sure that readers know what it does, plus there's a pretty obvious link to the Help page at the top of the Search page. --Nephele^Talk 18:50, 15 March 2009 (EDT)

That'd work for me. --Robin Hood (Talk • E-mail • Contribs) 22:07, 15 March 2009 (EDT)

OK, that's how I've now set it up. --Nephele^Talk 23:29, 15 March 2009 (EDT)

I'm not sure if it would have anything to do with what's being discussed here, but I've been considering requesting a feature I use often on another wiki. On the UESP, currently the only way to get to an article diff with a "mark as patrolled" link is to follow the diff link on Recent Changes. On the other wiki I use, any diff viewed by a Patroller/Admin automatically has the "mark as patrolled" link if it is not patrolled. This would be helpful for me because I use my watchlist e-mails rather frequently, to monitor pages so that I check the pages that are most important (to me) first, before checking Recent Changes. Just a thought... ;) --GuildKnight^Talk2me 12:56, 18 March 2009 (EDT)

Actually that reminds me. There's an old, old wish for a "Mark as unpatrolled" option when you suddenly realise you shouldn't have patrolled an edit after all. Sorry I didn't mention that one earlier but it completely slipped my mind. –Rpeh^{•T•C•E•} 13:34, 18 March 2009 (EDT)

True. I'm sysop on another wiki and sometimes, when looking at recent changes, I see an edit that I know will need to be rephrased heavily but I don't have the time to do it right now, so it's better left marked as unpatrolled for the time being. --Gez 13:47, 18 March 2009 (EDT)

Nothing new to add here, other than to pipe up that I too would appreciate both these options if they're doable. --Robin Hood (Talk • E-mail • Contribs) 14:06, 18 March 2009 (EDT)

The wider implementation of "mark as patrolled" links appears to be a feature that will automatically be added when the site upgrades to a more up-to-date version of mediawiki. On my test wiki, I'm running 1.10 and 1.15alpha side-by-side, and when I look at the exact same diff (starting from the history page instead of recent changes) in 1.10 and 1.15alpha, the "mark as patrolled" link appears in 1.15alpha, but not 1.10. FYI, 1.15alpha is the development version of mediawiki, which will morph into 1.15 when 1.15 is due for official release. I'll poke around a bit on the unpatrol option, too, but I'm guessing it will probably make more sense to implement any changes after UESP has upgraded, given that it's clear that particular section of code is going to be changed after the next upgrade. --Nephele^Talk 15:31, 18 March 2009 (EDT)

←

Speaking of the code update, I thought about something else that'd be on my wishlist: the ability for category pages to not display namespaces, and to not display parent pages (probably with magic words like __NOTOC__, maybe __NONS__ and __NOPARENT__). I think it'd look a lot neater for pages such as Category:Morrowind-Places-Tombs or Category:Tes3Mod-Tamriel Rebuilt-Scout, for example. --Gez 06:37, 20 March 2009 (EDT)

Revamping Templates

Time to reveal the real reason why I started my recent bout of extension-writing: I think our templates are ugly and broken and I want to fix them. Just to be clear, I'm not criticizing anyone other than myself with that assessment of our templates: I wrote many of our templates, including the ugliest ones, and I introduced more than a few of the problems. However, we've all been hampered by limitations of the mediawiki template system -- limitations that can only be overcome by updating the wiki's PHP code. In other words, I think we need a new extension with multiple template-related tools.

At this point in time, I'm posting this information on the Admin Noticeboard because my target audience is the site's template editors who, given the current complexity of our templates, are admins or at least editors who notice the Admin Noticeboard. I'm hoping to get feedback on whether some fairly abstract tools (new parser functions and tag functions) seem logical and useful -- and I'm asking for feedback before anyone (other than me) can actually test them or use them. If you don't understand templates, don't expect to understand the rest of this ;)

First, however, let me provide some perspective with some examples of the problems I think need to be fixed with our templates:

• I want to get rid of /Description and /Author subpages. They cause a multitude of problems, which are only tolerated because there's no other way to have shared information. Instead, I want to have |description= and |author= fields that are part of our summary templates (e.g., Book Summary); I want other pages to be able to access those fields -- without having to transclude and process the entire original article.
• The new descriptions should be more flexible -- for example, we need find a different way to deal with links on place page descriptions.
• Templates need to be more legible, in particular by being less complex. Ideally non-template-writers should at least be able to get the gist of what's going on in a template; it shouldn't take experienced template-writers twenty minutes to make sense of a template; it shouldn't take two years of UESP experience to learn how to put together a new infobox template.
• It needs to be possible to meaningfully test templates when previewing them.

I've put together a set of tools that I think can go a long way towards fixing these issues. These are tools that will primarily be used within templates -- in many cases, without requiring any changes to our existing articles (except where we want to clean up our articles to take advantage of new features). I'm also hoping that the tools are semi-intuitive to people who know templates. Also, to answer the first question that will probably cross your mind reading this list: yes, these features are all feasible. Most of this is working in the MetaTemplate extension that I'm putting together -- and so far it is a true extension, that does not require any modifications to the core mediawiki code.

The tools:

• A #define parser function, that can be used to provide default values for any template variables.
  • For example, the Faction/Code template would no longer be necessary. Instead, the Faction template would contain all the code and would start with a set of definitions, such as {{#define:alt| {{{altname|{{{faction|{{{1|}}}}}}}}}}} }}. These are defaults -- so if a specific page specifies {{Faction|alt=My faction}}, the value of alt would be "My faction", regardless of altname, faction, etc. As with many of the following parser functions, this really is more like a parser subroutine: it never returns a value and never displays anything on the page.
  • Another feature of the #define function is a "case=any" flag. So {{#define:imgdesc|case=any}} would specify that calling the template with any of imgdesc=, ImgDesc=, Imgdesc=, or IMGDESC= would be equivalent. No need to constantly repeat {{{imgdesc|{{{ImgDesc|}}}}}} anymore. {{#define:imgdesc|{{PAGENAME}}|case=any}} combines the two features.

• A #preview parser function. It works exactly the same way as #define, except it only takes effect when you are previewing a template.
  • With this function, you can test exactly what the template will look like for a given set of input conditions -- but if you then accidentally save the template without cleaning up the #preview lines, you won't mess up pages that use the template. Or you might intentionally save the #preview lines so that other editors can see a problem situation that needs fixing.

• A #inherit parser function that tells a nested template to inherit the listed variables from the template(s) that called it. This makes nested templates far more powerful and opens up many possible ways to move sections of complex templates into subtemplates.
  • For example, on Template:Oblivion Places Summary, the section about welkynd stones and varla stones could be moved into an "Ayleid Ruin Summary Section" template, in which {{#inherit|varla|welkynd}} could appear. Then, that template could be nested simply as {{Ayleid Ruin Summary Section}}, instead of {{Ayleid Ruin Summary Section|varla={{{varla}}}|welkynd={{{welkynd}}} }}.
  • So far, the example is just some simplification -- but the idea can then be extended to become truly powerful. Oblivion Places Summary (or Template:Place Summary) could instead call {{{{{type}}} Summary Section}} to insert any type of customized table section for any place type - grottoes, diamond mines, etc. Place Summary doesn't need to know anything about the requirements of those place types. Any required parameters only need to be added to the articles describing those places.

• A #include parser function that works similarly to the existing Include template.
  • In the above example, {{#include:{{{type}}} Summary Section}} would be a better way to include the section template, since it would no longer be necessary to create unnecessary summary section templates.

• A #save parser function that saves a list of variables to a database table added by this extension.
  • This is how /Description and /Author pages can be eliminated: the Book Summary template would include a {{#save:description|author}} line. Or even a {{#save:description|author|title|sortkey|prev|next|lorename}} line, in which case game-specific versions of books wouldn't have to repeat all of the information that's already provided on the Lore version of the book.

• A #load parser function that gets the information previously saved for a given article using a #save command.
  • For example, Book Link would start with a {{#load:{{{srcpage}}}|description|author}} line (where srcpage is my name for the current tt1 parameter, and would be #define'd on the template). To make the switchover easier, the #load template will also check to see whether a /Description or /Author page exists if there is no #save'd data.

• A #nolink parser function. This one is really a parser function ;) It takes the provided text and strips out all links, leaving just the label.
  • The raison d'etre for this function is the place description pages. With this function, we can freely add links to any and all place descriptions -- then use #nolink on Oblivion:Places or other pages where the links are overwhelming. In fact, the links on Oblivion:Places can be turned off by adding a single line at the top of the page (we don't have to modify every place link template on the page), namely {{#define:nolink|true}}. To demonstrate how all of these ideas can start to work together, here's one possibility for what the corresponding Template:Place Link template would look like, fully revamped:

<cleanspace>
{{#inherit:nolink}}

{{#define:place|{{{1}}} }}
{{#define:srcpage|{{NS_FULL|{{{game|}}}}{{{place}}} }}
{{#define:altname|{{#label:{{{place}}}}} }}

{{#load:{{{srcpage}}}|description|maplink|mapname}}

{{#define:desc|{{#if:{{{nolink|}}}|{{#nolink:{{{description}}}}}
                                  |{{{description}}}}} }}
{{#define:maplink|{{#ifeq:{{{mapname|}}}|none| |{{Map Link|ns={{{game|{{NAMESPACE}}}}}|place={{{mapname}}}}}}} }}
</cleanspace>'''[[{{{srcpage}}}|{{{altname}}}]]'''{{#if:{{{desc|}}}| — {{{desc}}}}}{{#if:{{{maplink|}}}| {{{maplink}}}}}<noinclude>
{{/Doc}}</noinclude>

Most of this post boils down to: is this more legible than the existing template? It's assuming that mapname and maplink are #save'd as part of the Place Summary/Oblivion Places Summary template -- which means that Place Link should almost never need to call Map Link, and therefore using the Map Link template will no longer crash pages such as Oblivion:Places. In other words, it's more efficient than our existing template. It's also using the namespace-related functions added by UespCustomCode (which is why ModName disappears).

• A cleanspace tag function, which was already used in the above example. Within a pair of <cleanspace>...</cleanspace> tags, any white space in between tags is removed before the page is rendered.
  • Therefore, #define tags can each be placed on separate lines, #define tags can be separated from #load tags by a blank line, etc. -- all of which make the template more legible.
  • Another effect is that any categories or breadcrumb trails within the cleanspace tags are disabled on the template page (except in preview mode). In other words, the cleanspace tags can replace the includeonly tags that are often used on templates, preventing unnecessary redlinks and non-existent categories from being added to the template pages. However, one critical difference is that the categories and trails are displayed in preview mode -- allowing full debugging of those features, whereas right now mistakes generally don't become visible until after the template has been saved.

• A displaycode tag function, whose only purpose is to alter how the template is displayed on the template page.
  • It's specifically intended for templates such as Hide -- where the template page tells you nothing, so the only way to see what the template does is to edit the page. Putting <displaycode>...</displaycode> around the code on the hide template would act like a pair of nowiki tags -- but only when looking at the template page.

• A cleantable tag function that cleans up any tables found within the <cleantable>...</cleantable> tags. Specifically, if a row is empty, the row is deleted from the table. If all of the rows in a table section are deleted, then the section header is also deleted. (OK, I haven't actually coded up this tag yet, but that's the plan).
  • This will allow infobox templates to be significantly simplified. It will no longer be necessary to embed entire sections of the table in #if statements, which in turn means that templates such as {{!}} no longer need to be used to build the table, and means that getting the spacing correct within templates will no longer be such an ordeal.

• A NESTLEVEL magic word that tells you whether or not the template is being called directly.
  • This is a somewhat more obscure feature, but since I'd been using nestlevel behind the scenes for some of these features, I figured I'd make it available in case anyone else has uses for it. When generating the template itself, {{NESTLEVEL}} returns 0. When the template is being called directly from an article, NESTLEVEL is 1. If the template is being called from another template, that is being called from an article, NESTLEVEL is 2, etc.

I know that's a lot of information to digest, so I'm not expecting any immediate feedback. I wouldn't be surprised if it take a couple of days just to digest the first couple of paragraphs ;) -- I'm asking everyone to start thinking differently about our current templates, to start seeing how they're broken, and then be ready to think about what tools might be necessary to fix them. I have a couple of years head start, which is how long some of these ideas have been kicking around in my head, albeit with many rounds of revamping along the way. I'm finally posting some ideas because I think I may at last have come up with some useful ways to actually make some fixes.

However, once people have started to digest the post, there is alot of feedback that would be useful:

• First, does any of this seem remotely useful? Would anyone other than me actually use some of these functions? Basically, is it worth installing an extension that provides these types of functions?
• Second, do the names make sense to anyone other than me? Are there better names that could be used for some of the functions? Are there ways to make the functions more intuitive? I'd like to get any renaming/major refactoring taken care of early on, before renaming will break any templates that might start to use the functions.
• There is one very unorthodox element introduced by this extension: templates using these functions will no longer look the same in preview mode as they do after you save them. I can see how it might be completely confusing to hit save and see something dramatically different than your last preview. However, I think it's also necessary for meaningfully debugging templates -- we want accurate previews, but we don't want redlinks and broken categories to actually appear on the templates. So, is that too confusing or acceptable?
• Do you think these functions will be able to do what I'm claiming? OK, that's not really a fair question. There are a bunch of details that I haven't covered (to prevent information overload!), which are often important in making the functions really work as expected. Furthermore, nobody other than me can test them yet. Nevertheless, if you do think of any snafus, let me know. Once (if) the extension gets installed, it will be easier to start thinking about this question.
• Are there other aspects of our templates that are driving anyone crazy? Although unless accompanied by concrete ideas of how to fix the problems, it might take me another two years to come up with fixes :P Nevertheless, it's better to get the ball rolling sooner rather than later.

Take your time digesting, and let me know if/when you have some thoughts! --Nephele^Talk 00:24, 20 March 2009 (EDT)

Well my first thought, just on reading the description for #define was "Wow!" If I had a penny for each time I'd wished I could create variables in templates, I'd have, well... about 63p, but it's still a fantastically useful feature.

Question One: can defines refer to other defines? I might just be cross-eyed here but I couldn't see an instance of this in your example. What I mean is, could we change that example to be like this?

...
{{#define:descText|{{#if:{{{desc|}}}| — {{{desc}}}}}}}
{{#define:maplinkText|{{#if:{{{maplink|}}}| {{{maplink}}}}}}}
</cleanspace>'''[[{{{srcpage}}}|{{{altname}}}]]'''{{{descText}}}{{{maplinkText}}}

It would mean complex expressions could be broken down into their component parts to make templates even easier to understand.

The #inherit function sounds like it could be insanely powerful. There have only been a few cases where I've wanted to do what it allows, but most of those have been recent. The example you described is a good one, is almost exactly what I'd been wanting to do myself, and was probably prompted by the same incident. I can think of a few other places where it could be very useful too.

Question Two: How deep does the function nest? I don't have a specific case where I'd want this yet, but if A includes B includes C, can C access A's parameters or just B's?

#include looks good but almost seems like a come-down after the previous two :)

Question Three: Does it offer the same options as the Include template? That is, can you specify several files to include and it determines which exist, and can you have a prefix? Not an important question as it can all be done with #if statements, but I thought I'd ask.

#save and #load are the ones I'm going to have to think about most since they probably represent the biggest change. My biggest concern is the impact on the database. A page like Oblivion:Books would make one call for each author, one for each description, and it would seem logical to stick the Ids in there too. That would add up to around 750 hits on the database. Now that's obviously one of the worst-case examples, and I know each query would be very quick, but given the popularity of Quest and Place pages that would also use this system it needs thinking about. Does the request create a "batch" of queries and then execute them together. If it could be one query instead of hundreds, that would be great. So that means...

Question Four: Could we have a few more details about how this works please?

Having said all that, it's a brilliant feature and I look forward to using it. Anything that gets rid of /Author and /Description pages is good, and I can see the use becoming more widespread as Ids - maybe other data like values and weights - get stored that way too.

The other additions will be also be massively useful, especially cleanspace and cleantable.

Question Five: (prompted by the NESTLEVEL magic word) Currently, the wiki software allows a template to transclude itself once (for examples). Does any of this remove that limitation? I've always wanted to be able to use some kind of recursion. The best example would be for the Quest Stages, where formatting is hard-coded on every page. Wouldn't It Be Nice If there was a way of doing something like:

{{Quest Stages
|10||A stage
|20||Another stage
|30|Yes|Final stage
}}

...and have the template calling itself, stripping off the first three params until there were none left? I know there are risks with that, and probably performance implications, but since you're basically re-writing MediaWiki and it's been on my wishlist for a while, I thought I'd ask!

So in answer to your questions...

1) Yes, this seems hugely, massively, incredibly useful. I can't wait to be able to begin playing with the new toys!

2) The names all make sense, but I'd change #nolink to #removelinks, #trimlinks or something like that to make it a verb and make it a fraction clearer.

3) It's going to seem a little odd at first but it's definitely going to be worth it.

4) It sounds like it. This reply, despite its length, is still only a set of first thoughts. I'll try to find some time at the weekend to take a long look at our existing templates and see how this will affect them. I imagine you've already done a lot of that but I want to be clear on how this will change things. The only problem I can see is with the database as described above.

5) Templates are never going to be exactly what I'd like. Basically, they're a very complex search and replace routine, and it would be great to have some way of having them more functional - turning them into scripts. Having said that, I never cease to be amazed what can be achieved with them and these changes will make them even more powerful.

By far the biggest problem with these changes is going to be doing any work on other wikis! I can certainly imagine myself typing "What do you MEAN you don't have the #define extension installed???" at some point in the future.

The final thought is simply "Thank you!" and "When can we start using them?" –Rpeh^{•T•C•E•} 04:49, 20 March 2009 (EDT)

About this #save: function... If each page gets a saved sortkey, it could allow to remove all the defaultsort instructions; defaultsort would be using the saved sortkey. One thing, though: I suppose that Special:ExpandTemplate (a very useful tool) will be included in the code update, how would this deal with saved values? --Gez 06:23, 20 March 2009 (EDT)

Some answers:

• Yes, #defines can refer to variables defined by other defines. My example included one example: place is a defined variable that is then used by srcpage and altname. The defines just have to be in the correct order -- all of these commands are processed sequentially, so order matters. Oh, and one other detail about the defines: defines are fully resolved when they are processed. In other words, if a define includes some complex, database-intensive chunk of code, the processing only needs to be done once, no matter how many times the defined variable is then used.
• #inherit looks through the entire stack of calls (if A calls B calls C calls D, D can inherit from A, B, and C) -- but only the calls that led to that template (if A calls B and C, C can inherit from A but not B). It actually crossed my mind that checking the whole stack might be too much sometimes, leading to problems with unwanted side-effects, and I considered adding an option to limit the levels that are checked -- but then I couldn't figure out whether you'd want to be able to limit it to the top-most or bottom-most levels. So I left limits as something to keep in mind, based upon what examples actually arise.
• #include allows multiple files to be checked (and if necessary, more than three files -- as many as you want to list). However, it doesn't have the "else" option or the "prefix" option of the Template:Include template. With the ability to do defines, "else" and "prefix" didn't seem necessary any more: you can now do the include once, then freely check the result of the include to decide whether you need to display alternative text, or alter the text. It isn't really anything new, given that we have a template that can already do those features, but converting it to PHP allows it to be a bit more efficient.
• #save only writes to the database once for an article -- even if there are multiple save statements in the article. All of the information is collected as the templates are processed, but then it is only written once the article has been saved (and once I can therefore get the correct revision ID for that version of the article). Some other points about save:
  • Save statements are always ignored when processing the actual template file (i.e., if Template:Book Summary includes a #save statement, it does not create an entry for Template:Book_Summary in the database -- it only creates entries once Book Summary has been transcluded into real articles).
  • One complication that I've identified and haven't fully resolved yet is what happens if there are multiple sections of an article with separate data to be saved. For example, if we wanted to save NPC data as part of the NPC Summary, what should be done on pages such as Oblivion:Dark Brotherhood Murderer? Right now, it will end up just saving data for the final NPC on the page (all the earlier data is rewritten). Do we want to just have a nosave option in the summary for such cases? Or do we want the ability to have multiple sets of data for a single article when necessary? I'm working towards the latter, but all I've really done so far is add the necessary fields to the database table.
  • The other tricky thing with #save is all of the article management necessary to make it work (page moves, deleted pages, page purges, regenerating pages after templates are updated, etc.). I've covered some of the bases, but I have a few rounds of debugging to go before feeling confident that all of the bases have been covered.
• #load reads from the database once for each article that needs to be read. At least once the article data is being #saved, it will just be one call; if it needs to then check for a /Description page and an /Author page, that would be two more calls, but that should only be necessary short-term.
  • The first time a #load call for a given article is encountered, it reads all of the #save'd data for that article and stores the data in memory. Therefore, even if multiple #load calls refer to the same article, and even if multiple variables need to be read for the same article, it still only needs to read from the database once. Reading all of the data once means that I only need to do some sanity checks once; the memory overhead is comparable to the current situation.
  • On pages such as Oblivion:Books that will add up to a lot of database calls -- yet that's still significantly fewer than are necessary right now. Right now, each book listed on Oblivion:Books can potentially require six database calls -- separate calls for /Description and /Author, for each of which it needs to check for the existence of an Oblivion page and a Lore page, then it needs to read the appropriate page. I'm happy with six times fewer database calls ;)
  • Trying to combine the queries any further isn't really feasible, as long as I'm working within mediawiki's standard template processing. I can't easily scan ahead through a document to find all the #load statements (especially since if there are multiple #loads they're likely to all be in templates rather than the main article). The other option would be to put placeholders in the text as it's being processed, wait until the end of the page to batch-process all of the load statements, then go back and replace all the placeholders. Mediawiki actually uses placeholders in this way, but I think it would cause more problems than it would solve in this situation. For example, it would be impossible to then use the description in subsequent #define statements, or in any type of parser function or template processing.
  • A "quirk" of the #load feature is that, for example, Oblivion:Books will look like it's actually transcluding the full content of every book listed on the page. When you edit the page, every book will be listed under "Templates used on this page"; for each book, the "What links here" list will state that Oblivion:Books is transcluding the page. However, that's all just because I'm tricking the mediawiki book-keeping. The reason for the trick is to ensure that Oblivion:Books gets regenerated if the listed books are updated, or even if the Book Summary template gets updated: so that if you change the description of "Arcana Restored", the new description automatically appears everywhere it's supposed to.
• Recursive template calls.... It's possible that some of my tinkering would make recursive template calls possible in some situations, although if so it's an unintentional side effect, bordering on a bug. Truly making recursive calls possible would either require tricking mediawiki's anti-recursion checks or directly hacking the code (and so far all of this has been possible without actually editing the mediawiki code, amazingly enough). Furthermore, I'm a bit reluctant to do so -- I know that the checks are there because of the potential for DoS-type attacks. An infinite recursive template call inserted into a commonly-used template would kill the server: the server would try to regenerate every page using the template, and each attempt would tie up the server for 15 minutes until the request finally timed out. Furthermore, such a problem could easily be caused by a typo from a well-intentioned editor or even admin. As a result, I'd be very uncomfortable making infinite recursion possible -- maybe making a few more levels possible, but I don't think that would really get us anywhere.
  • For your specific example, my first thought is that a template similar to Template:Book Normal might be a better option -- put each line of the table into a separate template.
  • Another thought that comes to mind is some type of argument-splitting function. Something that splits the incoming argument list into pieces, then repeatedly calls a template using those pieces. Something like {{#splitargs:Quest Stages|3}} that would call {{Quest Stages|1={{{1}}}|2={{{2}}}|3={{{3}}}}}, then {{Quest Stages|1={{{4}}}|2={{{5}}}|3={{{6}}}}}, then {{Quest Stages|1={{{7}}}|2={{{8}}}|3={{{9}}}}}, etc. until it runs out of arguments. That's very possible. I'm already accepting unlimited numbers of arguments with some of these functions (or in other words, any limit on the number of arguments is being imposed elsewhere in the system -- I have no idea whether mediawiki or PHP has a maximum number of arguments). That seems less susceptible to catastrophic mistakes, as long as the code makes sure that the split number is a positive, non-zero integer. Is this idea worth pursuing?
• Once this extension is stable and once I've made sure it works with MW1.14 or MW1.15, I probably will post it on mediawiki.org as a publicly available extension. That's one reason I've separated it from UespCustomCode, and it's guided some of my decisions about which function/magic word belongs in which extension. So maybe other wikis will eventually have these functions!
• I'm not sure about the saved sortkey -- a #save only happens once for an article, after all of the templates have been processed; other articles wouldn't want to #load the sortkey, because they would have different names. (The exception being cases such as books where multiple articles share the same title). The three ideas I've had about DEFAULTSORT are:
  • Hack the mediawiki code and hardwire a new, better value for the default sortkey, for example SORTABLECORENAME (see #Code Updates), or any other value that is somewhat closer to what we really want by default on the site. It's a pretty easy hack (and it's even to a mediawiki file that's likely to permanently include UESP customizations).
  • Hopefully, just converting all of our templates to use SORTABLECORENAME will fix most of the conflicts -- I'm hoping it provides a valid sort key for nearly every page on the site, and therefore overrides will be much less common.
  • The least-well-formed idea is to alter the priorities for DEFAULTSORT: make it so that DEFAULTSORT provided in the article itself overrides the values in any templates. That should be possible with some template rewriting, especially using some of these new functions (inherit + define). It would also be possible with some code hacks -- although I think the first suggestion would be a better code hack and would then mean that the only time DEFAULTSORT should be necessary is in occasional oddly-named articles.
• Good point about ExpandTemplate. That's an extension that we would like to add to the site. Unfortunately, it's very actively maintained, which means that it generally requires a very up-to-date mediawiki installation (currently it requires "1.14alpha r42593" -- which I think means the released version of 1.14 is good enough, but I'd have to check SVN to really be sure). So we haven't been able to install it yet (although I just realized that through SVN I could actually get a less-bleeding-edge version of the extension that might perhaps work on our site even before we upgrade....). In the meantime, I'll work on the assumption that it will eventually be installed and make sure that all of these features are compatible with ExpandTemplate. For the most part, it should all be transparent. But I do need to check your point about #save statements -- I'll need to make sure that ExpandTemplate is prevented from writing #save data (although it would still be able to #load data).
• I'll see whether it might be possible for Daveh to get at least a preliminary version of this extension installed this weekend -- assuming that the other extension installations go smoothly enough! Such an installation would be preliminary -- without any more code tweaks, save/load would be available for testing but not stable enough for use in articles and cleantable wouldn't be available, for example. However, that would be enough to let other editors start experimenting with the functions, and exploring how some of our templates could perhaps be revised. Which would need to be done before adding any of this to real articles, anyway, so it can't hurt to get a head start.

--Nephele^Talk 13:46, 20 March 2009 (EDT)

That all sounds fantastic and I'm really looking forward to using it. I think most further questions are going to have to wait until I can start playing for real, but I do have one more now. I've created two sandboxes, here and here to see how I'd go about redoing the Ingredients Summary (first one - not fully finished yet) and then use save/load to #load information on the Ingredients page rather than hard-code it as at the moment. The question is about the cleantable tag. Will it remove the "1st", "2nd" etc rows? For that matter, am I even remotely close to understanding how these extensions work? It's tricky to use something when you can't see the results, but I think I'm on the right track.

I like the idea of the #splitargs function. It would be useful anywhere we have variable-length lists such as NPCs and locations. We'd probably find lots of uses for it if it was around. If it's not a difficult one to code, I'll say "Yes please" to that one. You're right about resursive templates... it's just that it's such an elegant programming technique it's a shame it's not around! –Rpeh^{•T•C•E•} 10:41, 22 March 2009 (EDT)

Whoops - forgot this bit... For Dark Brotherhood Murderer and similar pages, how about putting each one on a subpage and then transcluding for the final page? –Rpeh^{•T•C•E•} 12:54, 22 March 2009 (EDT)

\=>

I would like to join the club of supporters of this great idea. Not that I feel that templates should be readable for any editor by definition, it would limit the freedom of what you can do with it. But it would definitely benefit from improvements like this.

Instead I will jump right to the content, and make some comments about the suggested functions.

cleanspace: Is it possible to forcibly include space characters, abuse html's nbsp characters for example? One problem with the templates has always been readability. You can't format your code like you would with a programming language, being able to include line breaks and indents would be very welcome. Sometimes you need that space character though; not having to close the cleanspace tags and then open them all the time would save alot.

displaycode: I'm not sure I would welcome this approach for template documentation. See Template:Cleanup-obnpcrp. The seperate doc pages work because they seperate template implementation from usage. You just state how a template should be used, and if a person wants to improve, it has to edit the page anyway.

NESTLEVEL: In combination with allowing recursion this could simplify alot of templates, like rpeh stated. I love recursion... :)

The other tags work beautifully for me, though I don't think I will be using them all myself. I'm always a bit wary for odd library functions without some degree of order (like PHP has), but I don't think this is the case (yet) here. --Timenn < talk > 17:53, 22 March 2009 (EDT)

Main Page Talk Vandalism

Yeah, I went ahead and semi-protected Talk:Main Page because it had been vandalized by a bot 9 times since March 17 and 5 times in the last 24 hours. It is only a week long Semi-Protection. I'm also going to slap a notice on the page telling people to use the community discussion.--Ratwar 00:15, 22 March 2009 (EDT)

This Morning's Vandalism

You will probably have noticed some particularly silly edits that occurred this morning: [1], [2], [3] and [4], all from 24.226.32.183. At about the same time, a character called "Zalgo" (Zalgo@ChatSpike-0d7e2092.home.cgocable.net) came into IRC, posted a long string of gibberish and then "The return is imminent". Shortly after that there was a brief (2 minute) DOS attack on the site that slowed things down noticeably.

This is pretty clearly Daedryon back again. I had already reported him to his ISP back in January, and I've just done the same again now. In the meantime, any suspicious activity from home.cgocable.net is probably down to this individual. –Rpeh^{•T•C•E•} 04:20, 23 March 2009 (EDT)

Prev: Archive 11

Up: Administrator Noticeboard

Next: Archive 13