Hoe nieuwsarchieven meestal ontsloten zijn: paginering

Je ziet ze vooral vaak op weblogs: nieuwsarchieven die al het oude nieuws keurig pagineren. Op elke pagina vind je een lijstje van tien nieuwskoppen, ieder met een link naar een aparte pagina met het volledige bericht. Met een bladerfunctie onderaan de pagina spring je van pagina 1 naar pagina 2, naar pagina 3, enzovoorts.

Deze manier van navigeren lijkt veel op de manier waarop Google zoekresultaten presenteert:

Of soms wordt de bladerfunctie simpelweg ingekort tot bijvoorbeeld:

Het bladeren door overzichten die over meerdere pagina’s zijn uitgesmeerd kom je kortom overal tegen op het web. Maar is een wijdverbreide methode ook automatisch een goede methode? Vaak wel, maar niet als het gaat om paginering.

Pagineren is een slechte ervaring voor bezoekers

Om de vergelijking met Google-zoekresultaten even verder door te trekken: als je zelf een zoekterm intikt in Google en je een lijst van gevonden pagina’s krijgt, hoeveel treffers bekijk je dan? De eerste 3, de eerste 10, de eerste 30? Als je een doorsnee gebruiker bent: waarschijnlijk hooguit de eerste 10, en vaak nog minder dan dat.

Uit onderzoek blijkt dat internetgebruikers steeds ongeduldiger worden en al lang niet meer de moeite nemen om na de eerste 10 treffers door te klikken naar het vervolg. Internet is een snel medium, internetgebruikers zijn ongeduldig en hebben een groeiende afkeer van lange overzichten. Een navigatiebalk met de mogelijkheid om naar de volgende pagina met 10 treffers te gaan, en weer een pagina met nog meer treffers, en weer een pagina: het is vaker een afhaakmoment dan een aanmoediging om door te gaan.

Pagineren is ook slecht voor Google

Al vaker heb ik het geschreven: een slechte ervaring voor menselijke bezoekers gaat opvallend vaak samen met een slechte ervaring voor zoekmachines. Zo ook hier. Internetgebruikers haken op zeker moment af, maar Google doet dat ook. Natuurlijk is Google prima in staat om al je tientallen overzichtspagina’s door te fietsen en vandaaruit de volledige berichten te vinden. Maar Google doet dat niet. Op veel sites zie je hetzelfde patroon: vanuit de homepage volgt Google een linkje of drie en de rest laat hij zitten – die zit te ver weggestopt.

Je kunt eenvoudig zelf de proef op de som nemen. Installeer bijvoorbeeld de Firefox-plugin SearchStatus. Als je na installatie gaat surfen, dan zie je rechts onderaan elke webpagina die je bezoekt de pagerank, een getal van 0 tot 10 waarmee Google de reputatie van die pagina classificeert (het groene balkje, niet het blauwe).

Duik nu eens diep in een willekeurig nieuwsarchief, bijvoorbeeld dat van Marketingfacts of Emerce. Bijna overal zie je hetzelfde beeld: nieuwsberichten met een pagerank van 0. Dat betekent dat Google zo’n pagina óf nog helemaal niet heeft ontdekt, óf wel heeft ontdekt maar er geen waarde aan hecht. Wat kun je daaraan doen?

Een XML-sitemap is niet voldoende

De standaardoplossing voor problemen met vindbaarheid in Google is om een XML-sitemap te maken met een volledige inhoudsopgave van je hele site. Zo’n sitemap is niet bedoeld voor menselijke bezoekers, maar alleen om zoeksystemen op de hoogte te houden van wijzigingen op je site.

Aan de hand van de XML-sitemap ziet Google voortaan precies welke pagina’s op je site nog ontbreken in zijn index. Veel contentmanagementsystemen genereren standaard XML-sitemaps, of hebben daar speciale plugins voor. Een kind kan de was doen.

Probleem opgelost? Niet helemaal. Natuurlijk wordt een website nooit slechter van een extra XML-sitemap. Maar een XML-sitemap heeft wel een belangrijke SEO-beperking: hij verbetert wel de vindbaarheid van dieperliggende pagina’s, maar niet de reputatie oftewel de pagerank. Webpagina’s krijgen pas reputatie als ze goede en duurzame links van andere pagina’s krijgen – vanaf de eigen website of vanaf andere sites.

Die duurzaamheid is een probleem bij chronologische paginering. Een recent nieuwsbericht is eerst vindbaar via overzichtspagina 1 (met nieuwsberichten 1 t/m 10), een paar dagen/weken later via overzichtspagina 2 (met nieuwsberichten 11 t/m 20), daarna overzichtspagina 3, enzovoorts. Naarmate het archief groeit, schuift dat bericht verder door en is het steeds een andere overzichtspagina (4, dan 5, dan 6, dan …) die ernaar linkt. De kans is groot dat dat bericht altijd op pagerank 0 blijft steken. Google houdt van duurzaam gestructureerde websites en niet van links die eerst op de ene en dan op de andere overzichtspagina staan.

Hoe het beter kan: een platte linkstructuur

Om oude nieuwsberichten wat pagerank te bezorgen, moeten we dus zorgen voor links vanaf vaste pagina’s, niet vanaf wisselende pagina’s. De simpelste oplossing: maak één lange overzichtspagina met links naar álle oude nieuwsberichten, ook al zijn het er meer dan duizend. In feite laat je dus gewoon de paginering weg. Hou je nog maar één enkele vaste pagina over.

Deze radicale oplossing lost in ieder geval het probleem op van de slechte Google-vindbaarheid. Als de homepage van je website rechtstreeks linkt naar deze overzichtspagina, dan zijn alle oude nieuwsberichten precies twee muiskliks verwijderd van de homepage. Zelfs zonder een XML-sitemap zal Google al je oude berichten vinden.

Wel blijft er nog een ander probleem: een overzichtspagina met honderden of zelfs meer dan duizend links is een slechte ervaring voor je bezoekers (plus een zware belasting voor je cms, dat hiervoor uitgebreide selecties moet uitvoeren). Maar ook daar valt prima iets aan te doen. Allereerst een redactionele ingreep: maak tussenkopjes, bijvoorbeeld om de maanden aan te geven. Dan kunnen bezoekers gerichter in een bepaalde periode zoeken. Bijvoorbeeld alleen de laatste drie maanden. Of alleen het voorjaar van 2005.

Zelfs met tussenkopjes blijft die overzichtspagina nog heel lang. Een tweede ingreep is meer technisch van aard: maak al die tussenkopjes in- en uitvouwbaar. Een voorbeeld is dit nieuwsoverzicht op Klimaatnieuws.nl:

Als je een specifieke maand zoekt, hoef je alleen maar die maand uit te vouwen (onderstaand plaatje is niet klikbaar, ga daarvoor naar Klimaatnieuws.nl):

En als je in een langere periode zoekt, kun je álle maanden uit het hele overzicht in één keer uitvouwen. Op internet zijn veel scripts te vinden voor dit soort uitvouwsystemen, zoek daarvoor op ‘folding menu’. Ze zijn zo gemaakt dat zoekmachines feitelijk alleen maar uitgevouwen maanden zien en dus ook alle nieuwsberichten probleemloos zullen vinden.

Hoe het nóg beter kan: inhoudelijk linken

Niet alle hyperlinks zijn gelijk voor Google. Een link naar een andere pagina met soortgelijke inhoud telt zwaarder dan een link naar een pagina over een heel ander onderwerp. Hoe meer relevante links, hoe beter je reputatie in Google.

Hoe groter je nieuwsarchief, hoe meer raakvlakken er ontstaan tussen al die nieuwsberichten. Daarom: zorg ervoor dat die naar elkaar linken. Niet alleen voor Google, maar ook voor bezoekers is dat prettig. Als die bezoekers vanuit een externe site rechtstreeks op een nieuwsbericht op jouw site uitkomen, dan maak je het ze makkelijk door ze direct te verwijzen naar soortgelijke berichten. Hoeven ze niet je hele nieuwsarchief door te spitten.

Doelgericht hyperlinks aanbrengen tussen nieuwsberichten is wel heel arbeidsintensief. Eigenlijk zou je dit al moeten doen tijdens het schrijven van een nieuwsbericht, niet pas achteraf. Gelukkig zijn er foefjes om een bestaand archief achteraf te verrijken met inhoudelijke links. Bij veel nieuwsberichten zie je bijvoorbeeld onderaan een rijtje gerelateerde berichten. Zoiets als:

In veel contentmanagementsystemen kunnen deze gerelateerde links automatisch worden gegenereerd. Bij WordPress heb ik goede ervaringen met de plugin YARPP (Yet Another Related Posts Plugin). Deze plugin beoordeelt op basis van titelwoorden, categorieën, trefwoorden en andere kenmerken in hoeverre twee nieuwsberichten met elkaar verwant zijn.

