Continuing my search for a decent KB, I’m concluding my evaluation of MediaWiki. This name might be familiar to you because it is the wiki engine running Wikipedia and sister projects. I first began looking into MediaWiki despite my giving up on wikis as a whole because I had decided that the overall format and objective of wikis didn’t line up with how I perceived my knowledge base to exist.
MediaWiki changed my mind mostly with two factors: the front page could be customized to attract people in instead of just funneling them to a search box. Secondly, the size and scale of the wikipedia project convinced me this would be a worth-while project.
Setting up MediaWiki was pretty painless. You need a SQL database and a http file server (Apache), so I was able to get by just fine with XAMPP for testing purposes. MediaWiki runs you through a configuration page to get account information for your database and naming all set up. It creates all the tables necessary after that.
After setting up, I did run into one error. It was listed in their FAQs and I solved the problem with a quick edit with Notepad++ of LocalSettings.php in the mediawiki folder.
The error:
Warning: domdocument::domdocument() expects at least 1 parameter, 0 given in C:xampphtdocswincludesPreprocessor_DOM.php on line 566
Fatal error: Call to undefined method domdocument::loadXML() in C:xampphtdocswincludesPreprocessor_DOM.php on line 568
The fix is to add this line in LocalSettings.php:
$wgParserConf['preprocessorClass'] = 'Preprocessor_Hash'; Unfortunately, while looking into the manual of WikiMedia, they recommended that I use other software to accomplish my goals. I was once again convinced that a wiki is going to have to be pretty well conceived for my plans for it to work or there will be many holes to plug to be confident in the security setup. It seems the ACLs is going to make or break a KB for me to be sold on it. The interface follows second. I’ve realized through my past experiences with trying to get more documentation to our processes that the system has to be easily accessible or else it is seen as too much of a hassle and the documentation never gets written.
Here are some interesting pages to read regarding user access and user access management in MediaWiki:
From http://www.mediawiki.org/wiki/Manual:Config_script:
User Rights: http://www.mediawiki.org/wiki/Manual:User_rights
-Control and create groups
-Control access (read, edit) permissions of groups
User Rights Management: http://www.mediawiki.org/wiki/Manual:User_rights_management
-Groups permissions to perform user management tasks
Preventing Access: http://www.mediawiki.org/wiki/Manual:Preventing_access
-Restricting edit & page creation rights
To have a page act normally for some users but be invisible to others, as is possible for instance in most forum software, is a very different matter. MediaWiki is designed for two basic access modes:
1. Everyone can view every single page on the wiki (with the possible exception of a few special pages). This is the mode used by Wikipedia and its sister projects.
2. Anonymous users can only view the Main Page and login page, and cannot edit any page. This is basically the same as the above, in terms of technical implementation (just an extra check for every page view), which is why it exists. This is the mode of operation used by certain private wikis such as those used by various Wikimedia committees.
Unfortunately this does not line up with how I want to operate my knowledge base. I am looking for:
- Select individuals can view every single page on the wiki. These people would be the master editors that could read, write, and update articles.
- Anonymous users can view most pages of the wiki, those that have been tagged or grouped to allow them access. These would be the typical users that are trying to search and solve their own problems.
Essentially this translates to:
- Library IT users can view all pages and also read and edit them. There may also be sub-groups of this so that IT Workstation and Network Support can see all articles but IT Help Desk has some it can not see.
- Library employees and users can search the kb to find information regarding any problems they might encounter to learn about workarounds, known problems, or assistance. There may also be a sub-group where only library employees can access regarding internal workings so as to not provide “security” leaks of internal systems to anonymous visitors.
I am definitely open to suggestions regarding where I should look next for a system that would provide an easily configurable ACL (access control list) to restrict general users from getting access to IT-only articles. Post any recommendations in the comments please.
Check out MediaWiki if it sounds right for you.