How should we (as a community) handle MediaWiki

Cobalt

@Chime

So, let's talk about what things are needed:

For game owners

The bare minimum I believe:

The ability to decide whether the wiki is open-to-join or requires account creation by staffers.
The ability to decide whether the wiki is open to see or only members can see it.
The ability to create accounts.

For a game's power users and/or staffers
For Staff:

Create accounts.
Lock certain pages.

For Users:

Create pages based on games wikipolicy.
Upload images based on games wikipolicy.

For a typical game player wiki user
See above.

For hosting providers like me
The ability to say "this monstrosity is too big, cut down your image size". ... I'm not sure since I don't really know what hosting concerns there are other than 'size'.

For game owner-and-hoster-types
See above.

surreality

@Cobaltasaurus said in How should we (as a community) handle MediaWiki:

The ability to decide whether the wiki is open to see or only members can see it.

It's worth mention that I think this may be able to be altered to some extent based on namespace. Or, at least, even 'locked down' members-only wikis can have a specific intro designated as 'open to public view' (which may just be the main page, I would have to double-check that one).

I strongly suggest admin-only user account creation. The one wiki I accidentally left open to letting people create accounts was flooded with spam pages almost immediately.

faraday

@surreality said in How should we (as a community) handle MediaWiki:

but I don't know how wikidot, which is on its own servers, is going to feel about people having external non-user sources from another server (the game itself) yanking from or shoving to its server.

See my comment in an earlier reply. It's totally fine, you just have to pay for the privilege (making it not-free).

surreality

@faraday That... yeah, if you are having to pay for game hosting one place, and wikidot as well? I'd nope the heck out of that, especially since that'd probably kill the ability to have the same domain name for both.

Roz

@surreality said in How should we (as a community) handle MediaWiki:

@Cobaltasaurus said in How should we (as a community) handle MediaWiki:

The ability to decide whether the wiki is open to see or only members can see it.

It's worth mention that I think this may be able to be altered to some extent based on namespace. Or, at least, even 'locked down' members-only wikis can have a specific intro designated as 'open to public view' (which may just be the main page, I would have to double-check that one).

I strongly suggest admin-only user account creation. The one wiki I accidentally left open to letting people create accounts was flooded with spam pages almost immediately.

We've eliminated this by basically setting a question-based captcha. That way we don't have to lock user creation to admins, but we don't get spambot issues.

Ninjakitten

@Roz

This is exactly what I was going to say. The game-wiki I've worked with most, I set up a question-based captcha for account creation also, and bar one brief incident where I guess some spammer actually worked out and programmed in the questions and answers (at which point I changed them and no one has bothered with that since), we've been spam-free since. It's been 3-5 years, I think.

faraday

@surreality said in How should we (as a community) handle MediaWiki:

@faraday That... yeah, if you are having to pay for game hosting one place, and wikidot as well? I'd nope the heck out of that, especially since that'd probably kill the ability to have the same domain name for both.

:shrugs: Depends on what you're going for. You can host a MUSH on a Digital Ocean micro VM for $5/month or a GenesisMUDs account for $7/month, and wikidot Pro is $4/month. Add them together and I still think that's comparable to what you'd pay for a server capable of hosting MediaWiki on top of the MUSH server. You can point your domain names so that www.yourmush.com goes to wikidot and mush.yourmush.com goes to the game.

Just to be clear - I don't really care what folks do for their own games. If you like MediaWiki, use MediaWiki. Just responding to the "nope you can't do that" type things I keep seeing in regards to Wikidot.

ThatGuyThere

I am not a big wiki person, but I think Cobalt summed up what I think is needed from an end user point of view.
I would also add not Wikia. I am glad it does not seem to be part of the debate here but I have been on games that used it and I hates it. I would play on a game with a wikia wiki but I would not make a char page there or really use the wiki.

surreality

@faraday You can host the MUX and mediawiki droplet on DigitalOcean for $10/month without a single hitch, on the same domain, in the same place, with the full functionality of mediawiki with every bell and whistle and then some, with semantics and DPL. It's just no contest to me. DigitalOcean steers everyone away from the $5/month package anyway and toward the $10 (their tech people rambled out the reasoning for it but it was over my head) for anything other than the most basic html-only websites, so that's what you'd be paying there anyway if you were hosting with them.

(For another $2/month, you can have automatic backups that will include both the MUX and the wiki together. That's another reason I would steer away from having the game and MUX hosted separately, really.)

Edit: Think of it this way: you've gone above and beyond on MUX code. Someone who wants only the very basics can get by with the SGP stuff thrown in to the base MUX install. You have very sound reasons to want something better than that, even if that could do in a pinch for a novice. It's essentially the same thing; there's a better option out there that has more integration potential, more flexibility, and is ultimately going to be easier for people contributing to this effort to create distributable content for. (@Roz, I suspect that's going to be us in some respects!)

faraday

@surreality As I've said, the contest comes with the ease with which you can install and configure wikidot vs MW. I've used the $5 DO package successfully, FWIW. Anyway, I feel like we're going in circles so I'm just going to bow out at this point.

