[pmwiki-users] Selecting a Wiki engine...

Mark Trumpold mark at ruthtrumpold.id.au
Mon Oct 2 13:51:00 CDT 2006


Good to know people would be willing and able to take on the task ... So far
I love it and hope it hangs around ....


On 2/10/06 7:57 PM, "Crisses" <crisses at kinhost.org> wrote:

> 
> On Oct 2, 2006, at 12:50 PM, Oliver Betz wrote:
> 
>> Hi All,
>> 
>> running several (currently broken) PhpWiki based wikis, I'm strongly
>> considering to switch to a better maintained Wiki engine. PmWiki is
>> on the top, I will also check DokuWiki and maybe Mediawiki again.
>> 
>> Since I'm no PHP programmer (I'm doing embedded stuff in "plain C"),
> 
> You might be surprised how similar PHP is to c/c++.  There are
> distinct differences, but reading the code should be relatively
> simple (compared to, say, perl ;) ).
> 
>> For example, I read that Mediawiki has a "suboptimal" code with many
>> globals, rather hard to maintain. Well, I have to believe it. Obvious
>> for me is that Mediawiki has no option to purge the page history,
>> that's a severe disadvantage for me (limited storage in hosted
>> environment, maybe performance issues).
> 
> PmWiki allows you to purge history -- by setting (the next page edit
> after X days), or by hand.
> 
>> Availability: although I see that Patrick R. Michaud and the very
>> active community do a great job improving PmWiki, I would like to
>> know whether there are more (potential) "core" developers, IOW
>> whether there is a good change that PmWiki will be maintained even if
>> PM stopped development some day.
> 
> Yep.
> 
> I might tear it apart and make it more object oriented ;)  But then
> that would only be the "if Patrick got hit by a bus" option.
> 
> Others probably know more of the PmWiki core than me, but I'd be
> willing to work on a team on the core.
> 
>> Security: is PHP really that bad (e.g. compared Perl) in terms of
>> security? The PmWiki code didn't seem to have many security issues in
>> the past. Is it written more defensive than other applications?
> 
> 1) You can't have SQL injection problems when there's no SQL :)
> 2) we have our share of page vandals
> 3) we have found vulnerabilities and squished them, but none (TMK)
> have been wild exploits
> 
>> So many questions - maybe someone can point out whether or why PmWiki
>> is the best choice...
> 
> whether is a judgement call.  This was my first wiki, my only wiki.
> I've been here at least since about 2002, maybe earlier.  I can't
> remember.  I've tried CMS systems, blogging packages, learning
> management software, and worst of all e-commerce systems, and I
> always want to come back home to PmWiki. :P
> 
> Why:
> 
> user/author-centric -- we go out of our way on the coding side to
> make things easier for the people writing
> Solid extensible core
> Modules don't break the core
> Responsive community
> Community small enough to remain consolidated -- lots of people here
> have been here as long or longer than I have
> One core developer means all us other code junkies can get busy
> writing extensions ;)
> the core developer is responsive to anyone with a demonstrable need
> core extensions only happen if it's useful to many environments
> (there will be a shopping cart module -- but NOT in the core!)
> the core footprint is still under 2MB -- and that's a rule of thumb
> that has been maintained throughout
> strong internationalization support
> world-wide community support 24/7/365 ;)
> We don't say "you can't do that" we provide hacks and snippets or ask
> Patrick to add a hook to make it possible ;)
> 
> I'm sure I left some things out ;)
> 
> Crisses
> 
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users







More information about the pmwiki-users mailing list