Er is een nadeel aan dit soort plugins: ze zijn slecht voor de performance van je site. In principe moet voor elk nieuwsbericht een ingewikkelde zoekselectie op de rest van het archief worden uitgevoerd. Dat hakt erin, uit eigen metingen op deze site bleek de gemiddelde laadtijd per nieuwspagina met 45% toe te nemen.

Ik raad daarom aan om zo’n plugin alleen toe te passen in combinatie met caching. Dat houdt in dat die ingewikkelde zoekselectie niet elke keer opnieuw wordt uitgevoerd, maar alleen op gezette tijden, bijvoorbeeld eens per uur, eens per dag of nog minder vaak. Hoe je caching moet toepassen? Dat hangt af van je contentmanagementsysteem. Vaak heeft zo’n systeem kant-en-klare caching-modules.

En nog een kleine tip, maar met grote gevolgen. Bij een plugin als YARPP kun je kiezen of de gerelateerde berichten onderaan een nieuwsbericht altijd ouder zijn, of ook van recenter datum kunnen zijn. Met andere woorden: mag een nieuwsbericht ook verwijzen naar andere berichten die later zijn gepubliceerd?

Mijn advies: kies altijd het laatste, want dan wordt de pagerank van Google gelijkmatiger over je nieuwsarchief uitgesmeerd. Kies je voor alleen linken naar oudere berichten, dan krijgen de alleroudste berichten uit je archief relatief de meeste pagerank, terwijl je je bezoekers misschien juist liever wat meer actuele nieuwsberichten zou laten lezen.

Dus: mocht de performance er niet onder lijden, dan heb je met het toevoegen van gerelateerde berichten een snelle manier om een nieuwsarchief inhoudelijk te verrijken. Daar worden zowel Google als bezoekers blij van.

Nog even recapituleren

Er zijn talloze manieren om een grote verzameling oude nieuwsberichten beter toegankelijk te maken voor bezoekers én beter vindbaar voor Google, maar paginering is zo ongeveer de allerslechtste.

Mijn twee favoriete methoden om het beter te doen heb ik hierboven beschreven:

• een simpel totaaloverzicht (waar je eventueel een in-/uitvouwmogelijkheid aan kunt toevoegen),
• inhoudelijke links aanbrengen (al of niet geautomatiseerd) tussen verwante berichten.

Natuurlijk zijn er nog meer manieren te bedenken voor een betere structuur. Gebruik je zelf een andere methode, dan ben je welkom om dat hieronder te melden!

Wie zich verdiept in de wereld van open-source contentmanagementsystemen, komt al snel bekende namen als WordPress, Joomla, Drupal en TYPO3 tegen. Vooral Drupal en TYPO3 worden vaak toegepast voor het wat steviger werk, bijvoorbeeld sites met veel subsites, met allerlei web 2.0-achtige toepassingen en met koppelingen met externe systemen. Tot op zekere hoogte worden ze voor dezelfde soort websites ingezet, maar ze zijn totaal verschillend. Welk systeem moet je kiezen? Met zowel TYPO3 als Drupal heb ik nu ruim een jaar praktijkervaring, allebei in de omroepwereld, respectievelijk bij VARA en NCRV. Hieronder mijn bevindingen als webontwikkelaar.

Lees gewoon verder, of gebruik de inhoudsopgave links om alleen specifieke vergelijkingspunten te lezen.

Wat Drupal en TYPO3 gemeen hebben

Eerst wat basisbegrippen en de belangrijkste overeenkomsten. Drupal en TYPO3 zijn allebei PHP/MySQL-toepassingen die je op een eigen webserver kunt installeren. De kale versies (core) van beide systemen bieden al heel veel standaardfunctionaliteit, maar voor speciale doeleinden kun je nog extra aanvullende modules installeren, bij TYPO3 heten deze extensies. Beide contentmanagementsystemen hebben een back-end waarin redacteuren en beheerders kunnen inloggen voor hun dagelijkse werkzaamheden.

Drupal en TYPO3 hebben allebei een community van ontwikkelaars en gebruikers die zich inzetten voor de verdere ontwikkeling. Regelmatig verschijnen nieuwe updates van zowel core als modules/extensies. Meestal gaat het om nieuwe features en bugfixes, soms om reparatie van veiligheidslekken.

Gebruiksvriendelijkheid voor redacteuren

Het succes van een contentmanagementsysteem (cms) binnen een organisatie wordt voor een aanzienlijk deel bepaald door het draagvlak onder redacteuren. Zij werken er immers het meeste mee. Daarom behandel ik dit punt bewust als eerste. En op dit punt scoort Drupal duidelijk beter dan TYPO3. Webredacteuren die met Drupal werken heb ik eigenlijk nooit horen klagen dat het van nature een te ingewikkeld systeem zou zijn, integendeel. Stagiaires kunnen er al vrij snel mee aan de slag, zonder dat een ontwikkelaar ze voortdurend te hulp moet schieten.

De TYPO3-interface is daarentegen veel minder intuïtief, ik heb weleens scheldpartijen van gefrustreerde webredacteuren moeten aanhoren. Vaak verwijzen ze naar het immens populaire WordPress, een pakket waarmee steeds meer redacteuren ervaring hebben. Hoewel WordPress niet geschikt is voor het grote werk, zie je heel duidelijk dat WordPress qua gebruiksvriendelijkheid steeds meer de meetlat wordt waarlangs anders cms’en worden gelegd. En dan komt TYPO3 er niet zo best van af.

Een dikke plus dus voor Drupal. Toch zijn hierbij twee nuances op hun plaats. Allereerst is er in 2010 een nieuwe TYPO3-release verschenen (4.4) met een sterk verbeterde interface. TYPO3 probeert dus een inhaalslag te maken, goede zaak.

Daarnaast heeft TYPO3 een nuttige feature die van levensbelang kan zijn voor webredacteuren: de mogelijkheid om redactionele bewerkingen ongedaan te maken en verwijderde items uit een virtuele prullenbak terug te halen. In Drupal heb ik weleens gezocht naar dergelijke functionaliteit, maar wat ik vond was veel simpeler en lang niet full-proof. En tja, en als het een keer flink misgaat, dan blijft er nog maar één redmiddel over: in allerijl een databasebackup terugzetten.

Architectuur: inhoudstypes

Dit vind ik duidelijk een van de sterkste punten van Drupal. Dankzij de Drupal-module CCK (Content Construction Kit) kun je alle inhoudstypes (pagina’s, nieuwsberichten, adressen, gebruikers, vul zelf maar aan) via de back-end helemaal zelf configureren. Per inhoudstype kun je onbeperkt velden toevoegen en per veld het datatype (tekst, getal, plaatje, enzovoorts) specificeren. CCK is zó standaard geworden in Drupal dat vrijwel alle andere modules er goed mee samenwerken.

In TYPO3 is het ook wel mogelijk om je eigen inhoudstypes op maat te maken, maar dat ging altijd veel omslachtiger. Vaak zie je hierbij de TYPO3-extensie tt_news opduiken: aanvankelijk bedoeld voor nieuwsberichten, maar gaandeweg gebruikt voor van alles en nog wat, bijvoorbeeld om er portfolio-items in te zetten.

Een andere mogelijkheid is om voor specifieke inhoudstypes een aparte TYPO3-extensie te maken. Het werkt allemaal, maar uit oogpunt van transparantie, van integratie in andere modules en van slagvaardig debuggen geef ik toch de voorkeur aan de back-end als dé plek om inhoudstypes te definiëren en te beheren – dus zoals Drupal dat doet.

Heb je in Drupal eenmaal je eigen inhoudstypes gedefinieerd, dan kun je met de Views-module bepalen hoe ze op het scherm worden getoond. In essentie is Views niets anders dan een interface om query’s op je eigen inhoudstypes te specificeren. MySQL-kenners zullen juichen bij het lezen van de vorige zin.

Architectuur: taxonomieën

Drupal heeft nog een geweldige ingebouwde feature: taxonomieën. Net als CCK en Views is deze functionaliteit zo ingeburgerd dat talloze andere modules er vrijwel probleemloos mee samenwerken.

Dankzij taxonomieën heeft Drupal mijn manier van websites bouwen fundamenteel veranderd. Waar ik nu standaard mee begin, is eerst een of meer taxonomieën aanmaken en die koppelen aan de belangrijkste navigatiemenu’s. Daarna bekijk ik per taxonomie welke inhoudstypes erbij moeten komen en per inhoudstype welke datavelden erin moeten zitten.

In feite is dit de top-down benadering van een informatiearchitect. Vroeger werkte ik veel meer bottom-up: eerst inhoudstypes maken en dan pas kijken hoe je die content met rubrieken en tags inhoudelijk kunt ontsluiten en integreren in ander delen van de toekomstige site.

Architectuur: TYPO3-boomstructuur

TYPO3 heeft een volstrekt andere architectuur dan Drupal, die pakweg evenveel verschilt als de Chinese met de Engelse taal. De kern is een boomstructuur, waaraan je vrijwel alles kunt hangen: statische pagina’s, nieuwsitems, templates, geregistreerde gebruikers, gebruikersrechten, noem maar op.

In het begin heb ik erg moeten wennen aan dit concept. Die boom doet weliswaar denken aan een soort sitemap voor bezoekers van de site, maar deze vergelijking gaat al vrij snel mank. Nieuwsitems bijvoorbeeld: de detailpagina van een nieuwsitem hang je niet apart in de boom, maar alle nieuwsitem samen stop je samen in een storage-map, die je heel ergens anders in de boomstructuur kunt plaatsen. Ook kun je bepaalde zijtakken van de boom exclusief gebruiken voor templates, storagemappen en gebruikersgegevens.

Uiteindelijk is de TYPO3-boomstructuur dus een soort mengvorm van een sitemap voor redacteuren en een opbergsysteem voor ontwikkelaars en beheerders. Overzichtelijk en eenduidig is anders, maar ik moet ook wel weer toegeven: heb je het nogal abstracte principe van de boomstructuur eenmaal in je vingers, dan heb je genoeg bagage om ook complexe TYPO3-sites in betrekkelijk korte tijd te doorgronden.

Architectuur: domeinen

Bij TYPO3 en Drupal is het allebei mogelijk om content vanuit één installatie over verschillende domeinen en subdomeinen te serveren. Dit is een heel sterk punt van TYPO3: je kunt aan elk punt in de TYPO3-boomstructuur een domeinrecord hangen, zodat de onderliggende takken toegankelijk zijn via dat domein. Bij Drupal moet je hiervoor aparte modules inschakelen, en ik heb gemerkt dat de integratie met andere modules lang niet altijd perfect is – glad ijs dus.

Ontwikkeling: Typoscript

Iedere TYPO3-ontwikkelaar en -beheerder krijgt vroeg of laat te maken met Typoscript. Aanvankelijk was Typoscript bedoeld als een simpel XML-achtig configuratietaaltje voor webdesigners die niet met PHP kunnen of willen werken. In de loop der jaren is deze scriptingtaal echter zo complex geworden (met name door stdWrap) dat de mogelijkheden veel en veel verder reiken en er hele boeken over zijn verschenen.

Met Typoscript heb ik altijd een haat-liefdeverhouding gehad. In het gunstigste geval kun je met Typoscript dingen voor elkaar krijgen zonder nieuwe TYPO3-extensies te bouwen of bestaande extensies aan te passen. In het ongunstigste geval wordt Typoscript te veel gebruikt als onnodige vervanging van PHP-code. Het gevolg: honderden regels Typoscript-code, die door zijn sterk afwijkende, niet-sequentiële manier van abstraheren veel moeilijker te doorgronden is dan hetzelfde aantal PHP-regels. Typoscript vond ik bovendien altijd lastig te debuggen, bij mijn weten zijn daar geen goede tools voor zoals bij PHP. Typoscript is ook nog veel zwijgzamer dan PHP als het gaat om errors en warnings.

Ontwikkeling: modules/extensies en complexiteit

Drupal noemt ze modules, TYPO3 noemt ze extensies, maar het gaat om hetzelfde: extra bouwstenen die je optioneel kunt installeren. Vanuit de community worden er al duizenden aangedragen, waarvan een groot deel van uitstekende kwaliteit. Daarnaast bestaat natuurlijk altijd de mogelijkheid om zelf nieuwe modules te ontwikkelen – en bij voorkeur later weer terug te geven aan de community.

Zelf heb ik geen praktijkervaring met het bouwen van TYPO3-extensies, wel met het debuggen en aanpassen van Drupal-modules. Drupal werkt met hooks: functies die bestaande functionaliteit in de Drupal-core veranderen of uitbreiden. Dat lijkt heel overzichtelijk, maar ergens is er toch wel een grens. Als je lang doorgaat met extra modules installeren, bereik je naar mijn gevoel bij Drupal eerder een omslagpunt dan bij TYPO3. Dat omslagpunt uit zich in de vorm van niet gemakkelijk op te lossen bugs en performanceproblemen.

Ik ben er nog niet achter waar ‘m dat precies in zit. Mogelijk dat de vrij horizontale Drupal-architectuur ervoor zorgt dat er meer afhankelijkheden ontstaan in een complexe website. Interessant leesvoer wat dit betreft is The problem of Drupals exponential complexity van Bèr Kessels.

De boomstructuur van TYPO3 – hoe warrig ook voor redacteuren en beginnende ontwikkelaars – lijkt uiteindelijk toch beter te schalen. Het is prima mogelijk om extensies alleen aan relevante delen van een website te hangen, wat interferentie en afhankelijkheden tussen extensies een stuk zou kunnen beperken.

Ontwikkeling: documentatie

Hier kan ik kort over zijn: zowel bij Drupal als bij TYPO3 is die goed. Er zijn handleidingen voor beginners en gevorderden op internet te vinden, en ook in boekvorm. Wel merk ik in de praktijk dat als je met specifieke probleempjes zit, je bij Drupal meer kans hebt om bruikbare oplossingen te vinden dan bij TYPO3, simpelweg doordat Drupal wereldwijd meer gebruikers heeft en er meer over geblogd wordt.

Ontwikkeling: zoeken

TYPO3 en Drupal hebben allebei out-of-the-box een zoekmogelijkheid. Bij TYPO3 is die slecht schaalbaar, bij sites van meer dan een paar honderd webpagina’s is die al merkbaar traag. De standaardzoeker van Drupal doet het iets beter, maar ook die raad ik niet aan voor complexe sites.

De oplossing in beide gevallen is integratie met externe zoekoplossingen. Bij TYPO3 is mnoGoSearch een veelgebruikte oplossing; bij Drupal heb ik goede ervaringen met Apache SOLR.

Ontwikkeling/beheer: OTAP

Het is vanzelfsprekend dat je nieuwe functionaliteit eerst ontwikkelt en test, alvorens die live te zetten. Vaak wordt hierbij het OTAP-model aangehouden: Ontwikkel, Test, Acceptatie, Productie.

Deze stapsgewijze werkwijze impliceert dat je af en toe nieuwe code moet overzetten naar een andere omgeving. Dat klinkt eenvoudig, maar de praktijk valt tegen. Drupal- en TYPO3-websites bestaan allebei voor een deel uit statische bestanden (PHP, templates, CSS) en voor een deel uit configuratie die in de MySQL-database wordt opgeslagen.

De statische bestanden zijn simpel over te zetten (al of niet met een versiebeheersysteem als SVN), maar de configuratie is lastiger. Als je een hele database overzet vanuit Ontwikkel, Test of Acceptatie naar Productie, dan wordt de bestaande redactionele content in de productieomgeving overschreven. Je moet dus maar een klein stukje van de database overzetten. In praktijk werkt het vaak het snelst door de configuratie op Productie handmatig opnieuw door te voeren. Met het risico dat je daarbij fouten maakt.

TYPO3 heeft daarbij nog een extra complicatie: in Typoscript wordt vaak verwezen naar specifieke knooppunten in de boomstructuur. TYPO3 doet dat met automatisch gegenereerde id’s. Maar pagina’s met redactionele content gebruiken ook die id’s. Het gevolg: als je een al bestaande site op Productie terugkopieert naar Ontwikkel om nieuwe features te ontwikkelen, dan gaan ontwikkelaars op Ontwikkel en redacteuren op Productie onbedoeld dezelfde id’s gebruiken. Bij het overzetten van ontwikkelwerk naar Productie moet je dus alle id’s langslopen en zonodig hernummeren.

Enfin, ik kan me voorstellen dat dit verhaal over id’s erg gedetailleerd wordt. Wat ik maar wil zeggen: Drupal en TYPO3 zijn allebei niet ideaal qua OTAP, waarbij Drupal net iets minder problematisch is. Overigens weet ik niet of TYPO3 op dit punt in het afgelopen jaar veel is veranderd. Als je als TYPO3-ontwikkelaar hier iets meer over weet, dan ben je welkom dat onderaan te melden bij de reacties.

Beheer: performance

Bij elke PHP/MySQL-toepassing zie je hetzelfde beeld: hoe meer bezoekers er komen, hoe trager je site wordt. Vaak is MySQL de bottleneck. Zowel bij Drupal als bij TYPO3 heb ik gezien dat het aantal database-query’s voor de homepage van een portaalsite kan oplopen tot tussen de 500 en 1000. Voor één pagina!

Caching is dus noodzakelijk en bij beide cms’en kunnen diverse cachingtechnieken voorhanden die veel performancewinst kunnen opleveren. In die zin is er dus nauwelijks verschil.

Beheer: security

In beide systemen worden weleens veiligheidslekken ontdekt, waarna onder regie van het Drupal Security Team of het TYPO3 Security Team een nieuwe versie van de core of van een specifieke module/extensie wordt uitgebracht. In frequentie en ernst van gevonden problemen zie ik geen wezenlijk verschil tussen Drupal en TYPO3.

Beheer: upgraden

Hier scoort TYPO3 veel beter. Gemiddels eens per twee jaar verschijnt een major release van Drupal. Als ik deze woorden tik, staat versie 7.0 op het punt van verschijnen. Major releases van Drupal brengen altijd ingrijpende veranderingen met zich mee. Zelf heb ik een keer een relatief eenvoudige Drupal-site geüpgrade van 5 naar 6. Daar was ik dagen mee bezig, vooral omdat enkele Drupal 5-modules niet meer in 6 werkten en daarvoor andere oplossingen moesten worden gezocht.

Upgraden bij TYPO3 geeft veel minder kopzorgen. De enige nieuwe major release die ik ooit bij TYPO3 heb meegemaakt, versie 4.0, gaf betrekkelijk weinig problemen.

Front-end: zelf themen

Drupal en TYPO3 zijn beide van nature meer georiënteerd op back-end webontwikkelaars, minder op themers. In beide systemen is theming een vak apart. HTML en CSS zijn vaak verspreid over templates, modules en configuratie in de back-end. Het is vaak lastig om ‘even’ iets aan te passen.

In de praktijk merk ik dat dat met Drupal wel wat sneller gaat dan bij TYPO3. Net als bij WordPress werk je bij Drupal met HTML-templates waar je PHP-functies in kunt stoppen. Vooral als je ervaring hebt met WordPress, zul je Drupal-theming veel sneller oppikken dan TYPO3-theming.

Aan de andere kant heeft Drupal een euvel dat TYPO3 weer niet heeft: de naar mijn smaak nogal doorgeslagen neiging om werkelijk overal ‘classes’ en ‘divs’ in te voegen – in Drupal word je soms tureluurs van de overmaat aan CSS.

Front-end: kant-en-klare themes

WordPress-gebruikers worden verwend met een overvloed aan kant-en-klare themes – deels gratis, deels voor een bescheiden bedrag te koop. Het laatste jaar zie ik steeds meer van die themes overgezet worden naar Drupal, al blijft Drupal sterk achterlopen.

Voor TYPO3 is het aanbod aan goede themes helemaal erg beperkt. Als je voor TYPO3 kiest, is de kans dus groot dat je zelf moet gaan themen, of dat deel van de ontwikkeling uitbesteden.

Community

Via mailinglijsten, forums en gebruikersdagen volg ik de community’s van WordPress, Joomla, Movable Type, TYPO3 en Drupal op de voet. Die van Drupal vind ik het plezierigst en meest gastvrij, met WordPress als goede tweede. Vooral op de halfjaarlijkse Drupal-conferenties (DrupalCon) ervaar ik een schwung die ik zelden elders meemaak in de ict-wereld, zie bijvoorbeeld mijn ervaringen met DrupalCon 2009 in Parijs.

Conclusie

De goede verstaander zal het wel hebben begrepen: ik ben zelf meer fan van Drupal dan van TYPO3. Vooral de gebruiksvriendelijkheid voor redacteuren, de elegante architectuur van Drupal en de enthousiaste community hebben mijn hart gestolen. Als voormalig TYPO3-ontwikkelaar heb ik de nogal spartaanse interface en het schrijven en debuggen van Typoscript als de grootste struikelblokken ervaren.

Daarmee wil ik beslist niet zeggen dat TYPO3 in zijn algemeenheid een inferieur systeem is. Als het gaat om complexe portaalsites met content op verschillende (sub)domeinen, denk ik zelfs dat TYPO3 een meer solide oplossing biedt dan Drupal. De toekomst van TYPO3 zie ik daarom vooral als ontwikkelframework voor high-end toepassingen, minder als cms. De TYPO3-community werkt zelf al geruime tijd aan zo’n framework: Flow3. Zonder meer een interessante ontwikkeling.

Maar voor verreweg de meeste websites zal zo’n geavanceerd framework niet nodig zijn. Heb je een middelgrote website in gedachten? Met maar één domein? Eventueel met community? Of web 2.0-toepassingen? Dan lijkt Drupal me het aangewezen cms.

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.

• een totaal vernieuwde gebruikersinterface,
• een nieuwe WYSIWIG-editor,
• nieuwe import/export- en backup/restore-functies,
• een blogdashboard met statistieken,
• OpenID-ondersteuning,
• installatiewizard,
• ondersteuning voor losse pagina’s,
• ingebouwd asset-management voor het beheer van opgeladen bestanden en foto’s

En nog belangrijker nieuws: Movable Type wordt open-source. Dat kan ik alleen maar toejuichen, want eerder schreef ik nog over het vage Mambo-achtige tweesporenbeleid van Six Apart: een beetje commercieel, een beetje open-source. Het lijkt erop dat Six Apart voor het overweldigende succes van WordPress door de knieën gaat en niet alleen WordPress-achtige features introduceert, maar ook definitief kiest voor een open-source aanpak.

Enkele weken geleden schreef ik nog over een weeffout in WordPress, namelijk gratis themes waarin stukjes (mogelijk onveilige) PHP-scripting voorkomen. Als de nieuwe MT-versie inderdaad zo’n grote stap voorwaarts is, dan is de keuze voor mij duidelijk: dan blijf ik voor mijn belangrijkste sites voorlopig Movable Type gebruiken.

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 enthousiasme 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.

Met webwinkels heb ik nauwelijks ervaring, dus een pasklaar antwoord kan ik niet geven – wel een paar criteria bij de selectieprocedure. Net vanochtend lees ik op de site ECommerce-Guide een korte bespreking van Five Free Open Source Shopping Carts: osCommerce, Zen Shopping Cart, Agora Shopping Cart, NoPCart en Commerce.Cgi.

De enthousiaste conclusie: ook voor commerciële activiteiten op internet kun je prima volstaan met open-source oplossingen. Dat klinkt leuk, maar een voor Nederlandse websites belangrijke vraag wordt er niet in beantwoord, namelijk: zijn deze winkelwagensystemen ook beschikbaar in andere talen dan Engels?

In Nederland heb je bovendien te maken met specifieke wettelijke bepalingen, zoals de Wet koop op afstand. Of deze pakketten daaraan (kunnen) voldoen, wordt eveneens niet direct duidelijk.

Dan maar alle vijf uitproberen? Dat hoeft gelukkig niet. Als je op de namen van deze winkelsystemen zoekt binnen het Nederlandse deel van internet, dan valt direct op dat NoPCart bij ons totaal onbekend is. Zen Shopping Cart en Commerce.Cgi worden al wat vaker gebruikt, maar het populairst bij ons blijken Agora Shopping Cart en osCommerce.

Agora Shopping Cart heeft als groot voordeel dat het standaard is opgenomen in Fantastico, een verzameling van enkele tientallen gratis programma’s waarover je vaak gratis kunt beschikken bij hostingprovider die cPanel aanbieden als beheersinterface voor hun klanten. Alle Fantastico-programma’s, dus ook Agora, zijn met slechts een paar muisklikken te installeren via het cPanel-menu. Dat is handig voor onervaren webmasters.

Op mij maakt osCommerce de beste indruk, want deze oplossing heeft een Nederlandse gebruikersgroep, de osCommerce Nederland. Dan is er in ieder geval ondersteuning in Nederland, en met de Nederlandse vertaling en de wettelijke randvoorwaarden zal het vermoedelijk ook wel oké zijn.

Een volgend selectiecriterium: hoe moeten de klanten betalen? Kunnen ze dat bijvoorbeeld ook met iDeal doen, een veelbelovend betaalsysteem dat volgens een recente peiling op www.computertotaal.nl al door 40 procent van de Nederlandse internetgebruikers wordt gebruikt? Daar is snel achter te komen met een handige zoekactie, bijvoorbeeld oscommerce ideal.

En een laatste criterium: zijn deze pakketten te integreren in open-source contentmanagementsystemen (Joomla, Typo3, Textpattern) en weblogs (WordPress, Movable Type)? Ook dit is een kwestie van handig googelen. En anders kun je altijd nog de betreffende website uitpluizen, de lijst van features goed bekijken en het supportforum doornemen.

Wat ik maar wil zeggen: aan de hand van een paar praktische criteria is het enorme aanbod van open-source oplossingen in een kwartiertje tijd snel uit te dunnen tot een of twee kansrijke kandidaten. De volgende stap: downloaden en gewoon maar uitproberen.