Running a corporate wiki is much different than running a public wiki. People inside a corporate environment expect certain things that (most) public wikis simply don’t have to worry about. These things include single sign on/integrated authentication, WYSIWYG editing, search that finds more than just wiki pages, formalized input, document versioning (draft, stable, published, etc.), document importing, and document exporting.

Thankfully, there are a number of MediaWiki extensions that can provide these types of functionality.

Must have extensions

Integrated authentication

Single sign on, or some form of integrated authentication is a must have in any corporate environment. People hate remembeing a bunch of passwords, and hate using applications that make them remember another one. IT departments hate changing passwords, and will hate any application where they will have to support another password database.

There are a number of options for this, ranging from complex, to easy. I’ll start with the easy ones and go to the complex ones:

1. NetworkAuth
   • If you don’t mind anonymous editing, but want to ensure only computers from your network segment are editing the wiki, this plugin will do that.
2. HttpAuth
   • This lets your web server do the authentication; this is really easy if you are already using mod_auth_pam, mod_authz_ldap, mod_auth_kerb, etc.
3. Plexel
   • Plexel is easy Active Directory (AD) authentication. This plugin will do AD authentication with Kerberos support, and group synching with relatively little configuration; however, it isn’t free (as in beer or as in freedom), and does not run on Windows platforms. It also only works with AD.
4. LDAP Authentication
   • Notice that I am the author of this plugin, and may show some bias towards it; however, this plugin is extremely flexible and is the most feature-complete of any of the plugins I’ll mention. The LDAP plugin supports password authentication with multiple domains, generic web server authentication (for things like Kerberos, PKI/Smartcard/CAC authentication), nested group login restrictions, nested group synchronization, preference synchronization, ldap query filtering (for login restrictions), and way more. I listed the Plexel plugin before this one because flexibility and features come with a price: complexity. This plugin can be extremely difficult to configure if you are doing something really complex; however, if you are doing basic password authentication to a single domain, this plugin is fairly easy to configure. This plugin is my recommendation if you have an LDAP and/or AD domain, and do not have some form of web Single Sign On (like OpenSSO or Crowd Authentication).
5. Shibboleth Authentication (or ShibbolethPlus Authentication)
   • These plugins are recommended if you have a SAML SSO enviroment. I haven’t been able to test these yet, but I’m assuming they will work with any compliant SAML provider
6. Crowd Authentication
   • This plugin is recommended if you are using Atlassian Crowd.

Document versioning

Wikis are great as documentation systems. Unfortunately, some documentation is meant to be formalized, reviewed, published, and only changed after going through this process. Wikis are generally not good for this type of process. Thankfully, the German Wikipedia brought us an extension that is perfect for this type of process. Flagged Revisions (FlaggedRevs) “… allows for Editor and Reviewer users to rate revisions of articles and set those revisions as the default revision to show upon normal page view. Readers can also give feedback. These revisions will remain the same even if included templates are changed or images are overwritten. This allows for MediaWiki to act more as a Content Management System (CMS).” With this extension, you can build a formalized process for publishing articles.

Document importing

Importing PDFs, Microsoft Office Documents, and Open Office documents is needed for proper growth of a corporate wiki. Sure, you can upload these documents; however, if they need to be edited frequently, and by multiple people, uploaded documents become cumbersome quickly. Here are a couple of ways to import these documents:

1. Word2MediaWikiPlus
   • This isn’t an extension, per se, but is a set of macros for Microsoft Word that can export your Word documents as wikitext. It will also export all of the images and bring up upload windows to upload any images used. This may also work for PDFs if you have the Adobe Acrobat PDF extension for Word.
2. Open Office
   • Open Office can export documents as wikitext natively. I don’t find the wikitext to be as elegant as the wikitext exported from Word2MediaWikiPlus, but it gets the job done. Open Office (3+) also has an experimental PDF import extension, which may allow PDFs to be exported as wikitext.

Document exporting

There are a number of PDF exporters for MediaWiki; nearly all of them suck.

The Collections extension is one that is looking extremely promising (especially since it has the support of the Wikimedia Foundation). Not all formatting exports properly, or at all, and most parser function and tag extensions aren’t supported, but simple to moderately complex documents will export beautifully in multiple formats (PDF, ODF, Docbook XML, and XHTML). Best of all, you can create collections of articles and export all of them as a single document that has bookmarks for article titles and headings!

This extension is unfortunately difficult to install in a corporate environment (especially if you are on a disconnected network). I may make a future how-to for doing this.

Promising extensions

WYSIWYG editing

Although I much prefer wikitext to WYSIWYG editors for everything except tables, some users will simply refuse to learn wikitext, and therefore, will not use the wiki unless there is a visual editor. The FCKeditor extension is an extremely promising WYSIWYG for MediaWiki. Most WYSIWYG editors, to date, have thrown wikitext out of the window, and don’t work with templates, extensions, and various other markup. The FCKeditor extension supports most wikitext visually, and for the things that are difficult or impossible to do visually, it allows wikitext through butons in the visual editor. Best of all, this extension lets power users switch between visual and wikitext modes.

This extension is definitely usable now; however, since the Wikimedia Usability Initiative has WYSIWYG editing on its radar, it is wise to keep up to date on what Wikimedia is going to use on their wikis.

Enhanced search

The default (MySQL) search that comes with MediaWiki isn’t terrible, and the Lucene plugin is good; however, corporate wikis usually allow uploads that public wikis don’t allow, and they need these uploaded documents to be searchable. Recently, an extension was released that can index PDFs, DOCs, PPTs, etc.. The EzMwLucene extension will be a must have extension when it is ready for public use. Right now it is fairly difficult to install, and has a few bugs. Keep an eye on this one though!

Formalized input

Infoboxes, like those used on Wikipedia, are good for formalized input, and you may already be using these. So, isn’t this a closed subject? Well, infoboxes scare users even more than regular wikitext, and make pages hard to edit for novice users. Also, although you are formalizing your input, you aren’t getting the most benefit possible from having it formalized. Semantic MediaWiki (SMW) and Semantic Forms (SF) are powerful extensions that let you define properties for data, and then make real forms for inputting the data.

SMW and SF are complex extensions, but when you get used to them, you won’t know how you ever lived without them. After getting used to SMW, you should also check out some extensions for it, especially Semantic Result Formats, Semantic Google Maps, MetaVidWiki, and Semantic Tasks.

Update (05/16/2009): Fixed mispelled title and url, and removed info about kerberos not working through reverse proxies.

Related posts:

1. New OpenSSO authentication plugin for MediaWiki