Linux.com

Feature: Enterprise Applications

Putting MediaWiki to use in an organization

By on May 19, 2006 (8:00:00 AM)

Share    Print    Comments   

Imagine how useful it would be to have an online knowledge base that can easily be updated created by key people within your organization. That's the promise of a wiki -- a Web application that "allows users to easily add, remove, or otherwise edit all content, very quickly and easily," as Wikipedia, perhaps the best-known wiki, puts it. Why not bring the benefits of a wiki to your organization?

If you're sold on the concept, the first thing you need to do is to pick the software that you're going to use for your wiki. If you want hunt around to find out what's out there, a good place to start is Wikipedia's wiki software wiki. If you say, "I'll use whatever Wikipedia is using," that'll be MediaWiki.

MediaWiki installation is easy -- either follow the instructions on MediaWiki's site or read "The open source wiki behind Wikipedia." Install MediaWiki on a server that can be seen by everyone in your organization. You'll then be able to access it from a Web browser by typing in something like http://servername/wiki.

With a brand new wiki there's absolutely no security or control built into it. Anyone that can access the Web page will be able to add pages, comments, and discussions. We're going to stop that. First add a new user account -- you'll need to be able to log on once you've disabled anonymous access. Next, find the LocalSettings.php file in your wiki directory. Add the following lines:

$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgShowIPinHeader = false;

With that done, anyone on the network will be able to view the wiki, but only someone with an account will be able to create or edit pages.

You may also want to enhance the wiki pages by adding PHP functionality. To do this, add a function into the includes/Setup.php file:

function ParsePHPTag($Content)
{
 global $wgOut;
 $wgOut->enableClientCache(false);
 ob_start();
 eval($Content);
 $Result = ob_get_contents();
 ob_end_clean();
  return($Result);
}
$wgParser->setHook('php','ParsePHPTag');

Then, if you want to use PHP in any of your wiki pages, don't use the normal <?PHP ... ?> tags; instead use <PHP> ... </PHP>.

Now you can even access data in a MySQL database by adding code like this to a wiki page:

<PHP>

$db = mysql_connect("localhost", "userid", "userpassword");
mysql_select_db("cstellar",$db);

$result = mysql_query("SELECT COUNT(*) stars FROM chyg85",$db);

printf("Records: %s\n", mysql_result($result,0,"stars"));
</PHP>

In this example, all I'm doing is connecting to a database and counting the number of records in a table. Obviously you'd have to use your own database and user details.

MediaWiki is based on PHP, and so as well as being able to use any PHP functionality within a page, you can actually build your own extensions to MediaWiki. If you're interested in doing that, have a look at MediaWiki's documentation on extending wiki markup.

While you're setting parameters, look at your php.ini file. In php.ini, the line session.gc_maxlifetime sets the length of time (in seconds) that a PHP session is allowed to exist, like this:

session.gc_maxlifetime = 1440

This means that if you're editing the wiki then you must click on the "Save page" button at least once every 24 minutes or risk losing your work. You can increase the time to a value that will suit you better -- say to one hour, or 3600 seconds.

At this point you may be saying, "There's nothing here that I can't do with a text editor, an ordinary Web server, and giving group access to the Web files." True -- so let's see where the wiki comes into its own. Try editing the Main page, save the changes, and then click on the History tab. You'll see that MediaWiki tracks who made all changes and when. You can compare the differences between different versions. In one fell swoop you've got yourself a document management system as well as a potential in-house knowledge base.

"Aha!" I hear you say, "if this is just operating in a browser then how can I do spell check or word counts? What about formating?" If you use Firefox as your browser, you can add Firefox extensions to implement those functions. If you're using Firefox 1.5.x, install Spellbound dev and restart Firefox. When you then try editing one of your wiki pages, you'll find that misspelled words are underlined in red. Right-clicking in any editing areas (text boxes, for example) will allow you to display the spell check front end. Once there then it's just like spell checking in any other application.

It's just as easy to get a word count going, this time use roachfiend.com's Word Count. Again, don't forget to restart Firefox after installing the extension. However, the word count doesn't work within the text editing areas. to get around that problem, click MediaWiki's "Show Preview" button tp see your work displayed as a normal Web page. Now you can then select any area of the text, right-click on it, and you'll see that "Word Count" function is available. Click on it to see the number of words in a message box.

