I use mediawiki just for study notes, it has been really easy for everything I have done. Apparently Dokuwiki is a pain to upgrade. Bianca

I'm using PmWiki to manage some notes for a project I'm working on. It can use a database, but by default uses flat files which suited me better when I was setting it up.

On Mon, Jul 30, 2012 at 11:55:09PM +1000, Trent W. Buck wrote:

ikiwiki, gitit, moin, mediawiki -- in that order.

Actually, top of the list would be a git repo of reStructured Text and a makefile to churn out read-only static HTML. (Not a "wiki", in the c2 sense.)

I keep meaning to look at gollum one day (https://github.com/github/gollum) but it fails your static requirement. Karl

Karl Billeter wrote:

On Mon, Jul 30, 2012 at 11:55:09PM +1000, Trent W. Buck wrote:

...

ikiwiki, gitit, moin, mediawiki -- in that order.

Actually, top of the list would be a git repo of reStructured Text and a makefile to churn out read-only static HTML. (Not a "wiki", in the c2 sense.)

I keep meaning to look at gollum one day (https://github.com/github/gollum) but it fails your static requirement.

Meh. Looks like yet another NIH wiki. FWIW my requirements were/are: - MUST be dvcs-backed (SHOULD be git) MUST be able to make updates via the vcs. - SHOULD be reST (and thus SHOULD support PDF output) - SHOULD support a "dumb" static httpd via a make-style post-compile pass. - MAY support optional editing via a "smart" httpd with some kind of in-browser edit screen. - other shiny features, like tags, cross-references, indices, in-browser body searching (cf. git clone & grep) are OPTIONAL. Currently in the office we're using gitit, because management upgraded edit-via-browser to MUST and gitit has better reST support than ikiwiki... except that experience has shown that the haskell implementation of reST is pretty ordinary compared to the reST spec, or the Python implementation thereof. For my personal stuff I just have a bunch of .txt reST docs in doc/ in my dotfile repo, which technically has a makefile to render to PDF and HTML, but I haven't bothered to use for years -- I just link to the .txt version. For professional documents (like product manuals), I've nearly convinced management to use git+sphinx[*] instead of ODF. Which is a Super Nice thing. [*] sphinx is docutils plus some large/complex document extensions, and vastly better default .sty and .css stylesheets. http://sphinx.pocoo.org

Quoting Trent W. Buck (trentbuck@gmail.com):

ikiwiki, gitit, moin, mediawiki -- in that order.

Actually, top of the list would be a git repo of reStructured Text and a makefile to churn out read-only static HTML. (Not a "wiki", in the c2 sense.)

Concur, though the latter might not suit the use-case. I like the short and unproblematic dependencies lists of ikiwiki, gitit, and moin. Any system that's back-ended into a SQL database (e.g., Mediawiki) creates, if nothing else, one extra headache for ensuring meangful backups -- that is not present with a system using file-backed storage.

Tony Langdon <vk3jed@gmail.com> wrote:

That's not exactly useful here, since I want a real wiki, with multiple people able to edit pages. ;)

Ikiwiki and others on the list you quoted can do that.

Hi Brett

On Mon, Jul 30, 2012 at 9:08 PM, Tony Langdon < vk3jed@gmail.com > wrote: Can anyone recommend a Wiki package that can be run on a Linux host (LAMP or otherwise)? I might have a project which requires a wiki.

Consider what the surrounding environment needs to look like. Is it for internal use in a group/company, will you need to regularly add users, is it public and people need to sign up (and then be enabled by you or not). Depending on those things, your choice will differ - otherwise maintaining becomes a pest.

I did some testing of basically every wiki software available for debian a while back. My favourite is PMwiki - http://www.pmwiki.org/

It's quite simple to install and configure. Quite a large selection of 'cookbooks' (user submitted extensions). Still undergoing constant development. I use this personally.

We used PMwiki for a while in a few spots, and had to get rid of it. Indeed it's very nice with its extensions, but the user management is atrocious and because it's file based it's more difficult to scale (we have a resilient/redundant infrastructure). We got hideously stuck at quite a bit of expense (time wastage). Inside my company we now use the wiki that Redmine has per project/client which is very handy, as Redmine takes care of the permissions and client can edit stuff of their own (something I didn't expect them to do, but they do!) I contributed some patches to the wordpress Wiki plugin to make it behave decently, and now it's pretty usable. Cheers, Arjen. -- Exec.Director @ Open Query (http://openquery.com) MySQL services Sane business strategy explorations at http://Upstarta.biz Personal blog at http://lentz.com.au/blog/