I'll second dokuwiki, although it does store everything in text files. With the right plugins you can make it do all sorts of things, including adding a wysiwyg editor, mirroring the format of other wikis (such as mediawiki), and integrating with google calendars. I've been using it for the past year or so with the non-profit theatre I webmaster for, and we've had great luck with it. I looked at MediaWiki, TWiki, Oddmuse (we used it at work in the past), and a few other even lesser-known wikis before settling on dokuwiki.
That said, I'm surprised by the recommendations for Confluence. We use it at work, and pretty-much universally hate it. There are all sorts of reasons, ranging from unstable code to performance issues to being restricted to a flat page name paradigm within a given namespace (i.e. if you have an "SysAdmin" name space, you can have one and only one page titled "Monitoring"). . Take a look at wikimatrix.org, it's a great way to compare a lot of the wikis out there based on the features you are looking for. Nick Silkey wrote: > > The answer to all four tenets is Confluence. Federates nicely with how > things work in higher-ed. > >> On Apr 27, 2010 3:57 PM, "David Parter" <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> I know, there are a million to choose from. >> >> Here's the situation: >> >> Our faculty (and students) want wikis. And they would like us to >> support their wikis. They haven't exactly said what that means, but we >> can at least define a plausible service offering, and see if that >> works. >> >> Currently we have a ton of different wikis, all in a state of >> disrepair/not being maintained or secure, installed by individual >> faculty and students. We want to do better. We *need* to do better. >> >> Some things we already know: >> >> 1) We think we want a wiki that stores content in a database, because it >> decouples the content from the wiki code, makes migration and >> upgrades easier, and doesn't rely on the unix file system and which >> uid the web server runs as for security. But that maybe a misguided >> idea... >> >> 2) There needs to be some kind of authentication and authorization. This >> is where it gets hard -- we don't have to solve every problem with >> the same tool, but some of our users just need a handful of wiki >> users, so built-in authentication & authorization is ok. some >> probably want to leverage our existing authentication (for example, >> to allow all their students' access) but that may be ok to defer to a >> different solution. >> >> All probably want both authenticated and anonymous users to be able >> to read the wiki (but not post). >> >> 3) If we have to maintain/support the wiki code, we'd like it to be >> secure and reasonable to manage. >> >> 4) they don't all have to be in the same wiki instance, we can run >> multiple instances >> >> Any ideas? I realize this is not an entirely well-formed request, the >> staff person who has been looking into this is rather frustrated, so I >> thought I'd get some fresh ideas. >> >> thanks, >> >> --david >> >> ps: the same exact questions will be asked about "blogs", because some >> people think a wiki is the way to maintain a web site, others prefer >> blogs... >> _______________________________________________ >> Tech mailing list >> [email protected] <mailto:[email protected]> >> http://lopsa.org/cgi-bin/mailman/listinfo/tech >> This list provided by the League of Professional System Administrators >> http://lopsa.org/ > ------------------------------------------------------------------------ > > _______________________________________________ > Tech mailing list > [email protected] > http://lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ > -- Dan Rich <[email protected]> | http://www.employees.org/~drich/ | "Step up to red alert!" "Are you sure, sir? | It means changing the bulb in the sign..." | - Red Dwarf (BBC) _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