Lithium

I don't see why we need to come up with a consensus on MW at all. Just like we've not come to a consensus about what code to use. Some like MUX, some like Penn, some like Rhost, etc etc.

Some people like MW, I do, I know how to set it up, use it, and my wiki staffer likes using it.

I host my wiki and my game on the same site without a problem.

So I would say use what is best for you, or what you enjoy using the most, because until now I'd never even cared about what is used for the wiki so long as the adds are not horrible.

Bobotron

@surreality
There's a thing called QuestyCaptcha that goes with a standard MW install extension for captcha that lets you set a text based question in order to sign up. It worked really well for the LaRP wiki without requiring staff to create them.

Thenomain

@Cobaltasaurus said in How should we (as a community) handle MediaWiki:

@Chime

So, let's talk about what things are needed:

For game owners

The bare minimum I believe:

The ability to decide whether the wiki is open-to-join or requires account creation by staffers.

The ability to decide whether the wiki is open to see or only members can see it.

The ability to create accounts.

I spent a few weeks gathering together and testing and pondering the best extensions for the Eldritch wiki. You can see what few we ended up with here:

http://eldritch.mechanipus.com/w/index.php/Special:Version

The single best find was InviteSignup, which is perhaps the best extension for all Mush wikis that you didn't think of. (You thought of DPL3 already, which is the best.)

I would like to be able to link character objects to accounts. (Cough cough Evennia.) Your access to add, remove, post, read things from inside the game, or access information from outside it, could be based on this. It's pretty trivial from inside TinyMUX, but not from outside.

Last I read, the MediaWiki group said they were never going to install an access system beyond locking and editing, and that if this is what you want then use a different system or create a different installation. This deeply sucks.

Oh, and because I can, hee hee hee on @Chime putting herself in the position to continue maintaining a PHP install. I feel for you.

Tat

So now that I'm home and have a bit more time to devote to something other than flailing about how much I love Semantic Wiki, I thought I'd take a look at what the original post actually asked. SO.

For game owners

I think the things @Cobaltasaurus set out are good ones - game owners need to have at least some basic level of control over who's editing what, and in some cases, who's seeing what.

I'd add:

Mostly hands-off admin after primary set-up
Well documented

I'm personally less interested in the 'easy to get up and running the way you want' than I am the 'easy to use once it is' - I'm happy to put in a lot of work at the get-go to get a wiki that doesn't require much upkeep or handholding on my part. I get that not everyone thinks this way, though.

For a game's power users and/or staffers

Easy to use
Flexible
Well documented

I'm not saying that a wiki should be able to do ANYTHING you want, but flexibility is one of the things that sets mediawiki apart for me. The array of extensions is simply INSANE.

In addition, because wikipedia runs on it, as well as wikia (for better or worse, probably the second most popular wiki site), there are tons of tricks and tips documented. There's also an active, responsive community to ask questions of.

For a typical game player wiki user

Easy to post and create content
Easy to find and read content

This is where Semantic Wiki blows everything else (that I know of) out of the water. The forms alone have erased a lot of staff effort helping people understand fill-in-the-blank templates. But more importantly, the ability to build targeted searches makes it really easy to find old information. Since we started keeping logs on the wiki, the ability to search in detailed ways has been very useful.

For hosting providers like me

I don't have much to say on this one - we simply went from paying for space for a webpage to paying for space for a wiki. I installed it (a process I found absurdly easy) and customized it (definitely a lot of work to get to the level we're at now, though I keep stealing things from old wikis at this point).

I'm definitely curious about where your frustration points are.

If what you're aiming for is a game-in-a-box that includes a mediawiki install, I'd probably suggest a basic install with a few additional extensions up and running, and a depository somewhere of easy-to-tweak templates for commonly used things like character pages or logs.

The extensions I'd call must-haves are

Arrays
DPL (IF not using Semantic Wiki - I'd consider Semantic advanced MediaWiki'ing)
Parser Functions
WikiEditor
Input Box
Confirm Edit with QuestyCaptcha plug-in

A handful of these I think you can actually choose to install on mediawiki install these days.

If you're being really nice, I'd also include a skin that isn't the god-awful Monobook.

I'm not sure if this really gets at what you're asking - these are the reasons we stick with MediaWiki and why I like it, anyway.

Chime

@Tat said in How should we (as a community) handle MediaWiki:

I'm personally less interested in the 'easy to get up and running the way you want' than I am the 'easy to use once it is' - I'm happy to put in a lot of work at the get-go to get a wiki that doesn't require much upkeep or handholding on my part. I get that not everyone thinks this way, though.

Well yes. Ultimately the setup should be to ask the owner a few questions in some web form, have them push a button, and bam-- a wiki-- with zero interaction on my part.

For hosting providers like me

I don't have much to say on this one - we simply went from paying for space for a webpage to paying for space for a wiki. I installed it (a process I found absurdly easy) and customized it (definitely a lot of work to get to the level we're at now, though I keep stealing things from old wikis at this point).

