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.

Presentaties

Van bijna elke presentatie zijn video-opnamen gemaakt. De organisatie heeft beloofd die video’s online te zetten. Zodra dat is gebeurd, zal ik de links toevoegen in onderstaand overzicht.

45 Modules in 45 Minutes – the Best Modules You’re Not Using

Iedere Drupal-ontwikkelaar kent CCK en Views, maar in deze sessies passeerden 45 andere modules de revue die veel minder bekend zijn, maar toch de moeite waard. Better Messages, HTML Purifier, Image Resize Filter, Table Wizard, Persistent Login, Automated Logout, Taxonomy Breadcrumb, Taxonomy Image – ik kende ze allemaal nog niet, maar sommige ga ik zeker gebruiken.
» presentatie en videobeelden: drupaleasy.com/45

Sustainable theming: how to take a vacation

Een vlotte lezing waarin het belang van duurzame CSS werd uitgelegd, zodat je naderhand gemakkelijker dingen kunt aanpassen of uitbreiden. Natuurlijk een behartenswaardig onderwerp, alleen bleef het allemaal nogal abstract bij gebrek aan concrete voorbeelden van duurzame en niet-duurzame CSS.
» presentatie: www.slideshare.net/caroltron/sustainable-theming

Geo tools for Drupal

Als liefhebber van wandelen kijk ik reikhalzend uit naar alle ontwikkelingen die met GIS te maken hebben. In de Drupal-community wordt volop gewerkt aan koppelingen met GIS-servers en mashups, waarvan in deze sessie verslag werd gedaan. Een bijzonder interessante ontwikkeling, zij het tot nu toe nog zonder veel zichtbare resultaten.

Basics of making a mobile website with Drupal

Wat mij betreft een van de beste presentaties van de hele conferentie. Tom Deryckere van Siruna behandelde eerst de algemene principes van mobiele websites, zoals navigatie, tools en valkuilen. Daarna liet hij een veelbelovende nieuwe tool van Siruna zien om websites te vertalen naar mobiele platforms.
» presentatie: www.mobiledrupal.com/content/slides-presentation-mobile-drupal-drupal-camp-colorado (van een eerdere conferentie, maar ogenschijnlijk dezelfde presentatie)
» promotiefilmpje: www.siruna.com/our-technology-platform (is nog in bèta).

Drupal for Media + Edipresse Success Story

Een sessie over de introductie van Drupal bij het Zwitserse uitgeefconcern Edipresse. Daarbij viel vooral op hoe snel ze het allemaal voor elkaar kregen, mede dankzij de Agile-ontwikkelmethodiek en slim hergebruik van HTML/CSS-templates. De verschillen tussen adverteren in print en op internet werden nogal breed uitgemeten. Ja, het is moeilijk om met een nieuwssite geld te verdienen. Ja, traditionele adverteerders geven voor kranten en tijdschriften meer geld uit dan voor websites. Maar dat wisten we tien jaar geleden toch allemaal al?
» presentatie (gedeeltelijk): www.slideshare.net/pjduvivier/drupal-experience-at-edipresse-media-company

Social + Media: What We Need Next

Een geanimeerde keynote speech van Chris Heuer over social media. Niet dat ik me heb verveeld, maar anderhalve week later is me eigenlijk maar één ding van zijn betoog bijgebleven en dat is dat bedrijven vooral als media moeten gaan denken. Eigenlijk wel grappig, want in de vorige sessie over Edipresse was de ondertoon juist tegengesteld: media moesten daar vooral als bedrijven gaan denken.

Transforming The Economist Online using Drupal, open-source and Scrum

Deze vlag dekte de lading precies. De invoering van Drupal bij The Economist was niet alleen de overgang op een andere techniek, maar ook op een andere filosofie (open-source) en andere ontwikkelmethodiek (Scrum). Zelf heb ik nog geen ervaring met Agile en Scrum, maar ik zie duidelijk voordelen ten opzichte van de traditionele watervalmethode (ook enkele nadelen overigens).
» samenvatting: http://paris2009.drupalcon.org/session/transforming-economist-online-using-drupal-open-source-and-scrum

Make a Module: A Hands-on Intro to Module Development

Een spoedcursus Drupal-modules bouwen. Duidelijk verhaal, voor mij erg leerzaam.

How To: Install, Upgrade, Backup, & Migrate

In deze sessie zag ik vooral heel veel scripting voorbij komen. Plus één markante uitspraak onthouden: dat het upgraden van n aparte Drupal-installaties soms sneller gaat dan één grote multisite-installatie waar alle n websites op draaien, terwijl je juist het omgekeerde zou verwachten.
» presentatie: drupaladmin.net/paris

Drupal Ingredients for your Website Dish, or Modules You Should Use on Every Site

Nog een bloemlezing van leuke Drupal-modules, je zou er wel vijf sessies mee kunnen vullen.
» presentatie: docs.google.com/present/view?id=dcv55663_82d9m66bdz

Agile Drupal Development with Scrum

Agile en Scrum werden al in andere lezingen genoemd en geroemd. Hier werd er wat uitgebreider op ingegaan wat ze precies behelzen. Een goed-gestructureerde presentatie.

Understanding Drupal 6 Themes

Het afgelopen halfjaar heb ik veel gestoeid met theming in Drupal. Toch maar een kijkje nemen, dacht ik, wie weet leer ik nog wat nieuws. De sessie duurde echter maar 20 minuten: 15 minuten om de basisprincipes uit te leggen en 5 minuten voor wat vraagjes uit de zaal. Dus nog ruim een half uur over om leerzame praktijkvoorbeelden te geven? Nee, de sessie bleek afgelopen.
» presentatie: docs.google.com/present/view?id=0AUvHZLXzMJuBZGZrc3B2NzdfNmdxNDRmemNy&hl=en

Semantic Web fundamentals

Een keynote speech van Dan Brickley, deskundig op het gebied van W3C-webstandaarden. Deze presentatie ging over de toekomst van het web, met voor mij (ooit mijn loopbaan begonnen op een wetenschappelijke bibliotheek) een eyeopener: Brickley strooide met termen die al tientallen jaren in de bibliotheekwereld in zwang zijn, zoals thesauri, taxonomieën, Dublin Core, enzovoorts. Door de komst van het web en Google in het bijzonder zijn bibliotheken door veel mensen overbodig verklaard, maar na zo’n lezing lijkt het wel alsof juist deze ogenschijnlijk stoffige beroepsgroep mede de sleutel in handen heeft tot de toekomst van het web. Een fascinerende gedachte die mij de rest van de dag niet heeft losgelaten.

jQuery for designers and themers

Voor mij is jQuery niet nieuw, maar op deze sessie zag ik toch weer leuke nieuwe voorbeelden. De spreker nam in ieder geval de moeite om vanuit een praktijkvoorbeeld te werken en na elke aanpassing direct het effect te laten zien. jQuery UI, gebaseerd op jQuery, komt in de core van Drupal 7.
» presentatie: docs.google.com/present/view?id=drmcbw4_1816qv2fkc7

Building blocks for your module’s UI

Hier kregen Drupal-modulebouwers tips en best practices voorgeschoteld hoe je een prettige interface maakt voor je nieuwe Drupal-module. In algemene zin valt het mij op dat de Drupal-gemeenschap veel aandacht besteedt aan een gebruiksvriendelijke backend.

Welcome to the Jungle! Basic Drupal Recipes and Best Practices for Beginners

Een razendsnelle Drupal-introductie voor absolute beginners, eigenlijk meer gericht op ‘power users’ dan op ontwikkelaars. De beste tip van de hele sessie, en misschien wel van de hele conferentie: maak eerst een uitgewerkte schets op papier van wat je wilt gaan bouwen.

Sharing content across multiple sites with Domain Access

Ik ben nog te kort bezig met Drupal om alle ins en outs van deze presentatie te doorgronden. Maar het feit dat er meer dan tien Drupal-modules voorbijkwamen, plus nog wat PHP-code om bijvoorbeeld cookies te zetten, doet mij desondanks concluderen dat een ander open-source cms als Typo3 op dit specifieke punt veel eleganter in elkaar steekt. Anderzijds heeft Drupal op andere punten ook weer grote voordelen ten opzichte van Typo3. Op de verschillen tussen Drupal en Typo3 wil ik later in een aparte blogpost terugkomen.

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

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.