So today, I discovered that MoinMoin has an “all or nothing” attachment setting: either everyone with write permission to a page can upload attachments, or uploading attachments is disabled for the entire site. No exceptions. Period.
Not only that, but there is no maximum attachment size setting — unless the attachment was uploaded embedded in a ZIP file. How’s that for irony?
Not wanting to have my railroad site turn into a file trading site, I don’t really want to let everyone upload attachments.
Oh, also MoinMoin doesn’t maintain a history of attachments. So if somebody drives by and vandalizes an attachment, you get to…. restore the original version from tape. Yay?
So I decided I’d look back at MediaWiki, which has better attachment controls.
I still had my test installation, so I went to use it. I edited the main page. I wanted to read about the markup, so I clicked the “Editing help” link. Whoops, broken link. It links to Help:Editing on the local wiki. Which MediaWiki does not install for you. I asked about it on #mediawiki. The answer was: copy from mediawiki.org. OK, fine. How? “Cut and paste.” Yes, that’s right. Every time a new version of MediaWiki comes out, you get to cut and paste dozens of pages from mediawiki.org to your wiki, or else you’ll have outdated help. Yay?
The MediaWiki folks on IRC seem to like it this way. “Not everyone wants the same help.” Fine, but provide a sane default for those that don’t care.
Who thought running a wiki would be so hard?
Update: since yesterday, I went to moinmo.in and fixed the ThemeMarket page to reflect what versions a MoinMoin theme works with. I’m happy to help out with fixing Free Software — though I don’t really have time to add fundamental features like working syntax help links on this particular project.
Not to toot my own horn too hard, but ikiwiki
* Automatically updates all underlay content when the package is upgraded.
* Has a rather rich language for controlling attachment uploads. Example:
virusfree() and
((user(joey) and podcast/*.mp3 and mimetype(audio/mpeg) and maxsize(15mb))
or (!ispage() and maxsize(50kb)))
Hi Joey,
I’ve heard lots of good things about ikiwiki, and always trust your software. Part of the thing about this site though is that it is targeted at a non-geek audience, both in terms of readers and writers. It needs to be at least somewhat “flashy” (in a good sense, with themes) and ideally have a WYSIWYG editor.
I think ikiwiki is far ahead of the others on many of the nuts and bolts issues. The main thing that looks like it’s missing there is strong anti-spam measures (akismet or recaptcha would be great). I see your CSS market now (googling for ikiwiki themes hadn’t been helpful), and there are some usable designs there. I’ll have to give it a more serious look too.
I’ve built an internal website using ikiwiki and liked it very much. Adding WYSIWYG was easy, I just included TinyMCE into the edit page template and set the default page type to html. Of course, for a public site, you’ll have to filter the resulting HTML.
As for MediaWiki documentation, I agree that downloading docs from mediawiki.org is just too painful. However, the docs on wikipedia.org are usually pretty nice, so just linking to them solves most of the problems.
You could look at infogami which runs openlibrary. It allows semantic markup unlike most wikis. It also allows users to write their own skins and templates, using a Python-like language which the server runs in a sandboxed interpreter.
Not-exactly-random example page:
http://openlibrary.org/b/OL22647856M
You have my attention :-)
John,
On Mediawiki, if you can put together a list of the help pages you want you can use the ‘Special:Export’ page to pull them all down as a single xml file and import it into your Wiki.
Still a bit of a PITA, but slightly easier than Cut and Paste.
… I just remembered, you can also use ‘Special:Allpages’ to get a list of the pages in the Help namespace.
I discovered I could also select by Category:Help, which did what I wanted reasonably easily.