Drupal versus TYPO3: een vergelijking

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.