[pmwiki-users] Wiki Comparisons

Ben Wilson dausha at gmail.com
Mon May 22 12:35:27 CDT 2006


I'll bite.

On 5/22/06, Bill Jones <tetragondzein at gmail.com> wrote:
> Hi
>
> I have spent the better part of a year looking at various open source
> software to perform some specific tasks -
>
> 1) Basic Site CMS tasks (which will also integrate into a static site.)

Not sure about what you mean by integrating into a static site. I will
infer that you mean to say that a static site exists and that PmWiki
would have to co-exist. I think this is quite doable. Using the
InterMap feature, you could create an internal map "Static:" that
would resolve to the appropriate URL. Then, if you wanted to refer to
a static about.html page, you could (probably) just say
[[Static:about.html|About Us]]. [1]

As far as basic CMS, PmWiki provides that, with more specific CMS
behavior provided via recipes (plugins).[2] I'm rather fond of
AuthUserCMSLike,[3] but the alternative is at least as good.[3] They
both essentially do the same thing, although the alternative may be
better documented.

> 2) Basic ACL with per-user, per-group, per-directory, per-page, and
> per namespace security control.

Not sure about "namespace" as I am unfamiliar with the term. PmWiki
provides three varying levels of security:
  1. "Come in and rest a spell--virtually no security except for a few
anti-spam measures.
  2. "We're all Friends"--Control via just a password. Good for a few
trusted people as
      they all share the same password for either edit or admin control.
      PmWiki.org follows this approach for some pages (which makes it
more like 1.)
  3. "What are you doing here?"--Control via username/password. This
method is a bit
      weak on allowing new users to generate an account, but you'll
get the most CMS
      bang for your dollar here.

In terms of "per-group, per-directory, etc.," I think you'll find
PmWiki to your liking. You can password control a page, group, or the
entire site. By password control, you can either assign a single
password to fill that role, or you can assign by specific username or
by a user group. Your level of control is basically read, write,
upload, download, and a few other admin options.

> 3) A flat file, non-Database, text-centric portable backend.

PmWiki has perhaps the best flat file implimentation. There has been
discussion just this past week about how to pull the page content out
of a file on the backend without resorting to PmWiki. In *Nix it is as
easy as "grep 'text=' Some.PageName" The query I refer to was how to
convert a large (10K) page MediaWiki to PmWiki in shotgun fashion.

I hate database backends. They tend to be constricting. Databases hang
for no good reason, leaving a curious error message. I once Googled to
find out what a specific error message was, and I got back thousands
of other pages that displayed the same error.

The biggest error I get when deploying a new PmWiki site is that it
can't find a Skin, which is because I neglected to provide the symlink
to the public directory.

> Anything above these 3 is a bonus.

1. You get a great Community. We're pretty active, rather friendly,
and like to help.

2. Nearly a google-plex of recipes. Okay, only a few score, but they
fit almost any need. If they don't . . .

3. A solid code base upon which to develop your own plugins (Recipes).

4. Reliable upgrade process. Pm ensures that upgraded code only writes
to certain directories. It does _nothing_ to local directories. These
local directories include the wiki data files, local configuration,
user-created public directories (such as custom skins), and the
cookbook (locally installed plugins) directory. By treating these as
sacred, you can upgrade without worrying about losing your local
configuration or data. This is not to say that upgrades won't always
muck up your site. Code breaks and upgrades drop legacy support in
favor of better approaches.

5. Relative Stability. I'll get into this below. However, changes to
the PmWiki code base are gradual, rational, and tend to be backward
compatible. The v1 to v2 break was a major shift and caused some
heartburn. Pm ensured there was an appropriate programatic antiacid.

6. Decoupling. Pm is pretty good about keeping the form (XHTML, style)
away from function. Exceptions are the bare-bone necessary HTML to
render a site without any decent skin, or those few skinless pages.
However, most of these form defaults are configured using variables
that tend to submit themselves to the local configuration.

7. Dynamic Flexibility. The ability to create pagelists--and to
configure the output of a pagelist is simply amazing. Pm really outdid
himself with this. The Community kept asking for ways to do pagelists
differently. He responded by making it a very customizeable tool. I
think that one feature has moved PmWiki into the lead. I use pagelists
to track page changes, display journal entries like blogs. I even have
a release log for one project where the release notes are dynamically
generated from a PmWik-based issue tracker and from journal entries
made between releases.

8. Simple Install. Seriously, all you have to do is untar the code,
follow the simple instructions the first time you try to access the
code (which is a temporary chmod action) and set the Site group's
password in the local config file, and you are operational. It takes
me seconds to start a new site:

# wget -c http://www.pmwiki.org/pub/pmwiki/pmwiki-latest.tgz
# tar xvfz pmwiki-latest.tgz
# mv pmwiki-2* wiki
# chmod 2777 wiki
# {View page}, could even be done by "links
http:www/example.org/wiki/pmwiki.org"
# chmod 755 wiki
# cd wiki
# mkdir local
# cp sample-config.php local/config.php
# vi local/config.php

> During this past year I have
> "seriously" (meaning I've installed the software and deployed 'live
> data') using these systems:
>
> Moodle, Drupal, MediaWiki, and Dokuwiki.

I have experienced three over the past three years.

   1. Moodle: Had a good conversation with the owner of this code base when he
       was preparing to defend his thesis, which was based upon
Moodle. Good tool,
       but intended for a specific (education) purpose.
   2. Drupal: _The_ reason I fled to PmWiki. Changes between minor
revisions could
       cause entire plugins to fail miserably and unpredicably. It
overcoupled the form
       and function. This required major surgery to bring a 2.4 recipe to 2.5,
       and sometimes from 2.4 to 2.4.1. I helped deploy an entire site
and sold the use
       of open source CMS via Drupal to another client. Then Drupal
upgraded. The first
       site failed on upgrade--which froze me in time. The second
client looked at a demo
       and when it became known of the problems with upgrading chose
to pay for a
       CMS tool which is less powerful than PmWiki. But, that was
before I came to
       PmWiki.
   3. MediaWiki: Don't bite the hype. It is a well-known tool, but
relies on a database.
       Heck, all three of these examples do. MediaWiki is being
discussed on Slashdot,
       and the opinion is that it is good for the company developing
MediaWiki, and it
       may be good for the Wikipedia, but it is less suited for normal
corporate use.
       Heck, Twiki is better for corporate use than MediaWiki, IMO.
But, PmWiki has
       a few tricks up its sleeve that pulls it ahead of Twiki.

> Each has not met with my satisfaction for various reasons.  I am
> currently using DokuWiki, which I like very much, but I feel I may be
> missing out on other potential software systems and/or better
> solutions.

No experience with DokuWiki, although it sounds like the Dark Side of
the Force (Count Doku). Since I tend to find evil Star Wars references
for PmWiki, that may be a good thing.

> My question(s) are:
> Are CMS/Wiki-like projects simply "not where I would like yet"?
>
> What little I know about PMWiki implies that it may be something to
> evaluate; however I am worried "do I really want to change wiki
> software and spend another 2-3 months switching and learning?"  Anyone
> have experience using Dokuwiki and migrating to PMWiki?

To be honest, PmWiki has a bit of a learning curve. You could be up
and working in no time. It is simple to install and run. That is where
you will be fooled. The basic things are easy, but as you play with
PmWiki more you will find the neat tricks you can do with PmWiki that
aren't possible with other wikis.

You'll want to exercise more control in an area (e.g. limiting direct
downloads to trusted individuals) and explore the elegance of the
upload process. The code will suck you in and have you up until 5a
playing around with it. Don't believe me? Ask my wife when I went to
bed this morning.

> Any thoughts and comments about the above or anything you may feel I
> have over looked or should consider would be appreciated.

I'm a zealot. I'm a software engineer who likes predictability and
elegance. For my track record, I took a hobby project and converted it
into a major system managing terabytes of commercial satellite imagery
for an imagery clearinghouse. That system was meant to be a temporary
fix, but its successor project had to throw in the towel because when
finished it was less efficient. That's not all my doing, but I set
some high standards that my programmers abided by. I'm not on the
project now (I am an idiot and went to law school), but it has
survived me by two years thus far. My point is I know a good thing
when I see it.

PmWiki is easy to install. So, you can easily set the bugger up along
side your DokuWiki. Put PmWiki to its paces. See if you can
mass-import the DokuWiki site. I think with a little experimentation
you'll see how the two compare.

There, my long email message of the day.

[1]: For the sake of argument, Static: would resolve to http://www.example.org
[2]: http://pmwiki.org/wiki/Cookbook/Cookbook#CMS
[3]: http://pmwiki.org/wiki/Cookbook/AuthUserCMSLike
[4]: http://pmwiki.org/wiki/Cookbook/DynamicPageActions
-- 
Ben Wilson
" Mundus vult decipi, ergo decipiatur"




More information about the pmwiki-users mailing list