MediaWiki in bedrijf

Inhoud

(Media)Wiki in bedrijf

Introductie

Trends volgen elkaar snel op, zeker in de informatie- en communicatietechnologie. De ICT-ontwikkelingen hebben uiteraard grote invloed op de wijze waarop bedrijven- en medewerkers omgaan met hun digitale werkomgeving. Waar het ooit begon met het inrichten van eenvoudige websites als bedrijfsfolder, werd dat al snel gevolgd door intra/extranet-omgevingen. In zowat ieder bedrijf lijkt het nu weer bijna verplicht om alle content van alle bedrijfsonderdelen onder te brengen in een vooral zo zwaar mogelijk content management systeem. Maar helemaal dé hype zijn portals. Met name de bedrijfsportal, waar niet alleen het net gekochte CMS systeem, maar ook zoveel mogelijk andere bedrijfssystemen aan gekoppeld moet worden. Dit alles met het idee dat de gebruiker zo profiteert van een uniforme interface, met één centrale toegang tot alle informatie en alleen nog functionele verschillen tussen verschillende bedrijfstoepassingen. Ook is er een zekere keuzevrijheid voor de individuele gebruiker met betrekking tot de configuratie en layout van de persoonlijke portal-pagina. Daarbij faciliteert de bedrijfs-portal vaak ook mogelijkheden in collectief samenwerken door middel van gezamenlijke gebruik van Office-toepassingen en virtuele projectruimtes. Dat laatste is hard nodig, want wie bijvoorbeeld wel eens betrokken is geweest bij projecten weet dat er ontzettend veel tijd verspild wordt aan het heen en weer sturen van documenten, spreadsheets en andere bestanden. Om een zinnige bijdrage te kunnen leveren is het uiteraard van groot belang dat ieder projectlid telkens over de meest actuele versies van alle documentatie kan beschikken, maar in de praktijk blijkt dat een bijna onmogelijke opgave. Documenten worden soms geprint, soms gemaild, soms op een intranet of in een virtuele projectruimte gezet. Projectleden bewerken en distribueren per abuis oude documenten en doen niet of nauwelijks aan versiebeheer. Kortom, zelfs met toegang tot moderne communicatiemiddelen blijft er nog steeds volop gelegenheid voor miscommunicatie.

De bedrijfsportal lijkt in dat kader dus zeker een goede ontwikkeling en voor de gemiddelde kantoorwerker zal een CMS- of portal-implementatie ook in communicatieve mogelijkheden wel een sprong voorwaarts betekenen. De nadruk ligt bij een portal echter wel (logischerwijs) op harmonisatie van applicaties, processen en bedrijfsonderdelen. De gebundelde portal-omgeving is dan ook een compromis tussen diverse applicaties met ieder weer hun specifieke eigenschappen en uiteenlopende doeleinden. Niet erg voor de gemiddelde gebruiker, die merkt waarschijnlijk niet eens dat via de portal alleen de meestgebruikte onderdelen van een applicatie nog beschikbaar zijn.

Voor power-users ligt dat net even iets anders. In het maatkostuum van de portal missen ze al snel de wat specifiekere en meer geavanceerde functionaliteiten van de individuele applicaties. Zeker als het gaat om projectmatig werken, waarbij veel afhangt van goede onderlinge samenwerking en communicatie, voelt een deskundige IT-er zich in zo'n beperkende, vastomlijnde omgeving meestal niet echt thuis. Waar de power-user vooral behoefte aan heeft is de vrijheid om zelf de afwegingen en keuzes te maken; de IT-professional is uitstekend in staat om zelf te bepalen welke set van tools op welk moment het meest geschikt is. Binnen de corporate-portal is daarvoor om bovengenoemde redenen weinig tot geen ruimte, maar gelukkig bieden de nieuwe sociale tools op het internet een meer dan adequaat alternatief.

Het nieuwe web

Wie wil samenwerken met anderen zonder daarbij allerlei concessies te hoeven doen, doet er goed aan om de blik te verleggen van de zware, dure CMS/portal-omgevingen naar de open source oplossingen die aan de basis staan van het 'nieuwe web': weblogs, wiki's en rss. Deze tools zijn inmiddels zover doorontwikkeld dat ze niet langer afgedaan kunnen worden als speeltjes voor 'geeks'. Weblogs bijvoorbeeld zijn inmiddels doorgedrongen tot alle lagen van de bevolking, en ook het zakelijke bloggen neemt intussen een enorme vlucht.

Weblogs en wiki's zijn lichtgewicht applicaties en kunnen los van elkaar ingezet worden, maar ze gaan ook heel goed samen. Er is sprake van een duidelijke samenhang tussen de functionaliteiten van weblogs en wiki's. Weblogs zijn namelijk uitermate geschikt voor het communiceren van actuele dynamische content (nieuws), een wiki kan daarbij fungeren als aanvullende documentatie- of naslagruimte (achtergronden). En dan is er, niet te vergeten, nog het rss-protocol. Dit werkt als bindmiddel voor de content van beide systemen, het is de centrale schakel tussen zenders en ontvangers van informatie.

Wiki's worden door de enorme hype rondom weblogs enigszins overschaduwd, maar zeker in bedrijfsomgevingen zijn wiki's uitermate geschikt voor collectieve taken. Maar laten we beginnen bij het begin:

Wat is een wiki?

Een wiki is een collectie van hypertext documenten, zoals ook een website dat is, met dit verschil dat het bij een wiki iedere willekeurige gebruiker vrij staat om inhoud te creeëren of te bewerken. De belangrijkste kenmerken van een wiki:

  • gemakkelijke creatie en bewerking van inhoud via een simpele web-editor.
  • sterk vereenvoudigde wiki-opmaakcode, waarbij kennis van HTML-code niet nodig is.
  • een open structuur, waarbij iedereen die dat wil kan participeren. Uiteraard is het mogelijk om van de standaardinstelling af te wijken, de meeste wiki-applicaties bieden wel één of meerdere authorisatie-niveau's.
  • mogelijkheid om te linken naar nog niet bestaande pagina's. Zodra er op de verwijzing geklikt wordt, zal automatisch een pagina met die titel worden aangemaakt. De nieuwe pagina kan direct bewerkt worden.
  • automatisch versiebeheer. Oudere versies van gewijzigde pagina's worden bewaard en kunnen worden vergeleken met de huidige versie. Ongewenste wijzigingen (zoals spam) kunnen zo weer heel eenvoudig ongedaan gemaakt worden.
  • organische opbouw van structuur en content. Een wiki hoeft niet perse ingericht te worden, gebruikers kunnen zelf inhoud en structuur aanbrengen.

Het meest bekende voorbeeld van een wiki is natuurlijk WikiPedia, de online encyclopedie die door iedereen vrij gebruikt én gewijzigd mag worden. Andere globale wikiprojecten als WikiNews en WikiQuote zijn opgezet vanuit dezelfde gedachte dat kennis makkelijk overdraagbaar en vooral vrij toegankelijk moet zijn. De bedenker van de wiki-techniek, Ward Cunningham, deed dat al meer dan 10 jaar geleden na een bezoekje aan Hawaii. Wie meer wil weten van het ontstaan, de historie en ontwikkelingen rondom wiki's kan er op WikiPedia (vanzelfsprekend) van alles over vinden.

afbeelding: wikipedia.tif

Bovenstaande voorbeelden illustreren dat collectief werken aan eenzelfde doel via een wiki ook mogelijk is op zeer grote schaal, met een bijna onvoorstelbaar aantal pagina's en vele tienduizenden editors. Maar ook, of beter, juist op kleinere schaal zijn er vele toepassingsmogelijkheden. Binnen een bedrijfsomgeving kan een wiki bijvoorbeeld dienst doen als:

  • documentatiecentrum
  • usersupport (FAQ's)
  • brainstorming
  • verslaglegging
  • kennisdatabank
  • virtuele projectruimte
  • procedurehandboek
  • intranet

En deze lijst is verre van compleet, waarschijnlijk kunt u zelf straks nog wel tien goede toepassingsmogelijkheden bedenken.

Afwegingen en keuzes vooraf

Wie gaat zoeken op internet, komt al snel terecht bij lange lijsten met overzichten van wiki-applicaties. En waar op de ene site een wiki-toepassing geroemd wordt om z'n veelzijdige mogelijkheden, wordt diezelfde applicatie elders weer uiterst kritisch beoordeeld vanwege het ontbreken van een aldaar onmisbaar geachte functionaliteit. Beter dan uzelf daardoor te laten leiden is het om zelf scherp in beeld te hebben welke functionaliteiten in uw situatie belangrijk zijn. Stel eventueel een 'longlist' op van in aanmerking komende wiki-pakketten en maak een checklist met belangrijke punten, zoals hieronder:

  • Door wie wordt de software ontwikkeld? individu / bedrijf / open source community / ...
  • Onder welke licentie wordt de software gedistribueerd? Lees ook de kleine lettertjes!
  • Op welke schaal wordt er reeds door anderen met de software gewerkt? Grotere schaalgrootte betekent waarschijnlijk betere support.
  • Op welk platform draait de wiki-software? Zoek naar een applicatie die past bij uw server-specs.
  • Welke functionaliteiten voor editors zijn aanwezig? Soms ligt de nadruk teveel op de techniek, in plaats van op het gemak om tekst te kunnen schrijven en bewerken. Versiebeheer is belangrijk, evenals duidelijke opmaakregels.
  • Functionaliteiten voor lezers: Denk aan zoek-functie, heldere navigatie, overzichten en inhoudsopgaven en printervriendelijke versies van artikelen.
  • Functionaliteiten voor administrators: Inventariseer de mogelijkheden omtrent inhouds- en gebruikersbeheer. Is er een monitor-functie met email- en/of RSS attenderingen bij calamiteiten en welke beveiligingsmechanismen zijn voorhanden?
  • Access management: Kan de wiki tijdelijk offline worden gehaald of eventueel van internet worden afgeschermd (intranet-functie)? Welke mogelijkheden zijn er om ongewenst bezoek tegen te houden (spam).
  • Data import: kan content uit andere systemen geïmporteerd worden? Kunnen HTML, Word en PDF documenten geconverteerd of gekoppeld worden?
  • Interface styling: Zeker als een wiki onderdeel wordt van de bedrijfsomgeving is harmonisatie met de huisstijl van het bedrijf belangrijk (branding). Onderzoek daarom altijd of en hoe de wiki-interface visueel aangepast kan worden.
  • Content lock-in: waak er voor dat de content niet 'opgesloten' raakt in het systeem. Kies voor een zo open mogelijk formaat (RSS/XML), dat ten alle tijde geexporteerd kan worden.
  • Schaalbaarheid: Is de wiki bestand tegen intensief gebruik en kan het overweg met een groot aantal pagina's en gelijktijdige gebruikers? Kan de capaciteit eventueel uitgebreid worden?
  • Technische aspecten: Is het zonder externe expertise te installeren én te onderhouden. Hoe arbeidsintensief is het beheer?

De kans is groot dat uw 'longlist' na het doorlopen van bovenstaande checklist is uitgedund tot een 'shortlist' van nog enkele goede kandidaten. Als u de mogelijkheid heeft, installeer die applicaties dan in een testomgeving.

Beveiliging

Houdt zeker ook rekening met een punt dat bijzondere aandacht verdient: beveiliging. Zeker in bedrijfsomgevingen kan dit een uitermate belangrijk onderdeel zijn. Anders dan vaak verondersteld wordt, is het niet per definitie zo dat een wiki aan kracht verliest wanneer er toegangsrestricties worden ingesteld. Een wiki kan bijvoorbeeld achter de firewall worden geplaatst en als zodanig functioneren als intranet. Daarbij zijn dan alle gebruikers van het bedrijfsnetwerk (potentiele) gebruikers van de wiki en als zodanig helemaal vrij om -binnen de bedrijfsmuren- de wiki op een open, collectieve wijze te benutten.

Een andere belangrijke overweging in relatie tot beveiliging betreft authenticatie. Wiki's kennen een vrij laagdrempelige inlogprocedure, waarbij wie dat wil op ieder gewenst moment een account kan aanmaken. Binnen een bedrijfsomgeving is dat wellicht niet gewenst, sommige wiki's bieden daarom de mogelijk om gebruikers te authenticeren via bedrijfssystemen zoals bijvoorbeeld Windows NT of LDAP. Behalve een veiligere authenticatiemethode levert dit nog een voordeel op, Single Sign On. De gebruiker logt in op het nieuwe systeem met een reeds bekende username-wachtwoord combinatie, waardoor de drempel direct een stuk lager ligt.

Dan bestaat er nog zoiets als 'spam'. Voor iedere wiki die benaderbaar is via het internet is spam een zeer serieus gevaar. Steeds meer spammers hebben het speciaal voorzien op wiki's, niet omdat ze lezers van die wiki's willen overhalen hun producten te gebruiken, maar alleen omdat veel links op veel sites kan zorgen voor een hogere page ranking bij Google en andere zoekmachines. En vanwege de open structuur van wiki's kan een beetje spammer zonder al teveel moeite toegang krijgen en vele pagina's volstouwen met obscure links. Dat gebeurt allang niet meer handmatig, maar met automatische scripts.

Gelukkig zijn er diverse manieren om spam-vandalisme tegen te gaan. Verplichte authenticatie houdt al 95% van alle spammers buiten de deur. Voor die laaste 5% zijn ook maatregelen mogelijk, bijvoorbeeld het blokkeren van de toegang op basis van het IP-adres. Helaas maken spammers veel gebruik van open proxies, waarmee ze voortdurend van IP-adres wisselen. Een blacklist op basis van alleen het IP-adres heeft dan ook weinig nut. Moderne wiki's kunnen ook blokkeren op basis van (delen van) trefwoorden en URL's.

Wiki's bieden bijna altijd een protect-optie op paginaniveau aan. Deze optie kan worden ingeschakeld door een beheerder zodra een pagina echt 'af' is. De betreffende pagina blijft dan wel beschikbaar, maar kan niet meer worden bewerkt. Dit is natuurlijk ook een prima methode om spam tegen te gaan. Ook is het mogelijk om ervoor te zorgen dat een spammer niets opschiet met zijn 'nijvere' arbeid, simpelweg door alle in de wiki aanwezige links automatisch te voorzien van het attribuut "rel=nofollow". De zoekrobot van Google (en iedere andere grote zoekmachine) weet dan dat deze link niet gevolgd hoeft te worden, dus zal het ook geen invloed hebben op de pageranking van de doelpagina.

Tenslotte is het in sommige wiki's al mogelijk om een maximum te stellen aan het aantal links op één pagina en dat in combinatie met een maximum aantal lettertekens per minuut. Spam-robots houden daar niet van, het liefst spuwen ze binnen één seconde honderden URL's op.

Zelf doen of uitbesteden

Wie uiteindelijk dan toch aan de slag wil met wiki's, kan dat op verschillende manieren en op verschillende niveau's doen. Allereerst is het zeker niet onverstandig om eens rond te neuzen in bestaande openbare wiki's, zoals Wikipedia. Bewerk eens een pagina, experimenteer met de opmaakcode en bestuur de userinterface. Wie verder wil kijken dan alleen de editor-rol, kan op www.opensourceCMS.com een aantal voorgeïnstalleerde wiki's vinden waarmee voor de duur van één uur ingelogd kan worden in de rol van zowel editor als administrator.

Dat ter orientatie, maar voor het echte werk zult u toch een beslissing moeten nemen: zelf een wiki installeren, of uitbesteden. Voor wie zelf geen serverruimte ter beschikking heeft, of zich gewoon niet met het technisch beheer van een wiki wil bezighouden, bestaat namelijk de mogelijkheid om deze extern te laten hosten. Ook kunt u specialisten inhuren om uw intranet te laten inrichten of ombouwen als wiki. Bedrijven als Omnistrong en SocialText richten zich op dit deel van de markt. Het overgrote deel van alle wiki-omgevingen wordt echter geïnstalleerd, geconfigureerd en beheerd op een webserver van de gebruiker zelf. En waarom ook niet, serverruimte is goedkoop en alle benodigde software wordt gedistribueerd onder open source licenties.

Een wiki installeren

De stijgende populariteit van wiki's is te danken aan een combinatie van factoren, een daarvan is het sterk toegenomen gemak waarmee veel van de huidige wiki-software op een server geïnstalleerd kan worden. Illustratief is de open source wiki-applicatie MediaWiki, welke lange tijd berucht is geweest vanwege de bijna onmogelijke installatieprocedure. In dit praktijkvoorbeeld laten we zien hoe deze applicatie in enkele stappen gebruiksgereed gemaakt kan worden. In plaats van MediaWiki zouden we hier overigens ook een vergelijkbare wiki-applicatie als WakkaWiki of DocuWiki kunnen behandelen. De architectuur is vrijwel identiek en ook de installatieprocedures zullen onderling niet heel erg van elkaar afwijken. Maar voor nu hebben we gekozen voor MediaWiki, dit is het architectuurplaatje:

Afbeeldingen: mediawiki.tif en general_architecture.tif 

Om MediaWiki te installeren dienen de volgende componenten aanwezig te zijn:

  • MySQL 4.0.x (3.2.x is ook mogelijk)
  • Apache server, minimaal 256 MB geheugen. Installeren op een Windows-server is ook mogelijk.
  • PHP 4.1.2 of hoger
  • MediaWiki

Toevallig of niet, maar alle vier zijn voortgekomen uit de open source community, en dus is de software ook voor iedereen gratis beschikbaar.

De thuisbasis van MediaWiki is www.mediawiki.org. Er is een mogelijkheid om te kiezen voor de meest recente (maar nog in ontwikkeling zijnde) beta-versie en een stabiele versie. Wie serieuze plannen heeft om de wiki op korte termijn in te zetten als bedrijfstoepassing kan beter geen risico's nemen en kiezen voor de stabiele versie (momenteel versie 1.4.9). Omdat we deze wiki als testomgeving gaan inrichten, downloaden we de beta-versie (momenteel 1.5rc4). Voor de installatieprocedure maakt het overigens weinig uit, deze is voor beide versies vrijwel identiek.

Je kunt ook deze handleiding gebruiken om Mediawiki offline op Windows (XP) te installeren. Zo kun je zonder webserver mediawiki uitproberen.

stap 1 - download en unzip

Download de meest recente versie van http://sourceforge.net/projects/wikipedia en unzip de bestanden in een directory op de lokale harde schijf.

Afbeelding: download en unzip.tiff

Stap 2 - Upload via FTP

Start een FTP-sessie op en maak contact met uw webserver. Maak er een nieuwe directory aan, bijvoorbeeld 'wiki'. Kopieer nu alle (sub)mappen en bestanden vanuit de lokale harde schijf naar de map 'wiki' op de webserver. Upload de tekstbestanden (PHP, HTML) als ASCII en afbeeldingen (JPG, GIF, PNG) als binaire bestanden.

afbeelding: ftp.tiff

Selecteer de subdirectory 'config' en maak deze schrijfbaar via het commando 'CHMOD 777' of 'CHMOD A+W CONFIG'.

afbeelding: chmod.tiff

Stap 3 - Configuratie via de browser

Open uw webbrowser en surf naar de zojuist aangemaakte directory, zoiets als www.website.nl/wiki. Het installatiescript kan nu worden opgestart.

De server-configuratie wordt kort geïnspecteerd. Mits deze wordt goedgekeurd volgt daarop een invuloefening. Wel even goed opletten bij de database configuratie, alleen als u beschikt over het 'root password' van de MySQL database kunt u direct een nieuwe database aanmaken. Vaak is dat niet zo, en beschikt alleen de hostingprovider over dit wachtwoord. In dat geval kunt u ook een bestaande MySQL database gebruiken, of eventueel een nieuwe database (laten) aanmaken met behulp van de hostingprovider.

afbeelding: database config.tif

Als alle velden goed zijn ingevuld, klikt u op 'Install'. Zodra het installatiescript is afgerond, wordt u gevraagd om het bestand 'LocalSettings.php' te kopieëren van de directory 'config' naar de hoofdmap. Maak daarna via 'CHMOD 640' de directory 'config' weer ontoegankelijk voor ongewenste gasten. Nog veiliger is het om de gehele directory 'config' van de server te verwijderen.

De software is nu geïnstalleerd en gebruiksklaar, u wordt door het installatiescript doorgestuurd naar de hoofpagina van de wiki.

afbeelding: succes install.tif

Direct aan de slag

Een specifiek kenmerk van MediaWiki, en wiki's in het algemeen, is de open en vrije werkwijze. Er hoeft in principe geen webmaster, redacteur of contentmanager te zijn die vooraf bepaalt welke informatie onder welk knopje geplaatst moet worden. In plaats daarvan zijn het de gebruikers zelf die het geheel op een bijna organische manier inhoud en vorm kunnen geven. Vooral bij projecten, waarbij het doel voor iedere deelnemer hetzelfde is, werkt deze opzet uitstekend. Het installeren van een 'lege' wiki, zoals hierboven, is dan eigenlijk al voldoende. De projectgroep kan direct zelfstandig aan de slag, men kan eigenhandig inlogaccounts aanmaken en pagina's toevoegen en bewerken. Met behulp van zelf te definiëren categorieën kunnen de gebruikers zelf structuur in de wiki aanbrengen.

Om aan te geven hoe eenvoudig dit is, een voorbeeld:

afbeelding: edit mainpage.tiff

Door op de 'edit'-knop te drukken, kan de inhoud van de pagina direct bewerkt worden. In dit voorbeeld hebben we de oorspronkelijke tekst vervangen door een korte introductietekst over een (fictief) project Webwerken. Eenmaal klikken op 'Save Page' zorgt er voor dat de pagina -met nieuwe inhoud- wordt opgeslagen. De oude versie van de pagina is overigens niet verloren, maar gearchiveerd. Laten we eens kijken hoe de aangepaste pagina er nu uitziet:

afbeelding: new mainpage.tif

Goed zichtbaar is de uitwerking van de wiki-opmaakcode. De koptitel 'Project Webwerken' werd vooraf gegaan door drie '=' tekens en werd ook op dezelfde manier weer afgesloten. Deze wiki-code wordt automatisch vertaald naar een H1 (header) element. De met dubbele haken ( .... ) gemarkeerde woorden zijn opgemaakt als interne link. Let wel, deze links zijn wel aanklikbaar, maar bestaan nog niet. Zodra zo'n link wordt aangeklikt verschijnt er echter geen foutpagina. Integendeel, de pagina wordt 'on the fly' aangemaakt en de gebruiker kan er direct content aan toevoegen. Tenslotte nog een toelichting over de woorden die worden voorafgegaan door een asterix (*), deze worden vanzelf in een opsommingslijst geplaatst. Vervang de asterix door een hekje (#) en het wordt vanzelf een genummerde lijst. Ter vergelijking, in html-opmaakcode zou zo'n lijst zo opgemaakt moeten worden:

<ol>
 <li><a href="technische realisatie">technische realisatie</a></li>
 <li><a href="scholing">scholing</a></li>
 <li><a href="kennisdelen">kennisdelen</a></li>
</ol>

Wiki opmaakcode

Het zal duidelijk zijn; wie de moeite neemt om zich de wiki-opmaakcode eigen te maken, kan zich veel tijd en moeite besparen. Die wiki-opmaakcode is trouwens in een vloek en een zucht onder de knie te krijgen. In onderstaand overzicht worden alle belangrijke opmaakcodes opgesomd, inclusief voorbeeld:

What it looks like What you type

Start your sections with header lines:


New section

Subsection

Sub-subsection


== New section ==

=== Subsection ===

==== Sub-subsection ====
You can break lines
without starting a new paragraph.
You can break lines<br>
without starting a new paragraph.
  • Lists are easy to do:
    • start every line with a star
      • more stars means deeper levels


* Lists are easy to do:
** start every line with a star
*** more stars means deeper levels


  1. Numbered lists are also good
    1. very organized
    2. easy to follow


# Numbered lists are also good
## very organized
## easy to follow

  • You can even do mixed lists
    1. and nest them
      • like this
        or have newlines
        inside lists
* You can even do mixed lists
*# and nest them
*#* like this<br>or have newlines<br>inside lists
  • You can also
    • break lines
      inside lists
      like this
* You can also
**break lines<br>inside lists<br>like this
A colon indents a line or paragraph.

A manual newline starts a new paragraph.

: A colon indents a line or paragraph.
A manual newline starts a new paragraph.
What it looks like What you type

Emphasize, strongly, very strongly.

  • These are double and triple apostrophes, not double quotes.
''Emphasize'', '''strongly''',
'''''very strongly'''''.
You can use small text for captions.
You can use <small>small text</small> 
for captions.
You can strike out deleted material

and underline new material.

You can <strike>strike out deleted material</strike>
and <u>underline new material</u>.
 Start with a space shows preformatted text
 Start with a space shows preformatted text
Centered text.
<center>Centered text.</center>

A horizontal line: 
----
What it looks like What you type
Sue is reading the video policy.
  • First letter of target is automatically capitalized.

Thus the link above is to http://meta.wikipedia.org/wiki/Video_policy, which is the page with the name "Video policy".

Sue is reading the [[video policy]].

Link to a section on a page, e.g.

List_of_cities_by_country#Morocco
[[List_of_cities_by_country#Morocco]].
Link target and link label are different: answers.

(This is called a piped link).

Same target, different name:
[[User:Larry Sanger|answers]]
Endings are blended into the link: official positions, genes
Endings are blended
into the link: [[official position]]s, [[gene]]s

Automatically hide stuff in parentheses: kingdom.

Automatically hide namespace: Village pump.

Automatically hide stuff in parentheses:
[[kingdom (biology)|]]. 
Automatically hide namespace:
[[Wikipedia:Village pump|]].
When adding a comment to a Talk page,

you should sign it. You can do this by adding three tildes for your user name:

Karl Wick

or four for user name plus date/time:

Karl Wick 08:10 Oct 5, 2002 (UTC)
When adding a comment to a Talk page,
you should sign it. You can do this by
adding three tildes for your user name:
: ~~~
or four for user name plus date/time:
: ~~~~
The weather in London is a page that doesn't exist yet.
  • You can create it by clicking on the link.
  • To create a new page:
    1. Create a link to it on some other page.
    2. Save that page.
    3. Click on the link you just made. The new page will open for editing.
[[The weather in London]] is a page
that doesn't exist yet.

Redirect one article title to another by putting text like this in its first line.

#REDIRECT [[United States]]
External links: Nupedia, [1]
External links:
[http://www.nupedia.com Nupedia],
[http://www.nupedia.com]
Or just give the URL: http://www.nupedia.com.
Or just give the URL:
http://www.nupedia.com.

To link to books, you can use ISBN links. ISBN 0123456789X

ISBN 0123456789X

To include links to non-image uploads such as sounds, use a "media" link.
Sound


[[media:Sg_mrob.ogg|Sound]]
What it looks like What you type
A picture: Afbeelding:Wiki.png
A picture: [[Image:Wiki.png]]

or, with alternate text (strongly encouraged)

[[Image:Wiki.png|Wikipedia 
- The Free Encyclopedia]] 

Clicking on an uploaded image displays a description page, which you can also link directly to: Image:Wiki.png

[[:Image:Wiki.png]]

To include links to images shown as links instead of drawn on the page, use a "media" link.
Image of a Tornado


[[media:Tornado.jpg|Image of a Tornado]]
You'll see the image under this URL:

http://www.website.com/image.gif

To show an image that is hosted externally, just put the URL to the image

De beginnende gebruiker hoeft alleen bovenstaande lijst bij de hand te houden, en zelfs dat hoeft na verloop van tijd niet meer.

Documentmanagement

Veruit de meestgenoemde redenen om niet in een CMS-systeem, maar juist in de vorm van een wiki te gaan samenwerken zijn de uitstekende voorzieningen van wiki's als het gaat om documentmanagement. Contentmanagement-systemen komen nog altijd niet veel verder dan het onhandige 'check-out', 'check-in' principe. Zolang één persoon actief bezig is met een document (check-out) is het voor anderen niet beschikbaar. Pas als het document weer wordt ingecheckt kan een ander verder met het gewijzigde document. Doordat men in deze werkvorm op elkaar moet gaan wachten gaat veel kostbare tijd verloren.

In een wiki wordt dat anders opgelost. De ingebouwde voorzieningen voor versie- en wijzigingsbeheer zijn namelijk van bijzonder hoogstaand niveau. In vergelijking met de wat omslachtige oplossingen van CMS systemen gaan wiki's veel soepeler en vooral slimmer om met documenten. Zo kan ieder lid van een projectteam zonder problemen tegelijkertijd werken aan hetzelfde document. Daarbij is het niet zo dat men op elkaar moet wachten, of elkaars bewerkingen 'live' in beeld krijgt. Bij het opslaan van het document wordt eenvoudigweg gevraagd of de zojuist gedane bewerkingen moeten worden samengevoegd met het meest recente document. Simpel en doeltreffend.

Wie wil zien of- en welke wijzigingen in de tussentijd door anderen zijn aangebracht, kijkt gewoon even naar de document-historie. Het overzicht van de bewerkingsgeschiedenis toont precies die velden welke belangrijk zijn.

afbeelding: bewerkingsgeschiedenis.tif

Niet alleen dat, alle verschillende versies kunnen inhoudelijk met elkaar vergeleken worden. Op die manier kunnen ongewenste toevoegingen heel eenvoudig weer verwijderd worden. Of net andersom, verwijderde content kan even zo snel ook weer teruggeplaatst worden.

afbeelding: bewerking-verschil.tif: wijzigingen worden keurig in rood aangegeven.

En wat te doen met notities die wel gaan over het document, maar er niet in thuishoren? Ook daar is een even simpele als inventieve oplossing voor; aan ieder document wordt automatisch een zogenaamde overleg- (of discussie)pagina gekoppeld. Op die pagina is ruimte voor ieders 'kantlijn-krabbels', vragen en opmerkingen die relevant zijn voor het actieve document. Op een bijna speelse methode ontstaan er onderlinge discussies en aanvullingende teksten ter overweging. Kortom, de overlegpagina's doen dienst als collectieve groepsruimte.

afbeelding: discussie.tif

Documenten- en de bijhorende overlegpagina's kunnen dus regelmatig aangepast worden, iets wat in een projectsituatie juist ook de bedoeling is. Voor de projectleden is het echter wel zaak om daarvan op de hoogte te blijven. MediaWiki heeft een tweetal ingebouwde attenderingsmogelijkheden. Ten eerste is daar natuurlijk RSS (of ATOM) voor monitoring van recente wijzigingen en nieuwe pagina's. De tweede -meer verfijnde- optie is de mogelijkheid om pagina's automatisch te gaan volgen via een zogenaamde 'watchpage'.

afbeelding: volglijst.tif

Standaard worden alle wijzigingen in gemarkeerde pagina's keurig op een persoonlijke volgpagina geplaatst. Daarbij is het mogelijk om bij grote (en eventueel ook kleine) paginawijzigingen een email-notificatie te laten bezorgen.

Overigens kent MediaWiki ook redactiemogelijkheden. Pagina's kunnen door een supervisor tijdelijk of definitief geblokkeerd worden. Dergelijke pagina's blijven wel beschikbaar, maar mogen niet langer gewijzigd worden. Diezelfde supervisor kan nieuwe documenten ook eerst inspecteren en daarna officieel goedkeuren door ze te voorzien van de 'approved'-status.

Gebruikersrollen

Editors

De beginnende editor zal waarschijnlijk maar een beperkt deel van de bestaande wiki-opmaakcode benutten. Maar omdat alle ingevoerde wiki-opmaakcode (dus ook die van andere, meer gevorderde gebruikers) in het edit-venster zichtbaar is, zal die beginnende gebruiker als vanzelf bekend raken met het gehele palet aan opmaakcodes. Editors houden zich dus bezig met inhoud, niet met de vorm. Wel heeft iedere gebruiker wel toegang tot een aantal voorkeursinstellingen, waaronder ook een eventuele alternatieve gebruikers-interface.

Administrators

Alle opmaakcode in bovenstaande tabel is vooral bruikbaar voor de reguliere gebruikers (editors). De rol van de beheerder, ook wel administrator of sysop genoemd, ligt vooral op het vlak van beveiliging en configuratie. Vandaar beschikt de administrator over een meer uitgebreide set aan mogelijkheden. Zo kan een administrator gebruikers en IP-adressen (tijdelijk of permanent) blokkeren en alle systeemteksten aanpassen -direct in de wiki zelf- via de pagina 'Special:Allmessages'. Ook kan een administrator meer (of minder) rechten geven aan gebruikers en nieuwe gebruikersrollen definiëren.

afbeelding systemmessages.tif: rechtstreeks vanuit de wiki systeemteksten aanpassen.

Local en Default Settings

Voor nieuwe administrators enigszins verwarrend is de functie van het bestand 'LocalSettings.php' in de root-map van de wiki. Het lijkt namelijk in eerste instantie niet meer dan het bestand met standaard configuratie-settings zoals die bij de inrichting van de wiki eenmalig gedefinieerd worden. Voor wie tevreden is met de standaardconfiguratie klopt dat ook wel, echter zodra er iets aan die standaardinstellingen aangepast, gewijzigd of toegevoegd moet worden, dient dat te gebeuren via 'LocalSettings.php'. Wie bijvoorbeeld gebruikers wil toestaan om afbeeldingen te uploaden, dient dat via 'LocalSettings.php' te activeren. Wie een algemene disclaimer als voetnoot onder iedere pagina wil plakken, doet dat via ditzelfde bestand. Ook extensions, een soort van plugins, worden via dit bestand geactiveerd. Wie anonieme pottenkijkers wil weren, kan onderstaande code aan 'LocalSettings.php' toevoegen. Hiermee is alleen de hoofdpagina, de inlogpagina en de help-pagina van de wiki openbaar, alle andere pagina's zijn alleen toegankelijk voor ingelogde leden.

# Pages anonymous (not-logged-in) users may see
$wgWhitelistRead = array ("Main Page", "Special:Userlogin", "Wikipedia:Help");

Om het nog wat lastiger te maken hebben de makers van MediaWiki ook nog een bestand 'DefaultSettings.php' toegevoegd, dit is terug te vinden in de directory '/includes'. Wie dit bestand opent met een teksteditor, ziet nog een hele rij aan optionele configuratie-instellingen. Zo is code beschikbaar waarmee gebruik van JavaScript en CSS-schema's door gebruikers kan worden geblokkeerd of toegestaan. Belangrijk is de code waarmee anonieme toegang geblokkeerd kan worden. Ook wat meer experimentele opties, zoals anti-spam maatregelen en de mogelijkheid om een trackback-functie in te stellen zijn ondergebracht in 'DefaultSettings.php'. Het is echter uitdrukkelijk niét de bedoeling om deze opties -die standaard allemaal inactief zijn- te activeren in dit bestand zelf. De truc is om de bruikbaar geachte code over te hevelen naar 'LocalSettings.php' in de root-directory. Wie direct gaat muteren in 'DefaultSettings.php' loopt namelijk het risico alle daarin aangepaste instellingen kwijt te raken bij een upgrade van de MediaWiki-software. Het enige bestand wat gegarandeerd niet overschreven wordt bij een upgrade is 'LocalSettings.php'.

afbeelding localsettings.tiff: 
Ook het standaardlogo in de linkerbovenhoek wordt via 'LocalSettings.php' aangepast.

Cascading Style Sheets

Voor heel veel wiki's ligt de nadruk niet zozeer op de vormgeving, maar gaat het vooral om de inhoud. Wie via Google zomaar willekeurig een aantal wiki's opzoekt en bekijkt, zal zien dat heel vaak van dezelfde standaard-layout gebruikt gemaakt wordt. Deze standaard template (of skin) is ontwikkeld door MediaWiki en draagt de titel 'Monobook'. Die zo vaak voorkomende standaard-layout zit bijvoorbeeld ook in Wikipedia, deze globale encyclopedie wordt -niet geheel toevallig- onderhouden met MediaWiki-software. Er zijn standaard nog een paar alternatieve templates geïnstalleerd, maar in de praktijk worden die bijna nooit toegepast. Het visuele onderscheid tussen verschillende wiki's wordt vaak dus alleen gemaakt door een eigen logo te plaatsen in de linkerbovenhoek, verder moet de inhoud voor zich spreken. Voordeel daarvan is natuurlijk dat wie eenmaal gewend is aan het werken met een wiki in deze opmaak, waarschijnlijk ook weinig drempelvrees zal hebben om later ook bijdragen te leveren aan andere vergelijkbare wiki's.

Dat werkt meer dan uitstekend in de private sector, maar binnen een bedrijf gelden vaak andere regels. Een webapplicatie moet niet alleen technisch passen in de ICT architectuur, maar zeker en vooral ook visueel. Dat betekent dat een wiki zich zal moeten committeren aan de huisstijl van het bedrijf; de lettertypen, kleurenschema's, navigatie- en grafische elementen dienen te worden afgestemd op de bestaande online bedrijfsomgeving.

Laat webdesign nu net het meest ingewikkelde onderdeel van MediaWiki zijn. Wie daarbij niet weet waar en hoe te beginnen, kan eindeloos dwalen over sites met vele pagina's met goedbedoelde- maar vaak niet werkende tips en oplossingen. De eerlijkheid gebied te zeggen dat dit door de opzet van MediaWiki enigszins in de hand wordt gewerkt. Bij iedere nieuwe MediaWiki-installatie wordt namelijk in het navigatiemenu prominent verwezen naar de Help-pagina. Deze wordt echter geleverd zonder content, dat wordt volledig aan de nieuwe eigenaar zelf overgelaten. Gevolg: de hulppagina's worden vaak niet ingericht door experts, maar door net beginnende wiki-gebruikers. En omdat er ontzettend veel van dit soort pagina's zijn, krijgen ze van Google vaak voorrang op de officiële documentatie die te vinden is op de wiki van MediaWiki zelf. Heel verstandig dus om deze URL te bookmarken: http://www.mediawiki.org/.

Monobook Skin

Laten we er eens vanuitgaan dat de eerder geïnstalleerde wiki ingebed moet worden in een corporate site. Dit betekent dat de Monobook-skin ofwel omgebouwd, of volledig vervangen moeten worden. Wie gaat voor optie één moet alle elementen in het Monobook CSS-schema gaan vertalen naar het CSS-schema van de corporate-site. Wie het Monobook CSS-schema in zijn geheel wil vervangen, bewandelt de omgekeerde weg. Voor beiden valt iets te zeggen, want qua tijdsinspanning zullen beide opties wel ongeveer evenveel tijd kosten.

Het voordeel van de eerste optie is dat de diverse elementen al keurig in hapklare blokken zijn onderverdeeld. Een klein voordeel van de laatste optie is dat alle elementen en attributen zoals benoemd in het CSS-schema van uw eigen site overgenomen kunnen worden in het Monobook CSS-schema. Hieronder staat de gestripte versie van het template (of skin) bestand 'Monobook.php'. Door alle tussenliggende PHP-code even weg te filteren, wordt de opbouw van de stijl-elementen binnen de pagina mooi zichtbaar:

afbeelding monobook-code.tif
  • 1: de globale 'wrapper' omvat alle tussenliggende elementen. De bijbehorende CSS-code is vrij standaard en zal daarom waarschijnlijk niet aangepast hoeven te worden. Met uitzondering van 'font-size' wellicht, die staat namelijk ingesteld op een variabele grootte van 127 procent.
  • 2: 'column-content' is de plaatshouder voor de centrale content. De CSS code van dit element, en ook die van de twee onderliggende elementen zal meestal flink aangepast moeten worden om te passen in een huisstijl.
  • 3, 4, 5 en 6: 'column-one' omvat de verzamelde navigatie-elementen binnen de linker-kolom. Het meeste werk zal met name hierin gaan zitten. De menu-elementen in MediaWiki worden opgemaakt met H5-headers als kopelement en ongenummerde lijsten (UL, LI) voor de menu-items. Veel sites gebruiken hier nog tabellen, paragraaf-elementen of zelfs Java-code voor. In die gevallen is de te gebruiken CSS-code van de wiki niet makkelijk in overeenstemming te brengen met die van de bedrijfs-site.
  • 7: 'footer' spreekt voor zich, de plaatshouder voor een eventuele voetnoot.

Natuurlijk kan met een geheel nieuwe PHP-skin en CSS-schema ook geheel voorbij gegaan worden aan de vooraf gedefinieerde Monobook-configuratie. Dat mag soms verstandig lijken, maar wie de gehele broncode van 'Monobook.php' eens goed bestudeert zal zien dat het heel ingenieus en met veel gevoel voor detail is afgewerkt. Zo wordt er bijvoorbeeld rekening gehouden met de povere CSS-ondersteuning van oudere browsers als Internet Explorer 5 en 5.5. En waarom zou je het wiel dan nogmaals zelf uitvinden, terwijl er al een glimmende bolide voor je klaarstaat.

Voor wie niet direct gebonden is aan een vaste huisstijl, maar toch wat meer afstand wil nemen van de standaard MediaWiki-interface, kan inspiratie opdoen bij de 'Gallery of user styles': http://meta.wikimedia.org/wiki/Gallery_of_user_styles.

Extensions

Hoewel MediaWiki zelf al over een bijn aduizelingwekkend aantal features beschikt, zijn er altijd wel specifieke situaties te bedenken waarin de standaard-software niet voorziet. Om die reden heeft MediaWiki het systeem opengesteld voor zogenaamde 'extensions', een soort van plugins. Hiervan bestaan vele soorten en varianten. Sommigen zijn alleen gemaakt om bepaalde acties eenvoudiger te maken, anderen voegen geheel nieuwe functionaliteit toe. Op het adres http://meta.wikimedia.org/wiki/Category:Mediawiki_Extensions worden vele extensies aangeboden. Zo zijn er extensies beschikbaar waarmee kalenders, weblogs, LDAP authenticatie, iFrames en zelfs stukjes van Google Maps in de wiki geïntegreerd kunnen worden.

Extensie toevoegen

Een extensie toevoegen aan MediaWiki is kinderlijk eenvoudig.

  • Stap 1: knip en plak de broncode in een leeg tekstdocument. Sla het document als een PHP-bestand, gebruik als naam de titel van de extensie.
  • Stap 2: kopieër met behulp van FTP het PHP-bestand naar de webserver, plaats het bestand in de submap '/extensions'.
  • Stap 3: open het bestand 'LocalSettings.php' en voeg onderstaande code toe:
include("extensions/extensienaam.php"); 
  • Stap 4: plaats 'LocalSettings.php' weer terug op de server, in de root van de wiki.

Hoewel de extensie direct wordt geactiveerd, kan een 'browser-refresh' via functietoets F5 soms nodig zijn om het resultaat te zien.

Dynamische paginalijsten

Een voorbeeld van zo'n handige extensie die bepaalde wiki-acties makkelijk maakt is DynamicPageList2. Met deze extensie kunnen gebruikers selectieve lijsten maken van pagina's die aan elkaar gekoppeld zijn via categorieën. Dat klinkt ingewikkelder dan het werkelijk is. De kracht van deze dynamische lijsten zit 'm namelijk in de toepassing van de logische operatoren AND en OR.

Een voorbeeld:

<DynamicPageList>
category=Aandelen,Obligaties
category=Juristen
</DynamicPageList> 

Het resultaat wat op de pagina getoond zal worden, is een index van alle pagina's die vallen onder de categorie 'Aandelen' OF 'Obligaties' EN 'Juristen'. De naam van de extensie geeft het al aan, deze lijsten zijn dynamisch, ze zullen dus aangepast worden zodra er pagina's worden verwijderd of toegevoegd aan één van de drie categorieën.

Naast 'extensions' bestaan er overigens ook nog 'MediaWiki Hacks' en 'MediaWiki Tools'. Het onderscheid tussen deze drie is niet altijd even makkelijk, vandaar dat sommige hacks bijvoorbeeld ook geregistreerd staan als extension.

Multimedia

De historie van de wiki is die van een webbased teksteditor. Vandaar wordt bij wiki's niet snel gedacht aan multimediale content. Toch is een wiki ook hier geschikt voor. Zo ook MediaWiki, waar standaard al een upload-optie en afbeeldingengalerij is ingebouwd. Uploads zijn normaliter beperkt tot afbeeldingen van het PNG, JPG en GIF formaat en mediabestanden van het OGG formaat. Dit wil echter niet zeggen dat andere bestandsformaten niet worden toegestaan. Integendeel, ook dit is geheel in handen van de wiki-eigenaar. Het eerder genoemde bestand 'DefaultSettings.php' bevat alle benodigde code:

/**
* This is the list of preferred extensions for uploading files. Uploading files
* with extensions not in this list will trigger a warning.
*/
$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg' );

/** Files with these extensions will never be allowed as uploads. */
$wgFileBlacklist = array(
	# HTML may contain cookie-stealing JavaScript and web bugs
	'html', 'htm', 'js', 'jsb',
	# PHP scripts may execute arbitrary code on the server
	'php', 'phtml', 'php3', 'php4', 'phps',
	# Other types that may be interpreted by some servers
	'shtml', 'jhtml', 'pl', 'py', 'cgi',
	# May contain harmful executables for Windows victims
	'exe', 'scr', 'dll', 'msi', 'vbs', 'bat', 'com', 'pif', 'cmd', 'vxd', 'cpl' );

Hoewel met de inrichting van een wiki gestreefd zou moeten worden naar het zoveel mogelijk benutten van die wiki, zal er in bedrijfssituaties altijd behoefte blijven bestaan aan documentopslag in bestandsformaten als MS Word, PDF, Excel en Powerpoint. Een kleine aanpassing in bovenstaande code is voldoende om ook die formaten toe te staan:

$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'doc', 'pdf', 'xls', 'ppt' );
afbeelding upload.tif

De wijzigingen moeten in 'LocalSettings.php' worden doorgevoerd, direct daarna kunnen de nieuwe bestandsformaten worden geuploaded. Om nu te voorkomen dat een niet geheel deskundige medewerker per ongeluk het volledig gescande telefoonboek in PDF-vorm op de wiki gaat plaatsen, is er ook een stukje code om de maximale bestandsomvang aan te geven:

/** Warn if uploaded files are larger than this */
$wgUploadSizeWarning = 150 * 1024;

Vergeet niet dat aangepaste code altijd vanuit 'DefaultSettings.php' overgeheveld moet worden naar 'LocalSettings.php'. Wie direct wijzigt in het eerste bestand, verliest de wijzigingen bij een software-upgrade.

Naast deze methode van toestaan van multimediale content bestaan er ook enkele media-extensies, bijvoorbeeld om Macromedia Flash-objecten te kunnen gebruiken en om tekst interactief om te zetten naar grafische muzieknoten. En hoe geniaal eenvoud kan zijn, toont MediaWiki aan met de wijze waarop externe afbeeldingen ingebed kunnen worden. Simpelweg door de URL van de betreffende afbeelding op te nemen in de wiki-pagina.

Tot Slot

Het is niet moeilijk om in te zien dat wiki's ongekende mogelijkheden hebben. Om die mogelijkheden ook echt te ervaren, daar is toch wel een beetje doorzettingsvermogen voor nodig. Want het installeren van de software mag dan tegenwoordig een koud kunstje zijn, het echte werk begint daarna pas. De fijnafstemming van alle opties is een behoorlijke klus, evenals het organiseren van een afdoende beveiliging. Daarbij komt vaak nog een stukje webdesign, een onderdeel waar wiki's nog niet echt in uitblinken. En als dan uiteindelijk de wiki helemaal gebruiksklaar is, bevat het systeem nog niet eens content. Dat mogen de gebruikers samen voor rekening nemen, waarbij ze nog wel even de wiki-opmaakcode onder de knie moeten krijgen.

Maar als die laatste lastige horde eenmaal is genomen, zal de wiki ook in het bedrijfsleven gaan floreren. De combinatie weblog, wiki en RSS wordt door ICT deskundigen al 'de nieuwe super-portal' genoemd. Sta dus niet raar te kijken als uw dure CMS en/of portalsoftware binnenkort worden voorzien van wiki-functionaliteiten. Of u daar genoegen mee neemt is aan u, met MediaWiki heeft u in ieder geval altijd een ijzersterk alternatief achter de hand.

Leesvoer

---

Afkomstig van GerardBierens.nl NL, de Vrije Encyclopedie. "http://www.gerardbierens.nl/index.php/MediaWiki_in_bedrijf"
Personal tools