I'm definitely curious about where your frustration points are.

Heh. Well-- you pointed out it'd be nice for these things to be hands-off. They aren't. Not remotely.

Game owners like to have these things-- wiki, forum, etc. and they never conceive of the idea that they should keep them up to date and patched from vulnerabilities.

PHP and virtually everything written in it has an atrocious track-record on the security side. So do many other things, and I don't really see a lot of good wiki alternatives that don't use PHP, but that developer ecosystem is particularly bad and has been so since its creation.

Individual game owners do not keep things up to date, and never will. Do they have the permissions? Yes. Can they? No. It isn't hard, but they just won't do it.

That leaves it to me to do when necessary, or to pull sites down. Upgrading 30 different wikis with incompatible config files and breakage points manually is kinda hellish, especially when people then feel entitled to blame me because their shit broke when I updated it.

That's not going to work. It can't scale, and I can't waste that much time on stupid php crap. The discussion here was to get a better sense of how all these wikis (within mechanipus and elsewhere) are being used, so that when I have a new mediawiki deployment and management feature it will do what people need it to do. A list of Extensions-- which many people have provided-- helps quite a bit.

End goal is to have a single mw install with a tiny php stub in each user's site that sets it up to run as their wiki and holds their config. There will be only one copy of the main Extensions list, one copy of all the normal mw source and language files, etc. That way, when they send out yet another warning email saying oops-we-blew-it-again, I can trivially update that one install.

If what you're aiming for is a game-in-a-box that includes a mediawiki install, I'd probably suggest a basic install with a few additional extensions up and running, and a depository somewhere of easy-to-tweak templates for commonly used things like character pages or logs.

Yep. Both for use for games I choose to host and usable as a package for people rolling their own somewhere, or for hosting companies that want to leverage these ideas for-profit. Any and all of those are fine.

The extensions I'd call must-haves are

Arrays

Hm! Yes, that looks interesting.

DPL (IF not using Semantic Wiki - I'd consider Semantic advanced MediaWiki'ing)

DPL, yes, though I've been sold on Semantic.

Parser Functions

WikiEditor

Input Box

Yep.

Confirm Edit with QuestyCaptcha plug-in

I don't particularly like captchas, but automated spam deterrents are necessary, so this is probably essential. Question based ones are certainly better than the "identify something like a word in this picture of abstract noise."

If you're being really nice, I'd also include a skin that isn't the god-awful Monobook.

Vector is included in the default install, for a while now. Most new wikis default to that. Anything using Monobook is horrendously antique.

I'm not sure if this really gets at what you're asking - these are the reasons we stick with MediaWiki and why I like it, anyway.

Thank you. This is wonderful and useful information.

Ninjakitten

@Thenomain said in How should we (as a community) handle MediaWiki:

The single best find was InviteSignup, which is perhaps the best extension for all Mush wikis that you didn't think of. (You thought of DPL3 already, which is the best.)

::goes to look at that:: If I'm reading it right, then I would still greatly prefer using QuestyCaptcha, because I don't want anyone else to have to be involved in getting people wiki accounts. I just want spammers to find it too much trouble to get one. "In which city is this game set?" (as a random example off the top of my head) is trivial for a real person who plays on the game, but tends to be a major stumbling block for a bot.

Tat

@Chime

Thank you. This is wonderful and useful information.

Oh good! I like to be useful. We do have a few other extensions that are pretty essential to how we use the wiki (for example, a faux-blog and threaded discussion pages), but the ones I listed will definitely get you the basics and, I think, are very popular and so should be kept up to date when mediawiki or PHP needs updated.

Now I'm considering that we should probably update and I'm thinking about what that might break and it makes me so very tired, so I can't imagine doing it for dozens of sites.

Thenomain

@Ninjakitten

Bet you a dollar that I could invoke InviteSignup from within the game. That dollar payable to Chime's Patreon.

See, I think that even minimal interaction for account creation should be handled by staff, regardless of it's on the game or on a wiki or on some web boards for posting. Maybe if there were stricter access controls, I'd be happier. For example, sign up and get one (1) character page. Basic staff verification and get free reign to edit the "setting" namespaces. Further verification and add pages to the "setting" namespaces. Etc.

The problem with all of this is no two of us are going to agree on everything. I throw out my own ideas in hopes that they make an impact when it comes down to making that decision.

Ninjakitten

@Thenomain
Yeah, you probably could invoke it from within the game. That might be okay. If Fred can get a wiki account by putting his email into a command on the game, and THAT triggers the invite automatically and he can go from there, with no one else having to touch anything, that'd be fine with me.

But I think we just essentially disagree, because I think wiki account creation should never have to wait for staff to do something. If Fred gets the urge to make his character page at 3am because he doesn't have RP, and he hasn't made his wiki account already, I don't think he should have to wait until staff is around to make him one. I hate it when that happens to me, and I haven't had any problems with players being able to just do it themselves once spambots are stymied.

Thenomain

@Ninjakitten

Which is why I mentioned a stepped account creation system.