Finally you can install a WYSYWIG HTML editor called Xinha Here! Both the spell check and word count extensions also work in the Xinha window.

With MediaWiki set up, you're ready to create your knowledge base; I can't help you there, it's all up to you. MediaWiki and the Firefox extensions have enhanced the way that I do my day-to-day work, and I'm sure that they can revolutionize the flow of information and knowledge around your organization.

Share    Print    Comments   

Comments

on Putting MediaWiki to use in an organization

Note: Comments are owned by the poster. We are not responsible for their content.

Why? Because its not the right solution for all

Posted by: suso_banderas on May 20, 2006 02:21 AM

As someone who uses mediawiki for 4 different wikis (<a href="http://www.bloomingpedia.org/" title="bloomingpedia.org">Bloomingpedia</a bloomingpedia.org>, <a href="http://www.bloomingtonlinux.org/" title="bloomingtonlinux.org">BLUG Website</a bloomingtonlinux.org>, <a href="http://suso.org/" title="suso.org">suso.org's</a suso.org> internal documentation and <a href="http://www.cookmedical.com/" title="cookmedical.com">Cook Incorporated's</a cookmedical.com> internal documentation wiki) I can say from using it for Cook Inc. that MediaWiki is not really the right tool for corporate wikis. What I've found so far is that it doesn't look like a documentation website to some people and the wiki syntax isn't logical. For instance, using == Section == for the largest section and ==== Minor ==== For the smallest doesn't make much sense. As an example of what does work, <a href="http://wiki.splitbrain.org/wiki:dokuwiki" title="splitbrain.org">DocuWiki's</a splitbrain.org> reverse of using more equal signs for larger sections makes more sense. This is just one example there are many others.

Also, MediaWiki's user management system doesn't lend itself well to the requirements of a large organization where you need to have really good access control. Not that <a href="http://wiki.splitbrain.org/wiki:dokuwiki" title="splitbrain.org">DocuWiki </a splitbrain.org> doesn't have its own faults, but it is generally more targeted at running documentation wikis.

Don't get me wrong, I think MediaWiki is great for many types of wiki applications, but not for all. And I worry that some people will read your article and not bother to check if there is something that would fit them better. For Bloomingpedia it made a lot of sense because I wanted people visiting to experience the same feel that wikipedia has. But for something like the suso internal docs website, I don't care about that as much.

One future wiki that I'm going to setup is a family wiki for my family, detailing relationships between people, etc. I don't think there is any type of family wiki, but it would be neat if there was specialized wiki software that offered features specific to running a family wiki like building family trees from tags that you insert into the documents, sending reminders on birthdays, etc.

#

Re:Why? Because its not the right solution for all

Posted by: Anonymous Coward on May 22, 2006 03:51 AM
Regarding relationships, you want the Semantic MediaWiki extension.

#

Re:Why? Because its not the right solution for all

Posted by: Anonymous Coward on May 22, 2006 06:01 AM
I disagree with your characterization of the header syntax.

It's actually *more* logical than the inverse, because one can only have one top level- the highest level beyond which one can not ascend. This maps naturally on = FOO =; if one wants to split the article into more than one piece, then == FOO ==; if more nesting is desired, one can keep adding =s indefinitely. (More abstractly, the base case chosen for the inverse of MediaWiki syntax is poorly chosen since the changes in syntax don't mirror the changes in semantics.)

On the other hand, what if your ultimate top level header was ==== FOO ==== (or whatever DocuWiki sets it at)? What happens when you want to go down to a fourth level? Do you simply write = FOO =? Very well then: how does one then express going down to a fifth level? FOO? (and so on). Yeah right.

#

Re:Why? Because its not the right solution for all

Posted by: suso_banderas on May 22, 2006 08:44 PM
Ok, I can see your point, but I don't think many people think like that. Most people equate bigger with more. Think about it in terms of fonts. To get a larger font, you usually raise the number in the size attribute.

Your argument makes sense from a software designer's standpoint. But I don't think it makes sense from a user's point of view.

#

Re(1):Why? Because its not the right solution for all

Posted by: Anonymous [ip: 216.46.1.103] on September 10, 2007 07:30 PM
Users are idiots.

#

'Docuwiki' should read 'DokuWiki'

Posted by: Anonymous Coward on May 22, 2006 10:41 AM
DokuWiki is kind of like a skinny MediaWiki. Great for documentation and collaboration and includes many of the features of 'larger' wikis.

#

Other wikis

Posted by: Anonymous Coward on May 20, 2006 06:14 AM
I have set up a couple of twiki installations. Are there some clear advantages for using mediawiki, docuwiki or some other wiki. Any clear differences security wise?

Simplicity especially for the users and for setting up access control is preferred. Also up to date debian packages would be nice.

I'we been quite happy with twiki but setting it up is a bit of an hassle.

#

DokuWiki security

Posted by: Anonymous Coward on May 22, 2006 10:54 AM
The dokuwiki security configuration is pretty straightforward and allows control down to the page level. Admin accounts get access to 'point and click' administration when they sign in. You can also just edit the access control configuration files with a text editor if you want. Passwords are transmitted in encrypted form and you can change the type of encryption. So it seems to be pretty secure as far as a php wiki can be made secure.

#

mediawiki straight up

Posted by: davejenk1ns on May 20, 2006 07:46 AM
<a href="http://www.backcountry.com/" title="backcountry.com">We</a backcountry.com> use MediaWiki straight outta the box-- well, okay, we changed the logo to our Goat, and renamed the thing (as in, "go look it up on the Goat"). It's worked wonders. No more MSWord documents flying around, no more revision after revision, no more missing out on the innovation that could come from anywhere.

MediaWiki does have its limitations-- better integration with our sales reports and bugzilla would be great places to start, but we'll crack those soon enough.

Overall, I give it two thumbs up for an intranet. It took one afternoon to install, and 13 months later, we now have 7500 pages of various processes, vendor info, and specs there. Great!

#

db credentials in a wiki???

Posted by: Anonymous Coward on May 21, 2006 02:45 PM
IMHO, it's foolish to put database credentials in a wiki, where everyone could see them in the "view source" page...

#

Re:db credentials in a wiki???

Posted by: Anonymous Coward on May 22, 2006 03:36 AM
You could always setup a read only account for the database that only has permissions to view tables that need to be displayed in the wiki.

#

Re:db credentials in a wiki???

Posted by: Anonymous Coward on May 22, 2006 04:14 AM
Not really. If it's only read access that you need it for (and if you're displaying info on a Wiki, it probably will be), create a specific user in your SQL server that only has read access to the tables/schemas that you want.

#

Re:db credentials in a wiki???

Posted by: Anonymous Coward on May 22, 2006 09:08 AM
Other options:
- include_once( "/secure_path/db_conn.inc" ) ;
- allow a specific user to make insecure (password-less) read-only access from the web server maintaining the wiki only, and no other address
- remove the view source option from public accounts

#

Gah! Please, no!

Posted by: Anonymous Coward on May 22, 2006 04:17 AM
Please do not encourage people to allow arbitrary PHP code in a Wiki page! You are just asking for morons to do this on a publicly-accessible Wiki, and get themselves w00ted. This is possibly the stupidest security-related idea since<nobr> <wbr></nobr>... well<nobr> <wbr></nobr>... since PHP.

#

Semantic Extensions

Posted by: Anonymous Coward on May 22, 2006 06:09 AM
To put the knowledge really to work, one would want to use mediawiki's new semantic web extensions:

Semantic MediaWiki.

#

Wikis in enterprises

Posted by: Anonymous Coward on May 22, 2006 07:12 AM
You can find information and a survey (in German!) about Wikis in Enterprises here: <a href="http://wikipedistik.de/umfrage/" title="wikipedistik.de">http://wikipedistik.de/umfrage/</a wikipedistik.de>

Hopefully this information will be translated to english in the next 1-3 days.

#

Re:Wikis in enterprises

Posted by: Anonymous Coward on June 21, 2006 04:26 PM
Ah well, it's translated meanwhile: <a href="http://wikipedistik.de/survey/" title="wikipedistik.de">http://wikipedistik.de/survey/</a wikipedistik.de>

