Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] wiki suggestion?

On Fri, Aug 1, 2014 at 2:00 AM, David Kramer <david at> wrote:

> On 07/31/2014 10:50 PM, John Abreau wrote:
> > Wikipedia is based on mediawiki, which I haven't used myself, but I
> > understand it's generally a good choice.
> >
> > I've used foswiki in the past, back before it forked off from twiki, and
> if
> > I were setting up a new wiki, I'd go with foswiki.
> I'm a very heavy user and strong believer in Foswiki.  It's extremely
> powerful and has hundreds of great plugins (including integrating with
> other systems).  I do all sorts of crazy things with it.  The Dev team
> is very active and very accessible on IRC.
> My original attraction to Foswiki was the fact that it has very powerful
> user/group/permissions system.  Most wikis are still on the "information
> wants to be free" train which makes them wholly unusable in the real
> world where script kiddies destroy your site because they can.  I used
> MediaWIki for one project and it is not designed like that.  It's very
> hard to lock down, and script kiddies put porn links all over the site.

I think some clarification and correction is needed here with respect to
the capabilities of MediaWiki.  MediaWiki software is very easy to lock
down.  See

I have zero script kiddies vandalizing my public (anonymous read) wiki
(because anonymous write is not allowed; and you can't get an account
unless I give you one.)

I create wikis inside corporate firewalls where authentication is handled
by Google Apps and content is not accessible unless you are logged in.
 Certain content is white-listed (like the main page, and a page on login
help) so that even if you have physical access to the wiki, you must
authenticate in order to view pages.  That's pretty "locked down".  Once
authenticated, anyone in the company can edit any page on the wiki.  That's
what wikis are designed to do.

One thing that MediaWiki is not designed to do is to secure individual
pieces of content from people who really want to get it (AND who also
already have access to the wiki).  For example, an uploaded pdf file of a
sensitive nature (merger/buyout plan) could potentially be exposed through
the webserver if the attacker knows the name of the file.  Also trying to
give only the Accounting group access to the accounting-related pages in a
company-wide wiki is not what MediaWiki is designed to do.  In that
scenario, you would segregate by namespace, or separate wiki - or even use
a real Content Management System for content while the wiki was for
knowledge management (i.e. process, procedures, events, forms, ad-hoc

The built-in category system of MediaWiki is the natural way to organize
content.  This is sufficient to organize content by department in a
company: tag each article with "Accounting", "Engineering", "HR", "Sales",
"Marketing", etc.  But, this may just seem cluttered to people who don't
want a corporate-wide information repository.  Sometimes groups want their
own "area" in the wiki, or their own wiki.  This is something you can
totally do with MediaWiki.  You can manage separate "namespaces" in
MediaWiki if you want to segregate content by teams; and you can also
create a "wikifarm" which is multiple wikis running off the same software

> Foswiki also has the ability to attach forms and metadata to wiki pages
> and do things based on it.  That lets you create database-like
> applications.  For instance, for Agile New England (which I'm also on
> the Board of) we use it to track our monthly meeting information.  The
> Speaker team will click a button to create a new Event page, and fill in
> the speaker, topic, bio, attach pictures, etc.  When they save it it
> automatically ends up on the list of upcoming meetings.  Then my IS
> group will get notified and we will create the content on the website
> from that.  Registration and other teams also use it.  After the even is
> over, we change the "Status" field on the page to "Past Event" and then
> it automatically gets removed from the upcoming meetings list and put on
> the past meetings list.

That's what the Semantic MediaWiki extension does.

Greg Rundlett <>

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /