[Discuss] Creating a Wiki server

[Greg Rundlett (freephile)]

Some additional information about MediaWiki...

On Sun, Aug 28, 2011 at 4:11 PM, David Kramer <david at thekramers.net> wrote:

> On 08/28/2011 12:31 PM, Tom Metro wrote:
> > Kyle Leslie wrote:
> >> Any suggestions on a set up.  I have seen some things about TikiWiki and
> >> MediaWiki.
> >
> > My vote is for Twiki (http://twiki.org/).
>
> I used to have a TWiki instance on my server for a long time, but I
> ditched it because there were an incredible number of security problems.
>  They were pretty good about fixing them, but one exploit hit my server
> and I lost a lot of work.  This was a long time ago, so I don't know if
> it's still true, but I personally would never use it again.
>
> I have long ago switched to PMWiki (http://www.pmwiki.org), which I find
> easier to use, easier to work with as an administrator (it's written in
> PHP instead of Perl), and has an extensive collection of plugins.  I use
> it on many projects.
>
> > MediaWiki obviously has the advantage that almost everyone is familiar
> > with it due to Wikipedia, but I find that the markup syntax is
> > inconsistent enough that I still refer to the documentation, despite
> > perhaps a decade of semi-regular document authoring in MediaWiki.
> >
> > Can you even get a WYSIWYG editor for MediaWiki?
>
> That's what I don't get about MediaWiki.  It doesn't have WYSIWYG built
> in, the markup is well documented, but a bit awkward, especially for
> tables, which I use a lot, but it's got this reputation for being the
> best.  You can add a WYSIWYG plugin though:
> http://smwforum.ontoprise.com/smwforum/index.php/WYSIWYG_extension
>
>
That's a nice plugin which I didn't know about.  There has been a lot of
work at various WYSIWYG implementations for mediawiki, as the
http://www.mediawiki.org/wiki/WYSIWYG_editor page points out.  That page
does not mention the one I've used for a long time called wikEd which is a
pseudo WYSIWYG editor:  http://en.wikipedia.org/wiki/User:Cacycle/wikEd_help


> > It doesn't seem to
> > provide much of a framework for setting up a document hierarchy with
> > standard navigation controls to move up/down the hierarchy. (Maybe with
> > a plugin?) Instead you get a breadcrumb trail that reflects whatever
> > random path you took to the current document, with no real indication
> > where the document fits in or how to navigate to siblings or parents.
>
> I don't fault MediaWiki for that, because what you're looking for works
> counter to Wiki philosophy.  To state that there is a fixed breadcrumb
> trail to a given page is to state that there is only one (or one
> "official" way to get to that page.  Wikis are about crosslinking from
> multiple places, and that's what gives them power over a simple document
> repository.
>

I tag my wiki articles into categories using natural language nouns, verbs
and phrases, and use a category cloud on the home page to expose the
contents of the wiki.


>
> Your particular usage may lend itself to breadcrumb trails, and you can
> probably create them yourself, but I wouldn't expect that to be
> automatic (though it is in Confluence, which we use at work, and the
> breadcrumbs often get "confused" because there isn't just one path to
> most documents).
>
> For instance, in PMWiki, pages can be divided into groups, and you can
> define many things at the group level, including the header and footer.
>  So for my Agile New England (http://www.agilenewengland.org) project,
> the PMWiki instance we use to coordinate volunteers has a separate
> WikiGroup for each team, and each team's WikiGroup has a defined header
> with links back to the main project page and the team's page.  We also
> define authorization at the group level.
>
>
For hosting wikis with multiple groups, one approach is to create a wiki
"farm" (or family of wikis) from a single codebase, but with separate
configurations and thus you can separate out the access controls.
http://en.wikipedia.org/wiki/Wiki_farm



> ...
>
> > Like Dan said, wikis need maintenance, and a wiki that lets you automate
> > some of that helps.
>
> Another feature I like about PMWiki is that page content is stored in
> text files on the hard drive rather than in the database.  That means I
> can do many administrative tasks (eg global search and replace of a
> person's email address, finding all pages that have text matching a
> regular expression, etc) very easily, and backups get compressed down
> very small.
>

One directory in the source of MediaWiki is the 'maintenance' scripts
directory.  Lots of interesting goodies in there.
http://www.mediawiki.org/wiki/Manual:Maintenance_scripts  (In addition to
regular database backups,) I use
http://www.mediawiki.org/wiki/Manual:DumpBackup.php to create a text backup
of the current wiki contents every hour which serves as a text-based version
which can be grepped easily if the server itself is down.