#

Agree

Posted by: jlchannel on May 22, 2006 10:00 AM
I'm totally agree. We have implement mediawiki here.

#

Full-Text-Search

Posted by: Anonymous Coward on May 22, 2006 03:23 PM
MediaWiki is only useful with a functioning Full-Text-Search, which is not implemented by default. IMHO, other search engines are either hard to implement and maintain (therefore boost costs), or are equally ineffective. Does anyone have a recommendation, here?

#

Re:Full-Text-Search

Posted by: Anonymous Coward on May 24, 2006 04:15 AM
Yeah...I had someone set one up for me last week and I can't search. I search for the exact words that are in the article and I get nothing. I started a message on some forum, we'll see if anyone answers.

<a href="http://www.mwusers.com/forums/showthread.php?t=2018" title="mwusers.com">http://www.mwusers.com/forums/showthread.php?t=20<nobr>1<wbr></nobr> 8</a mwusers.com>

#

Wiki-markup is the biggest barrier for adoption

Posted by: Anonymous Coward on May 23, 2006 12:05 AM
To have wide-spread contribution, coded wiki-syntax is a huge barrier. It's fine for coders or for companies who are prepared to do some training, but it is not intuitive or easy for the general population to pick-up.

MoinMoin now has a WYSIWYG editor included in the latest version, but it is missing quite a few other advanced features found in MediaWiki. Still, I think it is much more approachable for new, non-technical users.

A great site for comparing wiki engines used to be <a href="http://www.wikimatrix.org/" title="wikimatrix.org">http://www.wikimatrix.org/</a wikimatrix.org> but it appears to be down right now. The number of alternatives is overwhelming. I tried to configure Twiki, but CGI is just to particular of a language for me. Something PHP-based, such as MediaWiki, was much easier to administer.

When MediaWiki includes some type of WYSIWYG editor (such as WIKIWYG - <a href="http://www.wikiwyg.net/" title="wikiwyg.net">http://www.wikiwyg.net/</a wikiwyg.net>) it will be ready for larger-scale deployment to less-technical user bases. Until then, I don't think there is an ideal solution.

#

Re:Wiki-markup is the biggest barrier for adoption

Posted by: Anonymous Coward on May 26, 2006 06:27 PM
Well, I'm sure WIKIWYG can be "hacked" into MediaWiki. Looking at it, this seems possible especially as the WIKIWYG site says that it can be used with MediaWiki.

#

Problems with wikipedia

Posted by: Anonymous Coward on May 23, 2006 02:21 AM
The biggest problem we have run into with using wiki is that users put links where nobody can find them.
We have topics subtopics and people refuse to use them. So you have information on some thing like Linux App Configuration, under Jordan's entry -> Computers -> Linux -> Application -> Configuration. Where we already have a base of Linux -> Application. Trying to go back through and clean up this mess is quite time consuming. If somebody know s of an easy way I'd really appreciate the input.

#

forget subpages

Posted by: Anonymous Coward on May 23, 2006 05:38 AM
We also struggle with organizing pages in our intranet. I'm starting to think that using mediawiki effectivey requires a paradigm shift in the enterprise away from a heirarchical organization of docs.

Forget browsing by subject and rely more heavily on the search. Thank goodness the search works pretty well.

#

MediaWiki works perfect for us

Posted by: Kshitij Gupta on June 08, 2006 03:29 PM
We (at <a href="http://www.sitewards.com/" title="sitewards.com">Sitewards</a sitewards.com>) have had a tremendous experience with MediaWiki. We use it for all kinds of internal information management, including customer details, discussions, calls, knowledge tid-bits and so on. It's interface takes even the most tech-phobic just a few tries to get used to; and we have simple rules governing page-names, categories and templates. Of course the easiest changes (colours, formats, logo, user and rights management etc.) are things we have already incorporated.

We even introduce many of our customers to the wonders of Wiki's simplicity. We have a <a href="http://demowiki.sitewards.com/" title="sitewards.com">Demowiki</a sitewards.com> that we always keep for customers (and all interested) to test and play around with.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya