Doom Wiki:Central Processing/2015


< Doom Wiki:Central Processing
Revision as of 05:25, 4 August 2014 by Jartapran (talk | contribs) (August 1 upgrade)

This is the central discussion forum for wiki editing and administration activity on the Doom Wiki. Feel free to ask any questions or pose any concerns you have here, and you should receive a response shortly. Check the archived discussions for older threads.

Archived discussions


I added Template:Rquote from Wikipedia, where it is deprecated and use is discouraged, but I personally like the style of it and think it would be a good way to do quotes on this wiki where we have slightly less formality. Opinions? --Quasar 00:28, 4 January 2014 (UTC)

I suppose it'd fit for things like the level descriptions lifted from Hexen 64 (e.g., "In these frozen caverns, relentless ice [etc.]" in Guardian of Ice) and maybe for NPC pages (like Jack Campbell), though they're already using Template:Quote. --Gez 08:07, 10 January 2014 (UTC)
I prefer the Template:Quote style for those top-of-the-article quotes. This was an idea for extended quotations from literary sources or people that are within the article text itself. --Quasar 17:57, 13 January 2014 (UTC)


I am finding more and more articles that are marked as stub status but contain more or less all the information that can be said on the subject. I am starting to remove stub status from some of them, but it's way more than I can handle. I'd request that if you come across any articles which have been substantially fleshed out but still have an ugly stub header at the top, take the time to remove it. A perfect example and one I just fixed was the Delta Complex map article. All of its sections are filled out with information and I don't know much else that could be added to it but it was still marked as a level stub. --Quasar 19:30, 29 January 2014 (UTC)

Did some shoveling.  I think "more or less all the information" is often subjective, especially for a non-technical topic like a person.
Quasar, given your post above, what do you think of these articles?  I created them years ago, then tagged them as stubs after some people complained that they were very sparse.
Ryan W 02:56, 3 February 2014 (UTC)
The first looks significantly complete. The other two have empty sections. Those sections should either be filled out with info, or removed if the sections are irrelevant. Until such happens I'd consider them to still be level stubs. --Quasar 17:35, 4 February 2014 (UTC)

Captchas broken again

Somebody sold us out through Mechanical Turk again more than likely. As I don't feel like spending the next year blocking the entire Indian subcontinent, I've switched over to some randomized QuestyCaptcha code I found on the Internet. Let's see if it performs any better. --Quasar 15:27, 6 February 2014 (UTC)

A recent series of registrations by users with regex-pattern-matching user names who subsequently make no edits has made me suspicious that the new code, which included a random "Please tell what the current day of the week is in GMT" option (with link to Google) is susceptible to a dictionary attack or possibly even bots with AI coded to be able to answer that particular question. I have modified the code in LocalSettings again to remove that option, so we are currently only using questions that ask for a random character from an MD5 substring that's calculated on a GUID seeded with output from mt_rand. I will continue to tweak and strengthen the code if it proves necessary. --Quasar 17:12, 2 March 2014 (UTC)

Moving pages

I just noticed I can move some pages but not other ones for no reason I can notice. For example, I can move Mancubus fireball clipping but not Blood. Why so? --Kyano 10:12, 3 March 2014 (UTC)

Good question.  It appears to be a result of FlaggedRevs configuration.  By default, after a page has been reviewed (at any level of quality), only admins can move it.    Ryan W 01:42, 4 March 2014 (UTC)

Incidentally, the move of this page was never properly reversed, so all prior edits look like they pertain to the /2013 subpage.  Does anyone know how to fix this without erasing author attribution for any edits?    Ryan W 06:54, 13 March 2014 (UTC)

I'm afraid that ship has sailed, particularly since this page has been edited repeatedly since. I don't think it's that big a deal though. --Quasar 14:15, 13 March 2014 (UTC)

Images with an incorrect aspect ratio

In the following days, I will fix most if not all of the images in the "Screenshots using an incorrect aspect ratio" category. Speak now or forever hold your peace. --Kyano 22:17, 5 March 2014 (UTC)

One thing to watch out for would be any that are actually widescreen shots and are correctly rendered. I know the shot of Eternity on the Eternity Engine page had been mistagged as being incorrect aspect ratio at one point (it is in 16:10 widescreen IIRC). How many shots are we talking about? If I have time, I can help by reviewing them for issues like this. --Quasar 01:38, 6 March 2014 (UTC)
(edit conflict)  There are 199 images in the category.  It's true that the tagging was probably done based only on the dimensions of each uploaded file.  That said, I see a bunch of my ancient E1/E2 walkthrough snaps in there, which are probably safe to batch up.    Ryan W 01:59, 6 March 2014 (UTC)
My original idea was to just resize 640x400 to 640x480 and 320x200 to 320x240 and leave the rest untouched. That should be safe enough. Most of the images in that category with that problem have that size. If there's something wrong it can always be reverted. What do you think? --Kyano 13:11, 6 March 2014 (UTC)
Based on discussion ongoing here at File_talk:Tuttifrutti.png I am going to ask that you hold off on this for the time being. It's becoming quite clear that there are a number of exceptional images that are not classifiable only by their logical aspect ratio or dimensions and have been placed into this category incorrectly. --Quasar 16:27, 12 March 2014 (UTC)
Quasar, I saw your IRC posts.  Nobody said I was an authority on the technical characteristics of rendering :>   but the key thing is that categorization was done haphazardly, a few images at a time, by people with varying degrees of expertise themselves.  So in addition to what you say, there might be hundreds of *un*tagged files needing fixes.
Trying to be constructive here... um...
For certain uploaders, it may be on the record or really obvious which port was used (e.g. Ducon and myself).  For the others, if we could define a reasonably accurate "decision tree" for identifying the common situations you mention, we could re-sort, then talk about mass resizing.    Ryan W 04:06, 13 March 2014 (UTC)

Well here are the guidelines I'd stick to if you want to make progress without damaging any files that shouldn't be resized:

  • The dimensions should be 320x200 or 640x400 to be an immediate candidate. It's very likely anything else was rendered by a source port (which doesn't automatically mean they are correct but that they need more careful treatment, see below).
  • If the image is 320x200 or 640x400 but has a correct-looking (non-squashed) HUD, or sprites that look tall instead of broad (ie they do NOT match their appearance if extracted from the IWAD and viewed on a square-pixel display) then its been rendered with inherent aspect ratio correction by a source port. One of the ones we found and I was talking about on IRC was such a pic, at 640x400 size. It was basically rendered like 16:10 widescreen would be correctly rendered (wider FOV, rescaled HUD that looks tall instead of fat).
  • Just to be clear, as this category is already covered by my first suggestion, the "looks fat instead of tall" thing only works for shots that are 16:10. If the pic is already 4:3, like the one linked above, you can't correct it by rescaling - I suspect that one in particular is a Doom 95 shot and it renders its 4:3 modes in a very odd manner. You won't fix these by rescaling them.
  • It's still worth considering, for 320x200 images in particular, that a loss of quality is incurred by rescaling them to 320x240. This particularly hits numbers on the status bar, and port elements like the BOOM HUD, badly. I feel uncomfortable with the idea of introducing tons of scaling artifacts in the name of chasing after proper aspect ratio as an ideal. It's not necessarily the most important thing about the pics we have in some cases, I think.

--Quasar 14:06, 13 March 2014 (UTC)

I seem to recall a couple of my shots being redone with professional tools, i.e. cropping the HUD and then pasting it back in, with no apparent artifacts in the final copy.  Any media editing is inherently labor-intensive though, as exemplified by the manual check in your second bullet point.  Maybe the next logical step is a bot that reviews new image dimensions and warns the user before they upload 150 more?  :P      Ryan W 17:52, 13 March 2014 (UTC)

Source extension

I guess we need to have a debate on whether we want to keep/use the source extension. It seemed like something that would be very useful on an often highly technical wiki like this during the install process, so it was one I specifically selected for addition. I didn't know it had compatibility problems with wiki markup though. That's a bit discouraging. I have also run into problems with finding any method of imposing a right-hand margin on the code it produces in the past. --Quasar 01:50, 6 March 2014 (UTC)

The incompatibility is easy to understand as instead of merely telling MediaWiki the text block should use monospaced font (and respect whitespace), it tells it it is raw code. So interpreting markup elements would generally be undesirable. For a pseudocode example:
<source lang=php>string $foo = '\ . $bar . '\;</source>
string $foo = '\ . $bar . '\;
I don't think we're using a lot of markup in preformatted blocks, though (contrarily to the ZDoom wiki). The edit I reverted just happened to be on one of the few. --Gez 03:02, 6 March 2014 (UTC)
Makes sense, thanks for the input. Would you say you're in favor of keeping the extension around though? --Quasar 03:11, 6 March 2014 (UTC)
I think another solution should be found. While this wiki doesn't have a lot of source code snippets, the ones that there are should have highlighting. If the problem is that it's not possible to highlight portions of code (for example, bugged code, since most of the code snippets are inside the "Errors and bugs" category), work should be done to implement that feature in the source extension. My two cents. --Kyano 10:21, 15 March 2014 (UTC)

<tt>, <code>, etc.

This issue has been raised these last days due to some edits I've been doing. It turns out there are two ways to represent monospaced words/sentences: using either <tt> or <code>.

  • <tt>: that's what's being used in most of our articles now. It looks_like_this().
  • <code>: that's what's used in a few articles. It looks_like_this().

As you can see, the biggest apparent difference between the two is that <code> adds a grey background.

I personally support changing all <tt> occurrences to <code>. There are several reasons from my point of view:

  • <code> adds a grey background, which serves as a visual separator from the rest of the sentence which goes beyond the font (which is monospace for the two).
  • It's what Wikipedia is doing. For example: the Hello world program article. As you can see, they use <code> for all code samples inside sentences. On top of that, the big snippets of code also have a grey background, for consistence.
  • <tt> is currently deprecated and does not exist at all in HTML5. Should MediaWiki transition to HTML5, all <tt> occurrences will have to be replaced. That will not happen today, but it will end up happening at some point.

If the grey background is a problem, it can be removed at CSS level. But, again, I strongly support keeping it. As I've seen there's a habit in this wiki of avoiding the imposition of style policies, but something should be decided in this regard :)

On a related note, there is a bug in the rendering of both tags in Chrome: the fonts of <tt>, <code>, <pre> and the source extension look much smaller than the rest of text. Wikipedia noticed the bug and then fixed it by adding these lines to their CSS file:

<source lang="CSS"> /* Fix so tags look the same in Google Chrome. */ tt {

   font-family: monospace, sans-serif;

} </source>

Thoughts? :) --Kyano 15:00, 29 March 2014 (UTC)

I'd suggest doing what I did on the ZDoom wiki and using a template to wrap these tags. So you replace <tt>blah</tt> by {{c|blah}} instead of replacing it by <code>blah</code>. This makes it easier to update everything at once if needed. Personally, I don't really like the a background color change in text placed within a paragraph, I find it ugly and distracting, and I think the font change should be enough to serve as visual separator. It's why I still use tt instead of code. (On the other hand, if it's outside of a paragraph, then yeah, give it a different background, which is why I wrapped some <source> tags inside a prettytable. --Gez 15:28, 29 March 2014 (UTC)
That's another possibility, suggested by Quasar. At that moment, I thought it would be overkill (like using a template just for bold text), but maybe it's the best solution.
By the way, I think a grey background for <source> should by added with CSS so we don't have to do dirty tricks. --Kyano 20:37, 29 March 2014 (UTC)
I agree with Gez as previous discussed on IRC that <code> with a gray background is inappropriate for single words in the middle of a sentence. It harms readability. BTW I slightly edited your comment to maintain the discussion formatting, Kyano. I favor the template as a long-term solution and I believe it should simply expand to <span style="font-family: monospace, sans-serif;">{{{1}}}</span> --Quasar 21:31, 29 March 2014 (UTC)

Admin Rights Movement

To continue a discussion that spawned here: let's discuss which rights admins currently don't have that they really should. For a start, suppressredirect. Any right that corresponds to actions that can already be done in a different way (here: move then delete the redirect) has no reason to be denied. --Gez 19:39, 3 April 2014 (UTC)

Actually, rereading that page, I don't see anything else matching your last sentence (anyone please speak up if I missed one).  Additional rights defined by MediaWiki, or extensions, but currently *unused* might be more interesting.    Ryan W 23:36, 3 April 2014 (UTC)
Okay, I reviewed the documentation and am adding subsections accordingly, so it needn't be an all-or-nothing decision.    Ryan W 22:59, 4 April 2014 (UTC)


Admins now have suppressredirect. Cleaned up some other stuff while I was in there - chiefly, trying to setup captcha skip for emailconfirmed group as recommended by the ConfirmEdit documentation on MediaWiki does absolutely nothing because emailconfirmed hasn't been a user group since MW 1.13... I guess nobody ever reads or updates extension documentation. --Quasar 05:25, 4 April 2014 (UTC)


A special page for executing history merges in one step instead of several.  Seems straightforward, as Gez says.    Ryan W 22:59, 4 April 2014 (UTC)

I have given sysops this permission effective as of now. I do expect all use of it to proceed with overly paranoid caution however, as it is an inherently dangerous capability as spelled out on the Wikipedia page you linked; incorrect merges cannot be easily reverted. --Quasar (talk) 15:45, 4 July 2014 (UTC)
Heh, half the time our admins don't see an issue to begin with (myself included).  But thank you.    Ryan W (talk) 18:59, 4 July 2014 (UTC)


A special page for making the entire site temporarily read-only (including admin actions).  I proposed this to Quasar long ago as a method for dealing with robo-spam or DoS, in case he or Manc couldn't be found quickly.  He disagreed, saying even that wouldn't be urgent enough for such drastic measures.  Currently, any admin can disable editing by performing 60,000+ rangeblocks.  :>     Ryan W 22:59, 4 April 2014 (UTC)

I disagreed that doing it through rangeblocking was necessarily better than shutting off Apache or setting .htaccess to deny all in the backend; but the overriding factor with that is the rangeblocks > /16 being broken in versions of MediaWiki prior to 1.2x (at least I hope they've fixed it by now). If there's a frontend way to do it differently, I don't necessarily have an objection to it. --Quasar 14:33, 5 April 2014 (UTC)
I never said it was better, just faster, but you're entitled to disagree that it would be helpful in the first place.  To put it another way, if 200 bot accounts suddenly appeared to spam us at 30 edits/minute, and you and Manc were both traveling for the weekend, would there be risk to the servers themselves, or just a big on-wiki mess afterward?    Ryan W 19:57, 5 April 2014 (UTC)
P.S.  Nope, not fixed yet.    Ryan W 02:13, 13 April 2014 (UTC)


Admins already have tboverride, which allows creation of pages on the title blacklist; this allows the same when creating new user accounts.  Very rarely used, no doubt, but if the admin can be trusted with one of these rights, it seems logical to have both.    Ryan W 22:59, 4 April 2014 (UTC)

How do you create a new account while logged in as an admin? I guess that's my main question. --Quasar 14:35, 5 April 2014 (UTC)
Go to Special:UserLogin and click on "create an account". --Gez 17:22, 5 April 2014 (UTC)
I can do that as well and I'm not an admin... --Kyano 17:24, 5 April 2014 (UTC)
Interesting.  What happens when you try to activate it?    Ryan W 19:57, 5 April 2014 (UTC)
It works perfectly. --Kyano 20:00, 5 April 2014 (UTC)

Upgrade Plans

Manc and I intend to attempt to upgrade MediaWiki next Saturday, 4/19/2014. The wiki may be locked for editing starting sometime during the day before so that we retain a fully up-to-date set of dumps and backups in case the whole thing goes tits-up. There will be some unavoidable fallout from the procedure:

  • Monaco skin is most likely going bye-bye as the rebuild is not compatible with MW 1.18 or above. This is going to leave us in need for a new customized variant of Monobook or Vector as the default skin. Suggest posting your proposals. I'll want to be adopting something that is palette appropriate for Doom, and not sticking with a bright white background everywhere like the defaults have. That's going to require heavy customization of the CSS for whatever default we choose.
  • Along with that loss, we'll lose the very nice sidebar menu. I'll be doing research on what if anything is available as a replacement.
  • The FlaggedRevs extension will likely be going away and all of our revision approval data will be lost, because it won't import into the new version cleanly for whatever reason. We have two options with this - drop FlaggedRevs permanently, or install the newest version of it on the new instance and start from scratch. Also suggest posting your opinions in response to this. FlaggedRevs has been the most controversial aspect of this wiki since its migration, which is something to take into account.
  • All extensions will be updated, and some may go away if they're found not to work. In the same vein, some new ones may be added such as the new Mobile Version plugin which optionally provides an optimized view of the site for handheld devices - these extensions require MW 1.2x and so we've had no chance of using them so far.

--Quasar 17:53, 12 April 2014 (UTC)

1. Monaco replacement. No opinion. I use Monobook exclusively, and the only time I see Monaco is when I'm logged out, prompting me to log back in ASAP to make it disappear. :p 2. FlaggedRevs. I think that, in practice, we haven't really needed it? If we lose it, I don't think it'll be much of a problem. --Gez 18:20, 12 April 2014 (UTC)
1. I only use Monobook. 2. Happy to see FlaggedRevs disappear. 3. Something should be found to replace the sidebar menu. 4. Remember to update the YouTube extension as I asked, please. --Kyano 21:33, 12 April 2014 (UTC)
2. Now that I have examined the matter thoroughly, I suggest we'll try without FlaggedRevs in the upgraded version and consider re-installing it if there are considerable problems with the control of new edits. Time will tell that. --Jartapran 14:07, 14 April 2014 (UTC)
I agree. I always oppose to the use of FlaggedRevs, but maybe it's really solving a problem that I'm not seeing just because of the existence of the extension. --Kyano 14:10, 14 April 2014 (UTC)
1. Personally, I like Monaco simply because I like the color scheme--I've gotten used to the dark area at the side and top of the screen. 3. Did FlaggedRevs ever have any effect beyond displaying an annoying message below the article name? JudgeDeadd 15:30, 16 April 2014 (UTC)
What, you missed all the whiny forum posts, and my rants about user permissions?  Jeez, we put a lot of work into that.
The idea is, if you don't have an account or aren't logged in, the "annoying message" is temporarily hiding the most recent edits.  That means if you're playing or mapping, and you quickly open the wiki for a hint, you don't get this.    Ryan W 14:01, 17 April 2014 (UTC)

Updates as of 4/13: It may be possible to keep Monaco; I've found some other wikis that are using it on 1.22.5, and I've emailed their bureaucrats to see if they know anything about how to keep it working. In the event they can't help and it does not work, however, I've done some preliminary work in Firefox's inspector on a possible Monobook CSS styling that is similar to our Monaco default - beta preview here. Input is welcome. --Quasar 23:12, 13 April 2014 (UTC)

I like that. Please remember it would be good to have the modifications done at the end of the Monobook css file or preferably on a separated css file. Classes can be overriden easily. That would help with eventual theme or mediawiki version updates.
On a related note, would it be possible to have a theme for mobile phones such as the one Wikipedia has? --Kyano 09:16, 14 April 2014 (UTC)
The technically correct thing to do is actually to clone the monobook skin entirely and overwrite the CSS for that clone, and then offer that as a new skin option on the wiki. I may do that even if we do manage to keep Monaco, as I actually like the look of the modified Monobook. Not sure I'd make it my default, but it would be nice option with some additional tweaking. --Quasar 14:29, 14 April 2014 (UTC)
Let's call it Demonobook! :p --Gez 14:47, 14 April 2014 (UTC)
Agree. --Kyano 19:10, 14 April 2014 (UTC)


Well it took the better part of three days but we are now running on fully up-to-date software:

  • The head revision of dantman/monaco-port does work with 1.18+, but required MAJOR modifications to work out glitches and missing elements. So we still have our default skin. I'll be forking dantman soon on github and we'll be maintaining our own code base for it from now on (edit: Now available here).
  • FlaggedRevs seems to have miraculously survived. Needs thorough testing.
  • EmbedVideo came up as a question mark during the process but seems to be working as well.

Report ANYTHING unusual, ugly, detrimental, or dangerous here ASAP. --Quasar (talk) 01:21, 21 April 2014 (UTC)

Many thanks to you and Manc for another grim investment in the long-term stability of the wiki.
Needs thorough testing   Um... such as?  (I expect to be back at my computer in about 24 hrs.)    Ryan W (talk) 02:29, 22 April 2014 (UTC)
Just watch out for anything strange, in general.
Right now the only bad problem I'm aware of, and it's one that existed before the upgrade but seemed to have less impact than it does now, is that File: pages cannot be marked as reviewed unless you make an actual change to them after uploading. I think this is a Flagged Revisions bug to be honest.
One problem that's still possibly incompletely solved is missing system messages for some of our extensions. If you see this you'll see text similar to <some-message> or possibly &lt;some-message&gt; depending on the context, where you'd expect to see English language meaningful text. The fix for this is simple - I just have to upload some JSON files that didn't unpack out of the .tar.gz and .zip files properly. Don't try to create the missing system messages under MediaWiki namespace; it's incorrect to do so with the way things work now.
--Quasar (talk) 03:41, 22 April 2014 (UTC)
That File: bug is not in the bugzilla, and probably should be (at least one of the experts might tell us it's deliberate).    Ryan W (talk) 15:59, 25 April 2014 (UTC)
Here. The first thing I did after discovering this was still broken was search for a report and add a comment to it. --Quasar (talk) 19:08, 25 April 2014 (UTC)
Hmm, whoops!  Glad you did that.    Ryan W (talk) 19:40, 25 April 2014 (UTC)

License upgrade proposal

I am opening a proposal to upgrade the license of this wiki to the latest version of CC-BY-SA, which is 4.0 International. Because the CC-BY-SA 3.0 allows automatic upgrading, it is legally possible for MancuNET, as the publisher of the content, to upgrade this license without need for any legal processes or extensive opt-in/opt-out process. However, I want there to be a general consensus at least before taking such an action. The chief benefits of an upgrade are in the significantly more clear wording of the new version, which makes explicit reference to the simplified version's terminology - Attribution, and ShareAlike - in the legalese version of the license; and there are also additional protections against addition of DRM to the data, similar to those added by GPLv3 over the GPLv2 (regarding WIPO's so-called "technological measures").

This wiki would remain compatible with CC-BY-SA 3.0 resources, as they all allow license upgrading. It would not however be possible for 3.0 licensed wikis to use the content here without either upgrading, or creating and managing a mixed-license environment. That's perhaps the downside with regard to other community wikis, though a possible upshot as far as it concerns theft of our material by Wikia (this is not my overriding concern in proposing the license upgrade, but it is a factor deserving of consideration).

--Quasar (talk) 19:16, 25 April 2014 (UTC)

Do the CC license allow the addition of special permissions? We could then have a list of wikis allowed to use DoomWiki content. Though in most cases, it's not really needed I guess; content is either already present in some form for basic information you can find anywhere on the net (e.g., WAD format specifications), or the content is more likely to get a different presentation focused on the other wiki's needs with an interwiki link to here for more general information. At least, it's how I handle things with the ZDoom and SLADE wikis. --Gez (talk) 20:25, 25 April 2014 (UTC)
No, and such would be against the spirit of the license, besides requiring the permission of all previous contributors. --Quasar (talk) 20:48, 25 April 2014 (UTC)
I waited to respond until I could review the license text.  While I don't endorse all of Quasar's theories about third party re-use of our content, I agree that we should upgrade sooner or later.    Ryan W (talk) 21:03, 1 May 2014 (UTC)
I support updating to CC-BY-SA 4.0. The list of changes looks pretty uncontroversial. It seems like a sensible move.
It sounds like the main purpose here is to deny Wikia the right to use our work. This might work in the short term but I suspect Wikia will upgrade all their wikis to CC-BY-SA 4.0 at some point in the future anyway, so it's not likely to last for long. That said, upgrading to 4.0 is the right move anyway.
I would quite like to see us try to compete by just having better content rather than license lawyering, as I think this is a healthier and more productive attitude. But I've been horribly idle in my contributions to the wiki so I'm not really one to talk :) Fraggle (talk) 15:34, 1 July 2014 (UTC)
I wouldn't say main. It's the reason I originally looked to see if there was a newer version of CC BY-SA, I can admit that. But upon doing the research and finding out the stuff above about it, I felt it was a good idea regardless of that factor existing. I do agree though - improving this wiki faster than the paid editors/shills that have taken over the other site has to be our main goal (and I've been working overtime on it so far :) --Quasar (talk) 17:56, 1 July 2014 (UTC)

Misuse of Interwiki extension

When I turned this on I figured there would be measured, careful use of it and instead, in the last 24 hours, several interwikis to open independent sites we are trying to establish good relationships with, such as the Homestar Runner Wiki, have been deleted, and a few interwikis which we may have actually had links using, such as the 'c' prefix, have been deleted - leaving me with the inability to now find any of the articles that were using it via the API, since, it doesn't exist now.

I have turned off access to this extension for everyone until there is sufficient discussion about the strategy we are going to take in cleaning it up from this point forward. --Quasar (talk) 04:42, 28 April 2014 (UTC)

PS: Some discussion that occurred on IRC can be seen here.

I have hopped on SpiderMastermind and restored the three that are problematic deletions (two wikia generic redirects, and the HR wiki). I'll wait for Gez to catch up with this before re-enabling the extension, but here are the guidelines I personally feel we should follow:

  • Some specific wikia community interwiki? Delete it. These are garbage mostly. If we have one for Wolf3D or Chex Quest, those should be made exceptions.
  • Links to independent wikis, especially ones relevant to gaming: leave them in place. We may have cause to utilize them.
  • The following wikia interwikis need to be left in place for historical reasons: w:, wikia:, c:, community: - there are a lot of old talk page revisions with commentary by Wikia staff who linked to certain things relevant to those discussions, and in some cases these are still valid links and have even recently been useful to me (in particular, tracking down some of the old Monaco documentation that was linked to by Kirkburn). By deleting these interwikis we're sort of modifying what somebody said in the past, which is bad - it's a form of censorship in a way. I have verified we didn't have any links to their help namespaces left however; those were all in mainspace and have been expunged.
  • Links to all the WikiMedia resources obviously should be left alone (wikipedia, wikiquote, wikitionary, metawiki, etc). These are critical.

I would prefer that you err on the side of caution if you're not sure. Post about it here and we can decide what to do in collaboration. For now please focus on clearing out the reams of non-gaming-related wikia subdomains as they're the main thing cluttering up the table. --SpiderMastermind (talk) 07:45, 28 April 2014 (UTC)

I have only been deleting irrelevant wikia wikis and dead non-wikia wikis (which were most probably irrelevant too). For instance when I went through A-E, I left things like bulbapedia or diablowiki, which I do not expect to be actually relevant and used here. Good to have a list of protected wikia interwikis, though I'd suggest maybe using a bot to remove use of redundant prefixes since both w: and community: are the same thing (and I'd kinda rather see them as wikia:, wikia:c, and wikia:w personally but it's not very important).
c         	http://$
wikicities:c	http://$
wikicity	http://$
Not that redundancy, in itself, is necessarily a bad thing. I'd really be tempted to add shorter interwiki prefixes like dengine:, eternity: or zdoom: for dengine_wiki:, eternity_wiki: and zdoom_wiki:.
Also there are some wikis that I want to add to the table because I figure they might be useful: vgmpf (useful for the music pages, e.g. vgmpf:At Doom's Gate would lead to, modding ( has useful info on OPL and PC sound), and uesp: (best independent wiki for ZeniMax/Bethesda info). --Gez (talk) 11:56, 28 April 2014 (UTC)
Using my QueryBot to find all the uses and then eliminating the duplicates is within the realm of possibility. I'll give it a look-see. The extension is re-enabled for admins now. --Quasar (talk) 13:12, 28 April 2014 (UTC)


I think the cleanup is mostly finished. I got rid of all non-meta wikias and of all dead or non-English wikis I could find. The table is still rather large and full of irrelevant fluff, but at least it's mostly independent fluff. (There's some Curse wikis on it, but they aren't as bad as wikia and they don't have in their URL). Some questions remain: what to do with nonwiki stuff like skypeme:, acronym:, google:, rfc: or oeis: ? What do we do about irrelevant entries that aren't even wikis, like susning: (someone promoting his books) or ursine: (a company that sells fencing)? wlug: doesn't use the good address for its wiki, but should it be updated or deleted for being irrelevant? --Gez (talk) 17:31, 28 April 2014 (UTC)

I have (finally) reviewed my actions in the interwiki table log.  Almost all prefixes fell under Quasar's first bullet above, as I hope I made clear in the summaries.  However, a few were additional Wikia "central" links, and although they were unused, I didn't verify that before removing them, for which I apologize.


Ryan W (talk) 02:04, 28 July 2014 (UTC)

Continuing problems

I had to restore mediawikiwiki as it seems dozens of links are using it. Again it is not ideal for there to be duplicates in the table, but please please PLEASE do not delete any more of these types of interwikis until I have a chance to run a query to find out whether or not they are used anywhere. --Quasar (talk) 01:14, 6 May 2014 (UTC)

Apparently that was me.  It never would have crossed my mind that anyone would type that, when [[mw: has always been available and is already far more common (similar to how [[community: is never used because [[w: and [[wikia: were retained).  I guess I underestimated the number of quick fix edits needed during the migration [1].  Sorry, Quasar.  Your query offer should help with future deletions anyway.
I just got a fresh dump, and here are the prefixes in use.  This includes unmodified system messages, but a link in a template only counts once.
Prefix Uses
[[c: none alone, but 80 as [[w:c:
[[choco: 1
[[combine: 1
[[dew: 3
[[doom_wiki: 56, but they're interpreted as project space links [2]
[[eternity: 3
[[eternity_wiki: 1
[[gta: 1
[[hrwiki: 5
[[m: 40
[[mediawikiwiki: 3
[[modding: 5
[[mw: 48
[[odamex: 1
[[pcgaming: 1
[[simpsons: 1
[[tfwiki: 1
[[thinkwiki: 1
[[uesp: 1
[[uncyclopedia: 2
[[unidoom: 1
[[vgmpf: 24
[[w: 240, not counting [[w:c:
[[wikia: 57
[[wikicities: 6, none of which are [[wikicities:c:
[[wikiindex: 2
[[wikipedia: 3104
[[wowwiki: 2
[[zdoom: 1
[[zdoom_wiki: 10
Ideally, someone could figure out a regexp search for two left brackets, followed by a string not containing two right brackets, followed by a colon.  That would rope in prefixes which were never valid, or were dropped by Wikia before we left.
Ryan W (talk) 03:46, 8 May 2014 (UTC)
I'd still like to run queries through the API, as dump searches have missed things in the past (I remember there being an estimated ~5 occurrences of mancubuses but a more thorough search later turned up something closer to 10 of them). There's a very simple query that can be run to find all links on the wiki, in all namespaces, that are using a given interwiki. I just have to have time to write the JavaScript, and so far that hasn't happened this week despite my best efforts. Thanks for the table though, it may be useful. BTW I was only guesstimating that there must be dozens of mediawikiwiki links based on the fact that I just kept on running into more and more of them. After the 4th one I found, I decided to restore it figuring there could be a lot more. This was after I fixed the ones I'd already found to use mw: instead. --Quasar (talk) 05:51, 8 May 2014 (UTC)
I did have a post here bemoaning the loss of our iwlinks table data which was breaking the API; however, a MW dev (or just expert user) recommended the rebuildLinks.php maintenance script; even though it didn't advertise that it would do so, it appears to have rebuilt this table, so I'm in good shape to try automated queries now --Quasar (talk) 18:52, 8 May 2014 (UTC)

FlaggedRevs File glitch

Due to lack of any progress against the bug in FlaggedRevs that is driving us nuts with File namespace articles, I have disabled the extension from applying to them. You should no longer see any reviewed status or flagging UI for such articles. --Quasar (talk) 15:03, 29 May 2014 (UTC)

New FlaggedRevs glitch or odd behavior

On several recent article edits, a wide range of historical revisions have suddenly become considered unreviewed despite the history plainly stating that they are. I fixed the first one just by reviewing the latest revision. I fixed the second one by going back in time, unaccepting the last revision by Gez, and then re-accepting it, leaving only the newest 2 revisions as unreviewed. Why is this suddenly happening and what in the world could be causing it? Is there a pattern to these edits? Is there ANY possible logical reason for this, or is it yet another glitch in what is quickly becoming the largest waste of our time instead of a helpful tool? --Quasar (talk) 15:57, 29 June 2014 (UTC)

This happened again as of today on Zombieman; I was not able to reject the latest two changes alone because the last approved revision was apparently suddenly from early 2013. This time it may have had something to do with the article having a quality review status higher than normal... I am wondering if this is a common thread between all of the problems that have been cropping up. Either way, this is weird and unpredictable and is becoming problematic. If we could at least understand why it's happening and what to do about it, that would be a start. Otherwise, if we don't make some progress, I will be considering uninstalling FlaggedRevs permanently in the near future. --Quasar (talk) 16:54, 30 June 2014 (UTC)
I personally have encountered similar problems with this extension in the past but then I blamed it on my lack of understanding of how it works. In my opinion and experience, the behaviour of this extension is erratic and unpredictable and the extension itself is not needed for us. While I agree that a method to temporarily hide potential vandalism is good to have, a buggy and overly overly overly complicated extension is causing more problems than it mitigates. This is: I think that if we decide to keep this functionality, we should find some other simpler extension. --Kyano (talk) 17:08, 30 June 2014 (UTC)
The main thing for me at this point is that we barely utilize it above the level of functionality already provided by MediaWiki's built-in patrolling capability, which has none of the accompanying issues. Given that patrolling has been made a more prominent feature in the latest MediaWiki also (at least more so than I can remember it being in the past), the time may just be right to start using it instead. --Quasar (talk) 18:19, 30 June 2014 (UTC)
If there is a patrolling system built-in already that allows us to hide edits before they have been approved by a trustable user, we should be using that instead. I don't think we use or we will use the rest of things FlaggedRevs has to offer. --Kyano (talk) 20:23, 30 June 2014 (UTC)
Patrolling won't hide revisions. It just marks that someone has reviewed the edit for issues. That's most of the use we're currently getting out of FlaggedRevs by only ever marking things at the lowest review level. The hiding of the unapproved edits is the one benefit of FlaggedRevs, as it means things like spam edits aren't seen by web crawlers, but that's the extent of benefit at the current time. --Quasar (talk) 20:27, 30 June 2014 (UTC)
So that's a problem. How do other wikis deal with this? I know Wikipedia itself just pretends there's no such thing, leading to some funny results. Of course, Wikipedia can't do anything like what we would want to do -- their project is massive. On the other hand, I've always been worried that anonymous people may be discouraged to contribute knowing that their edits will be hidden for a specific lapse of time and that they may be completely rejected. --Kyano (talk) 23:16, 30 June 2014 (UTC)
Revert vandalism and spam as quickly as possible. That's the only other mechanism available - editor diligence. --Quasar (talk) 04:01, 1 July 2014 (UTC)
I'm starting to agree that costs outweigh benefits with this extension.  Kyano is correct that people have ditched us as a result (in combination with other "enhancements", like the captcha for adding links).  Note that using patrolling would require a discussion about user rights; currently only admins can do it, and given the number of human spammers we've had, I doubt we should enable it for all registered users.  :7     Ryan W (talk) 19:12, 4 July 2014 (UTC)

Someone just did this and, by combining the mighty powers of FlaggedRevs and QuestyCaptcha, I haven't had the nerve of doing anything about it -- I just don't know what I'm undoing or what I'm going to break.

First, if you click "diff" on the Recent changes page, you're taken to a diff between the blanking and the last revised edit which was like two years ago. As Quasar said, part of the historical revisions of articles were magically invalidated. So I had to go to the history tab to do the correct diff and then undo it. But then when I clicked Save, I was taken to the captcha, with no diff (just the article itself), so I don't know what in hell I'm undoing. It's like editing blindly.

On the other hand, it's obvious that FlaggedRevs has "hidden" this particular method of vandalism, so it's not completely useless -- but for obvious problems like this one, there has to be another way, like an extension or bot. Wikipedia already has similar things we can take a look at. And, well, we have things in place already. Don't we? --Kyano (talk) 00:37, 4 July 2014 (UTC)

I'm not aware of any other extensions that do what you're talking about, and bots don't come out of thin air. First, to be running as a constant process, a bot needs a server to live on. Second, a bot needs substantial AI to discern good edits from bad ones. Finally, you need the code for it period. Find a reliable open source vandalism reversion bot first, and then we can talk about where to run it. --Quasar (talk) 15:50, 4 July 2014 (UTC)
Well, the extension that does what I say is probably AbuseFilter, since it can recognise edits based on patterns and tag or block them. Forget about the bot, but just for your information, they are usually written by editors of Wikipedia using Pywikibot and run on Toolserver. --Kyano (talk) 16:17, 4 July 2014 (UTC)
Wikipedia has many bots running on people's home machines, but one has to know what one is doing (e.g. not corrupting the cookies from your main account).  Do ISPs ever address high-speed transactions in their terms of service?  Certain bots are indeed open source, but the rules/regexps generally aren't; someone more polite than myself would need to PM the maintainer, or simply start a new list tailored to this site's experiences.    Ryan W (talk) 17:44, 4 July 2014 (UTC)
This problem has now been fixed. Upon examining the FlaggedRevs tables in the database, I noted that the Automap article (which I did a test edit on before locking the database for testing) had adopted the newest row in the flaggedrevs table that had a valid fr_rev_timestamp. That field is supposed to be set for every entry in the table, but for over 7000 entries in our table it was an empty string. Apparently the previous version of FlaggedRevs wouldn't populate this field if you had FR_REV_INCLUDES enabled. Under the version we're now using, this field is expected to always be populated. Why the update script didn't fix this when we installed the newest version, I cannot say so, I had to manually repair the table in phpMyAdmin with raw SQL updates. I also fixed up the current revision on Automap and verified the other pending pages aren't having that problem. Test edits afterward show the system now working as expected. --Quasar (talk) 05:38, 5 July 2014 (UTC)

Another problem I just encountered. When editing an article with a quality approval, even if you are a reviewer, the edit boxes populate at the default levels for an editor and not the qualities that the article was previously approved with, and you have to manually go back in time, find the levels, and re-apply them. This is getting ridiculous. --Quasar (talk) 21:55, 4 July 2014 (UTC)

Captcha for external links

I have seen that adding new external links to an article triggers a very very pesky captcha, even for me, being an Editor. Is that intended or an oversight? --Kyano (talk) 23:19, 30 June 2014 (UTC)

The ability to exempt people from the captcha was based on the emailconfirmed user group, which was deprecated in MediaWiki 1.16 and does not work any more AFAIK. It doesn't seem the author of QuestyCaptcha has seen fit to provide an alternative exemption mechanism since then, either that or the documentation for the extension was still out of date last time I checked it. --Quasar (talk) 03:59, 1 July 2014 (UTC)
Editors should have the skipcaptcha, movestable, and movefile user rights.  I think that's common sense.    Ryan W (talk) 00:17, 4 July 2014 (UTC)
I think that what he means is that we have an extension called QuestyCaptcha which cannot be configured via user groups other than emailconfirmed. (Correct me if wrong.) --Kyano (talk) 00:20, 4 July 2014 (UTC)
I might be more apt to agree if we didn't have autopromotion enabled; if we're going to grant dangerous rights such as movestable to people who earn autopromotion, then we'll have to make the promotion criteria more strict as we discussed earlier but never got around to actually configuring due to the sheer amount of other stuff necessary. --Quasar (talk) 13:26, 4 July 2014 (UTC)
Autopromotion should have been turned off as soon as it was discovered.  The criteria were never presented for community approval, and is someone going to tell me that all the recipients are here to work collaboratively and build a reliable knowledgebase?    Ryan W (talk) 17:54, 4 July 2014 (UTC)
If we removed FlaggedRevs as the previous section suggests, these issues would become irrelevant of course...    Ryan W (talk) 17:59, 4 July 2014 (UTC)
To be fair I had left it enabled because so far it's worked fairly well. Most of the people (I can think of one exception but he's no longer an active editor) have been deserving. However, we do need to review the criteria as they're currently set at the default. I'd probably personally prefer a slightly longer trial period for people if we're going to assign them more rights via the editor group. --Quasar (talk) 14:32, 7 July 2014 (UTC)
I've assigned skipcaptcha to the editor and reviewer groups, but the other proposals from Ryan will require due caution. --Quasar (talk) 15:30, 4 July 2014 (UTC)


Just out of curiosity, I would like to know what are the rules that trigger tags. --Kyano (talk) 00:44, 4 July 2014 (UTC)

Most of them are created by AbuseFilter. --Quasar (talk) 15:19, 4 July 2014 (UTC)

July 4 vandalism

After the blanking of two articles of primary import, I think we should discuss whether or not the article blanking abuse filter should be set to disallow instead of tag. How often will anon editors have a legitimate need to blank any article? --Quasar (talk) 15:56, 4 July 2014 (UTC)

I say never. --Kyano (talk) 16:18, 4 July 2014 (UTC)
Ugh.  Sadly, I have to agree.    Ryan W (talk) 17:55, 4 July 2014 (UTC)


As discussed, we need consensus on how much time should pass to make a vote (such as a VfD) effective. We have a lot of stalled votes, some of them from several years ago. --Kyano (talk) 09:09, 7 July 2014 (UTC)

To clarify (after IRC discussion), this means a maximum time for a deletion thread to run.  When that time elapses, if the admin sees no consensus — either opinions are divided, or participation is insufficient — then the article is kept.  Anyone still wishing to delete must begin a new thread.
I'm undecided right now.  This would reduce one symptom of low participation (maintenance backlogs) without addressing the real issue, and in the meantime some awful articles stay up longer.  On the other hand, we know that the community's views on notability can evolve, and we shouldn't blindly assume that opinions posted 2 years ago still represent consensus.    Ryan W (talk) 10:20, 10 July 2014 (UTC)

Use of interwikis for links to other games as a guideline?

I think it'd be a good idea to start preferentially using links to the appropriate game-oriented wikis when linking to a game, which often have much more in-depth coverage than Wikipedia. We have the interwikis set up, and some of the other wikis are already doing this for us (virtually every mention of anything Doom-related on combineoverwiki links to us, not to Wikipedia:Doom, for example), so this is returning the favor by helping to build a network between our sites. --Quasar (talk) 06:20, 20 July 2014 (UTC)

Yes. --Kyano (talk) 07:50, 20 July 2014 (UTC)
Can't argue with that.    Ryan W (talk) 15:43, 20 July 2014 (UTC)
A good idea, but we'd probably need to have a list of usable game wikis somewhere then. Wikipedia is generally a safe fallback. --Gez (talk) 18:23, 31 July 2014 (UTC)

Big fat list of Vfd

Ladies and gentlemen, I'm laying here a list of articles that are currently (as of today, I mean) in a VfD. I know there is a category but I'll just leave this here, along with the dates, which I think are important.

Also, these categories:

Also, these files:

I did not vote on most of them because I'm a horrible person, but you knew that already. --Kyano (talk) 21:21, 25 July 2014 (UTC)

About the Bruiser Demon case, my opinion three years later would be that maybe the policy ought to be rethought. I think there is some justification for having pages on individual resources when they are notable enough. Many custom monsters have become more-or-less standard staples (and I'm not talking just about custom ZDoom monsters here, DeHackEd wonderkids like the evil marines or the afrit are memorable and noteworthy) and I've seen them discussed casually in Doomworld threads that weren't specifically about them. And we do have individual articles for one specific kind of resource already (maps), so given the emergence of gameplay mods which do not have maps but do change monsters and weapons, it might be time to allow individual articles for other resources than maps. Just to be clear though, I think this should be reserved for memorable resources that have been used in several high-profile works and where the behavior has known little or no alteration between their various versions. So the Bruiser Demon (KDIZD, Stronghold, ZDCMP2...) would qualify, but the upside-down orange caco from Zen Dynamics (and AFAIK no other mod) wouldn't. --Gez (talk) 13:32, 28 July 2014 (UTC)
I agree for the most part, but it's important IMO that we very strongly distinguish between these resource monsters and the original ones. For example, having them in their own category (not just Monsters, but maybe User-created monsters or some other suitable subcat). --Quasar (talk) 14:35, 28 July 2014 (UTC)
As a side note, the proposed speedy deletion criteria would only affect two of these, Doom23.gif and Ralphis.jpg (and the first might need to stay until the glitch gets fixed, can't remember).    Ryan W (talk) 23:16, 1 August 2014 (UTC)

Dedicated featured article pages

Being a new kind of thing for this wiki, the only thing present is the subpage on the Entryway talk page: very hard to discover without being in-the-know.

I propose that we have a main article at Doom Wiki:Featured Articles that can list past and present entries, and outline what exactly about the articles makes them featured, items that stand out among the rest. In addition to this, Doom Wiki:Featured Articles/Nominations can hold as the grounds to propose nominations and vote on them, or even its talk page; other subpages may just arise out of a need to archive old stuff, but that could be a year or more off. --Chungy (talk) 08:10, 26 July 2014 (UTC)

I'm not opposed but want to think about it for a while longer :P --Quasar (talk) 14:32, 28 July 2014 (UTC)
Whatever the eventual title, yes, obviously it should be linked from that section of Entryway so people know where to nominate/vote.    Ryan W (talk) 23:19, 1 August 2014 (UTC)

August 1 upgrade

Manc and I have updated to the newest stable MediaWiki (1.23.2) and newest compatible versions of all extensions. Be sure to report anything unusual or broken. --Quasar (talk) 17:54, 1 August 2014 (UTC)

Note: image uploads and generation of thumbnails are currently disabled due to a file system permissions error. I will post here when it's been resolved. Until then please avoid uploading new images, changing the size of thumbnails, or adding new images to articles. --Quasar (talk) 19:07, 1 August 2014 (UTC)
Indeed. It's just a matter of getting someone to suit up, get on a car, drive to Manc's house and wake him up. With a gun. We are the Borg. You will be thumbnailed. I'm not drunk, this is serious. Yes it is. --Kyano (talk) 21:18, 1 August 2014 (UTC)
The upgrade changed the following in my preferences (annoying but minor):
  • "Email me when a page or file on my watchlist is changed" became checked.
  • "Image size limit" went to the default value (and now has different choices IIRC).
  • "Add pages and files I edit to my watchlist" became checked.
Ryan W (talk) 23:18, 1 August 2014 (UTC)
It does not appear that the image issue will be addressed until Monday at the earliest, as we are not able to make contact with Manc, who stated he was going out of town for the weekend earlier. The basic wiki administration account does not have sufficient access rights on the server to perform the needed operation (chown -R) and there appears to be no suitable alternative that does not represent a security risk. --Quasar (talk) 16:02, 2 August 2014 (UTC)
The image thumbnailing and uploading problems are now taken care of (thanks Manc). --Quasar (talk) 01:06, 4 August 2014 (UTC)
Special:Contributions puts a comma in the year field.  I'll check the Chicago manual if needed, but I'm pretty sure that's wrong.  Bug filed [3].    Ryan W (talk) 00:48, 3 August 2014 (UTC)
As noted on IRC, despite that I cannot reproduce it, I must say the most probable cause is that the new control used for that input field is a <input type="number">, which is to be used for, well, numbers; it shows two little arrows that allow you to change the number without having to move your hands over the keyboard. That's not bad per se but leads to this. Too lazy to go and see whether it's possible to remove comma with an option within the HTML code. Not our job though. --Kyano (talk) 01:22, 4 August 2014 (UTC)
This is nothing too serious, but it seems that the edit counts shown on Special:ActiveUsers are currently from the last 90 days instead of 30. --Jartapran (talk) 09:43, 4 August 2014 (UTC)