Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
The OP didn't clarify what access controls were needed. Broadly speaking, MediaWiki is not designed to offer content-based access controls the way that a content management system is designed to do. It /can/ easily accomodate various types of authentication (and multi-family wikis) for collaborative authoring in a controlled environment. On Sun, Jan 3, 2010 at 6:20 PM, Tom Metro <tmetro-blu-5a1Jt6qxUNc at public.gmane.org> wrote: > Stephen Adler wrote: >> Any of you guys have a favourite wiki engine you use? > > I've always found the markup syntax inconsistent in MediaWiki, MediaWiki markup is the de-facto standard. Efforts on standardization of wiki markups like Creole and/or converters such as the PEAR text_wiki classes generally include MW syntax due to it's presence. Creole was specified by comparing major wiki engines and deciding on the most common choice for a particular wikitext element. If no commonality was found, the wikitext of the dominant wiki engine MediaWiki usually was chosen. related: * http://pear.php.net/package/Text_Wiki * http://www.wikicreole.org/wiki/Engines * http://www.mediawiki.org/wiki/Extension:XML_Bridge * http://www.mediawiki.org/wiki/Alternative_parsers * http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration#HConfiguringWikiSyntaxesanddefaultSyntax * http://dirkriehle.com/2008/07/19/a-grammar-for-standardized-wiki-markup/ > and the > functionality to be limited. MediaWiki software is full of functionality, and extensions. The difficulty in creating any standard wiki markup is due to the richness of the software, syntax and extended syntax. A lot of people want a WYSIWYG editor for wikis, however you can't (easily) do in a graphical editor what you can do (easily and quickly) in wiki markup. The template system is one example. {{This is a template macro|arg1| arg2}} What I'm saying is that MW is high on the functionality scale. This isn't to say that mediawiki can do anything and everything -- it can't. It is narrowly focused in it's purpose (collaborative authoring with ad-hoc structure). Using mediawiki for documentation and knowledge-sharing is well-established. related: http://www.mediawiki.org/wiki/Extension:Contents > People seem to install it almost by > default, which is unfortunate. If you need a collaborative authoring environment, then it's very fortunate that you might install MediaWiki :-) On the other hand, if you need "a wiki" because somebody wants an easy-to-edit website where most pages will have an individual author with lots of access control and separation, groups, project pages, levels of access etc. then what they asked for was a wiki, but what they need is a CMS. > > Wikispaces is great for situations where outsourcing your wiki to a > hosting provider is appropriate. Agreed > > But ultimately I'll add another vote for Twiki. I haven't set one up in > a few years, but you can make it do just about anything if you're > willing to put the time in. And that doesn't necessarily mean modifying > the core Perl code. It's extensively configurable and programmable from > the web UI. Plus there's a big library of plugins. You don't want to modify any core code in project unless you're actively trying to commit that code upstream. > > I do, however, read that there has been con controversy around the > project, and a fork spun off, http://foswiki.org/. A few months back the > people behind the fork obtained a backup of the twiki.org user records, > sent out a mass mailing promoting the fork, followed a few days later > with an email from the Twiki founder refuting the claims in the prior > email. Whatever...but the point is you'll probably want to assess both > projects and see which is on the track you want to follow. > Forks happen, and sometimes it's because you can't get your code committed upstream. But, it's more often a political divide and one that ultimately weakens/dilutes the software/community for the user. If I were starting a project and selecting software to use in that initiative, I'd probably steer clear of software that is forking unless I understood the situation fairly well. Greg Rundlett nbpt 978-225-8302 m. 978-764-4424 -skype/aim/irc/twitter freephile http://profiles.aim.com/freephile
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |