Hoe het begon: Moodle 1.8 en een platform dat zichzelf nog zocht
Toen Ldesign Media in 2010 voor het eerst startte met Moodle-ontwikkeling, draaiden we op versie 1.8. Het platform was krachtig, maar voelde nog duidelijk ruw aan: sterk admin- en formuliergedreven, en extensies leunden zwaar op vaste entry points en callbacks. Tegelijk was Moodle toen al duidelijk modulair opgezet, met plugin-types zoals activity modules, blocks, themes, auth- en enrolment plugins, elk met vaste entry points zoals lib.php. De gebruikelijke pluginstructuur met bestanden als db/install.xml, db/upgrade.php en version.php was er in de praktijk al, al verschilde de precieze verplichting per plugintype en oudere Moodle-versie.
Moodle 1.8 deed precies wat het beloofde: het was een cursusbeheersysteem, gebouwd door docenten, voor docenten. Het kon quizzen, opdrachten, forums en cijferboeken aan. Voor Dentallect, een van onze eerste grote klanten, was dat genoeg. Ze hadden een platform nodig waar tandheelkundige professionals na- en bijscholing konden afronden en waar die voltooiingen werden bijgehouden. Moodle 1.8 leverde dat, ook al vergde het er professioneel en zakelijk uit laten zien heel wat maatwerk-PHP dat we vandaag de dag niet meer zouden schrijven.
Wat we al snel leerden: de Moodle-community was het echte product. De forums op moodle.org waren al actief, de tracker vulde zich al met bugs en feature-aanvragen, en rond het project van Martin Dougiamas was een wereldwijde groep ontwikkelaars, docenten en vertalers ontstaan die vanuit eigen beweging bijdroegen omdat ze oprecht geloofden in open-source onderwijs.
Moodle 2.0: de grote backend-herschrijving (2010-2011)
Moodle 2.0, uitgebracht op 24 november 2010, voelde terecht als een breuklijn. Die release bracht grote veranderingen in repository support, de file picker, file metadata en opslag, web services door de hele codebase, cohorts, course completion en prerequisites, conditional activities, en een volledig herschreven backup/restore-laag. Voor teams met veel maatwerk voelde dat in de praktijk als een bijna nieuw platform.
Voor plugin-ontwikkelaars was dit keihard. Elke plugin die we hadden gebouwd of aangepast, en in 2010 hadden we er al tientallen, moest worden herschreven. De hook-namen veranderden, de functiehandtekeningen veranderden, de conventies rond bestandsafhandeling en output veranderden. Wat 2.0 níet deed, is het plugin-installatie- en upgrademechanisme vanaf nul uitvinden. Het XMLDB-gebaseerde model met install.xml en upgrade.php bestond al sinds Moodle 1.7, en ook het rollen- en capability-model bestond al vóór 2.0. Moodle bleef daarna nog lang sterk transaction-script-, lib.php- en callback-gedreven; het moderne Events API kwam pas in 2.6.
De installaties met zwaar maatwerk, vooral die met aangepaste code die diep in het cijferboek haakte, vereisten bijna een complete herbouw van de maatwerkcode. De les was pijnlijk maar blijvend: koppel je bedrijfslogica nooit aan Moodle-internals. Bouw op de stabiele API's, en waar geen stabiele API bestaat, isoleer de koppeling op één plek zodat die makkelijk te vervangen is.
De 2.0-architectuur, ondanks alle pijn van de migratie, was echt beter. De bestandsAPI betekende dat we eindelijk plugins konden bouwen die bestandsbijlagen betrouwbaar afhandelden. Het capability-systeem kreeg een veel volwassener uitwerking. En de backup/restore-laag werd voor het eerst een fundament waar je serieus op kon bouwen.
De 2.x-jaren: ritme, stabilisatie en een eerste frontend-kantelpunt (2011-2015)
In de jaren na 2.0 kreeg Moodle een voorspelbaarder release-ritme. Officieel hanteert Moodle voor major releases een cyclus van zes maanden, traditioneel in april en oktober. Dat ritme gaf het ecosysteem rust: plugins, documentatie en upgradeverwachtingen werden minder grillig. De plugin-directory op moodle.org werd echt bruikbaar, codestandaarden werden opgeschreven en de ontwikkelaarsdocumentatie verbeterde zichtbaar.
Voor ons was dit een productieve periode. We bouwden serieuze maatwerk-plugins voor opleidingsorganisaties met specifieke eisen rond certificaatbeheer die geen kant-en-klare plugin kon invullen. We bouwden een maatwerk-rapportplugin die voltooiingsdata over meerdere cursussen bevroeg en PDF-certificaten genereerde met TCPDF. Het werkte, het was onderhoudbaar, en het upgraden door 2.2, 2.3, 2.4 was eenvoudig omdat de API's waarop we steunden stabiel bleven.
Voor frontend-ontwikkeling is vooral Moodle 2.9 een belangrijker kantelpunt dan vaak wordt gedacht. Vanaf 2.9 werden templates de voorkeursroute voor HTML-output in plaats van HTML opbouwen in PHP, en ondersteunde Moodle AMD JavaScript-modules. De 3.x-serie maakte die aanpak vervolgens dominant, maar ze begon dus niet pas halverwege 3.x.
De 2.x-periode leerde ons ook over het governance-model van Moodle. Met governance bedoelen we: wie beslist wat er wel en niet in Moodle core terechtkomt, via welke spelregels, en hoe de community daarin wordt gehoord. In de praktijk werkt dat zo: Moodle HQ in Perth is eindverantwoordelijk voor de roadmap, beslist over breaking changes en keurt core-bijdragen uiteindelijk goed of af. Voorstellen en bugs lopen openbaar via de tracker (tracker.moodle.org), inhoudelijke discussie gebeurt op de forums van moodle.org, en code-bijdragen komen binnen als patches met peer review voordat ze in een release-branch landen. Het model is niet altijd snel, omstreden features kunnen jarenlang in discussie blijven, maar het levert een platform op met een coherente visie en duidelijke verantwoordelijkheid. Als we het niet eens waren met beslissingen (en dat was soms het geval), leerden we constructief via de tracker te engageren in plaats van er omheen te patchen.
Moodle 3.2-3.11: Boost, Mustache, privacy en een volwassen 3.x-lijn
De echte Bootstrap-omslag hoort niet bij Moodle 3.0, maar bij Moodle 3.2, uitgebracht op 5 december 2016. In de officiële release notes van 3.2 staat de nieuwe core-theme Boost op basis van Bootstrap 4 expliciet genoemd, samen met block- en navigatiewijzigingen. Dat is historisch gezien het juiste moment om de grote theming- en frontendverschuiving te plaatsen.
Voor zorgklanten die mobiel toegankelijke trainingen begonnen te vereisen voor klinisch personeel, was dit een doorbraak. Een verpleegkundige kon nu een compliancemodule afronden op een tablet tijdens een pauze. Maar de thema-architectuurwijziging was wederom een migratiehoofdzeer. Maatwerk-thema's gebouwd voor 2.x en vroege 3.x moesten herschreven worden voor Bootstrap. We hadden thema's gebouwd voor meerdere klanten die strak gekoppeld waren aan de oude opmaakstructuur. Elk ervan vereiste een complete front-end herbouw.
Samen met Boost werd Mustache de voorkeursroute om HTML vanuit een plugin te renderen. Die aanpak startte al in 2.9, maar vanaf 3.2 werd hij duidelijk de standaard. Mustache-templates zijn testbaar, scheiden verantwoordelijkheden correct, en maken het makkelijker voor thema-ontwikkelaars om plugin-output te overschrijven zonder plugin-PHP aan te raken. We herbouwden onze output-laag voor een groot deel van onze plugincatalogus in 2016 en 2017.
De webservices-API, die in rudimentaire vorm al bestond vanaf 2.0, rijpte sterk door de 3.x-serie. Tegen 3.5 was hij robuust genoeg om echte mobiele applicaties te ondersteunen. Voor Dentallect, een platform voor nascholing in de tandheelkunde dat we in deze periode hielpen bouwen, liet de webservices-API ons een companion-app bouwen die cursusvoortgang terugsynchroniseerde naar Moodle. De REST-API was goed gedocumenteerd en betrouwbaar. Die ervaring gaf ons vertrouwen in de externe API van Moodle als basis voor integraties.
Een andere harde mijlpaal in deze periode is Moodle 3.5. Daar werd vastgelegd dat plugins de Privacy API moeten implementeren om voor GDPR/AVG correct te rapporteren, exporteren en verwijderen welke persoonsgegevens ze opslaan. Dat is een veel preciezere kapstok dan alleen zeggen dat "privacy belangrijker werd in 3.x". We hadden meerdere Nederlandse klanten, met name zorginstellingen, voor wie inzageverzoeken voorheen een handmatige nachtmerrie waren. De Privacy API maakte dat automatiseerbaar.
Moodle 3.11 werd uitgebracht op 17 mei 2021 en is inmiddels unsupported: er komen geen fixes voor securityrisico's meer uit. Als historische eindfase van de 3.x-lijn is 3.11 relevant, maar technisch is het nu echt een oude versie.
Moodle 4.0: de echte UX-reset (2022)
Moodle 4.0, uitgebracht op 19 april 2022, was de grootste zichtbare UX-reset sinds 2.0. Die release bracht primary, secondary en tertiary navigation, een nieuwe course index, page drawers, en een verdere verschuiving van course rendering naar output components en Mustache-templates. Voor plugin- en formatbouwers was dat een serieuze wijziging, juist omdat veel course-output formeel in een nieuwere renderlaag terechtkwam.
Voor gebruikers was dit lang achterstallig en breed positief. De oude Moodle-interface was jarenlang een drempel voor adoptie, klanten klaagden dat cursisten het verwarrend vonden. Moodle 4.0 loste veel van die klachten op.
Voor plugin-ontwikkelaars was het alweer een migratie. Navigatieknooppuntafhandeling veranderde opnieuw. Blokplugins moesten worden nagelopen omdat blokken voortaan in de rechter blok-drawer landden, met aangepaste regio's en zonder de oude dock. Thema's gebouwd voor 3.x hadden updates nodig, met Boost als de officiële core-basis voor maatwerk-thema's.
Voor quiz- en vraagplugins was 4.0 ook een echt omslagpunt. De release introduceerde het nieuwe qbank-plugin type en question versions, werkte mod_quiz bij voor die nieuwe vragenbank, integreerde BigBlueButton in core Moodle LMS, en benoemde accessibility improvements expliciet als onderdeel van de release. Voor klanten in de zorg- en onderwijssector waren de toegankelijkheidsverbeteringen betekenisvol. Zorginstellingen die moesten voldoen aan de webtoegankelijkheidswetgeving waardeerden het feit dat ze geen toegankelijkheidspatches meer in hun maatwerk-plugins hoefden te bouwen.
Moodle 4.1-4.5: stabilisatie, LTS en AI in core
Moodle 4.1 was de LTS-release van die generatie en verhoogde de minimum-PHP-versie naar 7.4. Daarna is 4.5 de nieuwe LTS geworden. Volgens het officiële release-overzicht is 4.5 de meest recente LTS, met 5.3 als volgende LTS. Moodle 4.5 werd uitgebracht op 7 oktober 2024 en vereist minimaal PHP 8.1.
Belangrijk: het AI-verhaal begint niet pas bij Moodle 5.1. In Moodle 4.5 werd al een AI-subsystem aan Moodle LMS toegevoegd, inclusief placements en providerplugins zoals Open AI en Azure AI. 5.x bouwt daarop voort, maar 4.5 is de echte start van AI in core LMS.
De organisatorische verschuiving in deze periode was ook opmerkelijk. Moodle HQ rebrandde het platform als "Moodle LMS" om het te onderscheiden van hun groeiende productportfolio (Moodle Workplace, MoodleNet, MoodleCloud). Als specialistisch bureau verduidelijkte dit het landschap. Als klanten vroegen naar "Moodle," konden we nu wijzen naar een specifiek product met een duidelijke routekaart.
Moodle 5.0 en 5.1: modern PHP, routing en verdere AI-uitbouw
Moodle 5.0 verscheen op 14 april 2025 en Moodle 5.1 op 6 oktober 2025. Beide vereisen minimaal Moodle 4.2.3 als bronversie en minimaal PHP 8.2. Voor elke plugin die op PHP 7-syntaxis was blijven hangen, vereiste dit updates: getypte eigenschappen, benoemde argumenten, enum-ondersteuning, alleen-lezen eigenschappen, intersectietypes. Modern PHP is echt expressiever en veiliger dan PHP 7, maar het upgradepad vereist aandacht.
Moodle 5.1 bracht daarnaast een nieuwe /public-directorystructuur en een nieuwe routing engine. Op AI-vlak breidde 5.0 de 4.5-basis uit met onder meer een Ollama-provider, meerdere provider instances en adminrapportage voor AI-gebruik, terwijl 5.1 daar course- en activity-level access controls, betere placement-foutmeldingen en een DeepSeek-provider aan toevoegde. 5.1 bracht bovendien een vernieuwde activity chooser en een centralere course overview page.
Per vandaag is de actuele situatie dus: Moodle 4.5 is de huidige LTS/security-lijn, 5.0 en 5.1 zijn current stable, 5.2 staat nog als toekomstige release gepland, en 5.3 is aangewezen als volgende LTS.
Wat we leerden over langlevende plugins
Als ervaren Moodle plugin ontwikkelaar leert driehonderd plugins over vijftien jaar je patronen. Dit is wat we weten:
Bouw op de stabiele plugin-API, niet op internals. Core-functies met een underscore-prefix, interne databasetabellen die niet worden beheerd via het XMLDB-schema, renderer-methoden die niet in de gedocumenteerde API zitten, die veranderen allemaal tussen versies. De stabiele plugin-API verandert langzamer en is gedocumenteerd. Gebruik die.
Wees eigenaar van je databaseschema. Definieer al je tabellen via het XMLDB-schema in db/install.xml en db/upgrade.php. Maak nooit tabellen aan door raw SQL vanuit plugin-code uit te voeren. Het upgradesysteem bestaat precies om schemamigraties over Moodle-versies heen af te handelen.
Test op de volgende versie voordat die uitkomt. Moodle publiceert release candidates. Je plugin-testsuites draaien op RC-builds pikt breaking changes op voordat ze de productie raken. We hebben een CI-pipeline gebouwd die draait op de huidige stabiele versie, huidige LTS en huidige RC. Dat heeft veel problemen vroeg gevangen.
Houd je JavaScript modulair. Elke keer dat we AMD-modules hadden met duidelijke inputs en outputs, verliepen upgrades soepel. Elke keer dat we inline JavaScript hadden verstrengeld met PHP-stringoutput, waren upgrades pijnlijk.
Respecteer de Mustache-grens. Plugin-PHP moet datamatrices klaarmaken. Mustache-templates moeten HTML renderen. Als je die grens vervaagt, bedrijfslogica in templates zetten, of HTML in PHP genereren, lijdt het onderhoud direct en stapelt upgradecomplex zich op.
De menselijke kant: community en governance
De Moodle-community is één van de meest consistente positieve krachten geweest over vijftien jaar. De moodle.org-forums, de ontwikkelaarschat, de jaarlijkse MoodleMoot-conferenties, dit zijn plekken waar echte kennisdeling plaatsvindt. We hebben code bijgedragen aan de community, we hebben bijdragen van community-leden ontvangen die onze eigen plugins verbeterden, en we hebben geleerd van andere ontwikkelaars die door dezelfde problemen worstelden.
Het governance-model, HQ-gestuurd met community-input via de tracker, heeft zijn frustraties. Beslissingscycli kunnen traag zijn. Prioriteiten komen niet altijd overeen met wat bureaus in het veld nodig hebben. Maar het model levert een platform op met een coherente visie en een oprechte toewijding aan achterwaartse compatibiliteit binnen grote versies.
De jaarlijkse MoodleMoot NL-evenementen gaven ons directe verbindingen met de Nederlandse Moodle-community. Die relaties tellen, als een klant een ongewoon probleem heeft, weten wie je moet bellen in het bredere ecosysteem is onderdeel van goede dienstverlening.
Advies voor organisaties die nog op oudere versies draaien
Als je dit leest terwijl je Moodle 3.9 of 3.11 draait, zit je aantoonbaar buiten supported territory. Voor 3.9 eindigden de securityfixes op 11 december 2023; 3.11 krijgt überhaupt geen fixes voor securityrisico's meer. De kloof met actuele Moodle-versies is niet alleen cosmetisch, maar ook operationeel en security-gerelateerd.
Belangrijker nog: het actuele upgradepad is gefaseerd. Moodle 4.5 vereist minimaal 4.1.2 als bronversie, en Moodle 5.0 en 5.1 vereisen minimaal 4.2.3. Vanuit 3.9 of 3.11 kun je dus niet meer zomaar rechtstreeks naar iedere moderne lijn springen; minstens één tussenstap is onvermijdelijk.
Onze aanbeveling: begin met een audit. Catalogiseer elke aanpassing, maatwerk-plugins, thema-overschrijvingen, core-patches, third-party plugins. Bepaal voor elk de onderhoudsstatus. Controleer voor third-party plugins of er 4.x/5.x-compatibele releases zijn. Schat voor maatwerkcode de updateinspanning in. Plan daarna een gefaseerde upgrade: eerst testomgeving, dan staging, dan productie, met voor elke fase een terugrolplan.
De organisaties die het moeilijkst upgraden zijn de organisaties die technische schulden hebben laten ophopen terwijl ze de upgradebeslissing uitstelden. Elk jaar op een oude versie vergroot die schuld.
Vooruitkijken
De kern van het verhaal blijft overeind: Moodle is in vijftien jaar veranderd van een ruw, PHP-zwaar cursusplatform naar een volwassen, modulair LMS. De historische bakens liggen net iets anders dan vaak gedacht: 2.0 was de grote backend-breuk, 2.9 en 3.2 vormden het frontend-keerpunt, 4.0 was de UX-reset, 4.5 bracht AI in core Moodle LMS, en 5.x zet de lijn door met PHP 8.2+, routing en verdere AI-integratie.
We zijn er samen mee herbouwd. Elke grote versie heeft ons laten groeien, als PHP-ontwikkelaars, als front-end-engineers, als architecten van leerplatforms. De migratie van 1.8 naar 2.0 dwong ons goede plugin-architectuur te leren. Het 2.9/3.2-tijdperk dwong ons moderne JavaScript en templating te leren. De 4.0 UX-overhaul dwong ons te investeren in UX-denken. Moodle 5.x duwt ons dieper in modern PHP, routing en AI-ondersteunde ontwikkeling.
Dat is, denken we, precies het soort uitdaging voor een team dat dit ook de komende vijftien jaar wil blijven doen.
