# Ldesign Media — full content > Ldesign Media is a specialized Moodle LMS development and consultancy company based in The Hague, Netherlands (founded 2007), providing Moodle plugin development, system and SSO integrations, technical consulting, hosting, and custom LMS solutions in English and Dutch. This is the full-content companion to [llms.txt](https://ldesignmedia.nl/llms.txt): complete article text for LLM ingestion. The same AI usage policy applies: AI training, summarization, and search indexing are allowed; commercial reuse of content is not. Please cite "Ldesign Media" with a link to https://ldesignmedia.nl/en. --- ## What Does an LMS Cost? An Honest Pricing Guide for 2026 (EN) Source: https://ldesignmedia.nl/en/blog/what-does-an-lms-cost Published: 2026-07-28 "What does an LMS cost?" is the question we hear most often from L&D managers, HR teams, and trainers who are comparing learning platforms. The honest answer: anywhere from a few hundred euros per year to well over a hundred thousand, depending on the route you choose. In this guide we break down the three main routes (a commercial SaaS LMS, a professionally managed open-source LMS, and custom development), the cost drivers that really move the number, the costs that are easily missed in a first price comparison, and what a realistic total cost of ownership looks like over three to five years. All figures in this article are indicative ranges based on what we see in the Dutch and Belgian market. Prices vary per vendor, contract, and situation, so treat them as orientation, not as a quote. ## 1. The Short Answer: Three Routes In practice, organizations usually choose between three routes: a commercial SaaS LMS, a professionally managed open-source LMS, or a largely custom-built learning environment. These routes can partly overlap, but they have clearly different cost structures. ### SaaS LMS: per-user license fees With a commercial SaaS platform you pay a recurring license fee, usually per active user per month. Indicatively, in the Dutch market we see rates of roughly €2 to €15 per active user per month. Some vendors, however, work with flat subscriptions, user bundles, or enterprise contracts instead of a per-user price. Based on quotes and projects we encounter in the Dutch and Belgian market, we roughly see the following ranges: - **Entry-level packages:** roughly 2 to 5 euros per user per month, often with a minimum of 50 to 100 users - **Mid-market platforms:** roughly 5 to 15 euros per user per month, usually with annual platform fees on top - **Enterprise suites:** 15 euros and up per user per month, with implementation fees that can run into the tens of thousands For 500 users at a mid-market rate, you are quickly looking at 30,000 to 90,000 euros in license costs per year, excluding implementation, support, and add-ons. Every year, for as long as you use the platform. ### Open source (Moodle): no license costs Moodle is open source, released under the [GNU GPL license](https://www.gnu.org/licenses/gpl-3.0.html) and free to download from [moodle.org](https://moodle.org). There are **no license fees per user**. Moodle imposes no user limit in the software itself; practical limits are set by hosting and infrastructure. There are no per-user software licences that are re-billed every year. An LMS without license costs does not mean an LMS without costs: you pay for hosting, implementation, maintenance, and optionally support. But the cost structure is fundamentally different. Your budget mainly goes toward implementation, infrastructure, management, and further development, instead of recurring per-user software licenses. ### Custom development (maatwerk) With custom development you invest in a learning environment built around your processes, usually on an open-source foundation like Moodle. A focused custom plugin starts at a few thousand euros; a complete custom environment with theme, integrations, and plugins typically ranges from 25,000 to 100,000+ euros as a one-time investment. After that, your running costs are hosting and a support agreement. ## SaaS vs Open Source vs Custom at a Glance - **License costs:** SaaS: per user per month, re-billed every year | Open source: no license fees | Custom: no license fees, but one-time development costs - **User limit:** SaaS: costs grow with every user | Open source: no limit in the software; practical limits set by hosting and infrastructure | Custom: same, tailored to your infrastructure - **Upfront costs:** SaaS: low, often with onboarding and implementation fees | Open source: implementation, theme, and configuration | Custom: highest initial investment - **Costs as you grow:** SaaS: a license bill that grows with you | Open source: mostly extra hosting capacity | Custom: mostly hosting and further development - **Flexibility and integrations:** SaaS: limited to what the vendor offers | Open source: fully extensible with plugins | Custom: fully bespoke, including integrations with your systems - **Data and exit:** SaaS: subject to the vendor's export options and exit terms | Open source and custom: generally more control over data, hosting, and export, depending on the chosen management and contract model ## 2. The Real Cost Drivers The sticker price of an LMS is determined less by the vendor and more by five drivers. Understanding them puts you in control of any LMS quote (lms offerte) you receive. ### Number of users The dominant variable for SaaS platforms. Watch out for how "user" is defined: registered users, monthly active users, or concurrent users each produce very different bills. With open source, the user count mainly affects hosting capacity, not license costs. ### Integrations Connecting your LMS to your HR system, SSO (Azure AD, SAML), CRM, or payment provider can account for a significant share of the implementation budget and, in complex projects, raise total costs sharply. Off-the-shelf connectors can be sufficient when both systems support the same standards and data structures. Integrations with organization-specific processes, data models, or exceptions often require additional configuration or custom development. ### Hosting SaaS hosting is bundled into your license. For open source you choose: professional managed hosting often starts around 100 euros per month and can run up to several thousand euros per month for business-critical environments with high availability. ### Support and maintenance As a general software rule of thumb, the annual cost of technical maintenance, security updates, and limited ongoing development is often budgeted at roughly 15 to 25 percent of the original technical implementation cost. Deferring maintenance for a long time can lead to higher upgrade, security, and recovery costs. ### Content The platform is only the container. Creating e-learning content (instructional design, video, interactive modules) is a cost driver of its own. For organizations that need to develop many new courses, the content budget can ultimately exceed the technical LMS budget. Off-the-shelf course libraries cost 5 to 30 euros per user per course; custom-made e-learning ranges from 5,000 to 25,000 euros per finished hour of learning, depending on interactivity. Simple content can be considerably cheaper; video, animation, simulations, and complex interactions can raise the cost sharply. ## 3. Costs That Are Easily Missed in a First Price Comparison In 15+ years of Moodle projects, we have seen the same surprises come back in almost every LMS budget discussion: - **Onboarding and implementation fees:** many SaaS vendors charge 5,000 to 25,000 euros one-time before you can start - **Price per user at renewal:** contracts that looked sharp for 200 users become painful at 800 - **Premium features:** reporting, API access, SSO, and white-labeling often sit in a higher tier - **Data export and migration:** some vendors charge for data export or professional migration assistance, and the completeness, format, and cost of an export vary per vendor - **Unused seats:** licenses for employees who never log in - **Content lock-in:** content from a vendor-specific authoring tool is not always transferable as an editable source file; sometimes you can only export the published output ## 4. TCO: What an LMS Really Costs Over 3 to 5 Years License fees are only one line in the total cost of ownership. A realistic comparison for an organization with 500 users, roughly and depending on size and complexity: **SaaS mid-market platform (5 years):** - Licenses: 150,000 to 450,000 euros (500 users × €5 to €15 × 60 months) - Implementation and onboarding: 10,000 to 30,000 euros - Integrations: 10,000 to 40,000 euros - Management, support, and annual indexation: 10,000 to 40,000 euros - **Total: roughly 180,000 to 560,000 euros, depending on size and complexity** **Open source Moodle, professionally managed (5 years):** - Licenses: 0 euros - Implementation, theme, and configuration: 15,000 to 50,000 euros - Hosting: 6,000 to 30,000 euros - Support, updates, and small improvements: 25,000 to 75,000 euros - Upgrades, monitoring, and data migration: 5,000 to 25,000 euros - **Total: roughly 51,000 to 180,000 euros, depending on size and complexity** **Custom LMS development on Moodle (5 years):** - One-time development: 25,000 to 100,000+ euros - Hosting, support, and further development: 40,000 to 100,000 euros - Upgrades, monitoring, and data migration: 5,000 to 25,000 euros - **Total: roughly 70,000 to 225,000 euros, depending on size and complexity**, with an environment that fits your processes exactly A complex implementation with many integrations or specific requirements can exceed these ranges; for large custom projects the TCO can also run above 250,000 euros. This comparison covers the main external platform costs, but not the internal hours for functional administration, content management, training, and change management. Those costs can be significant for all models. The pattern is consistent: with SaaS models that charge per user, costs grow with the number of registered or active users, while with open source and custom development the investment is front-loaded and the marginal cost per extra user is usually limited, because no per-user license is charged. That is where organizations [save on LMS license costs](https://ldesignmedia.nl/en/tco-calculator) most. Our TCO calculator lets you run this comparison with your own numbers. ## 5. When Does an Open-Source or Custom LMS Become More Attractive Than SaaS? SaaS is a rational choice when you have a small, stable user group, standard requirements, and no integration needs. A professionally managed open-source LMS, optionally extended with custom development, becomes especially attractive when: - You have **more than a few hundred users** and per-user pricing makes growth expensive - You need **integrations** with HR, SSO, planning, or payment systems - You have **specific requirements around data location, processors, retention periods, and data access** due to GDPR, information security, or internal policy - You want **your own branding and UX** without vendor constraints - You need **workflows that no standard platform supports** For organizations such as KLM and Nedap, we developed Moodle functionality that aligned with organization-specific training processes. ## 6. Requesting an LMS Quote: What a Good Quote Contains When you request a quote for a learning platform (leerplatform offerte), compare more than the bottom line. A serious LMS quote specifies: - Which cost model applies and how users are counted - What is included in implementation (data migration, theme, configuration) - Which integrations are included and which are billed hourly - The hosting arrangement and where your data is stored - The support scope: response times, updates, upgrade policy - Exit terms: can you export your data and content, and at what cost If a quote only shows a per-user price, ask for the five-year total. That is the number that matters. ## 7. Frequently Asked Questions ### What does Moodle itself cost? Moodle is free to download and use. For Moodle LMS itself you pay no license fees per user, regardless of the number of users. Hosting, implementation, management, and any commercial plugins or additional services do cost money. Read more on our [LMS development service page](https://ldesignmedia.nl/en/services/lms-development). ### What does it cost to have an e-learning platform built? A focused custom plugin starts at a few thousand euros. A complete custom learning environment with integrations typically starts around 25,000 euros, depending on scope. The ranges above are indicative; every project is scoped individually. ### Is an LMS without license costs really cheaper? For organizations with a few hundred users or more, a professionally managed open-source LMS proves financially more attractive than a per-user SaaS model in many situations over multiple years. The exact break-even point, however, differs per situation. Below that, SaaS entry packages can be competitive, until you need integrations or grow. ### Can we keep our existing content when switching? Often yes, but it depends on the format used and the available source files. SCORM packages can generally be moved to another SCORM-compliant LMS. For all other content, we look at the options together: which exports does the current platform offer, is there an API available, and can progress, results, and certificates come along? We can map this out in a [quickscan of your current environment](https://ldesignmedia.nl/en/moodle-quickscan). Content from a vendor-specific authoring tool is not always transferable as an editable source file; sometimes only the published output can be exported. ## Conclusion The right question is not "what does an LMS cost" but "what will our LMS cost us over five years, including everything." For organizations with a few hundred users or more, a professionally managed open-source platform can be more cost-effective over multiple years, particularly when the SaaS alternative is billed per user. This must be calculated per situation, including implementation, management, upgrades, internal hours, and exit costs. Want to know what this looks like with your numbers? Run the comparison in our [TCO calculator](https://ldesignmedia.nl/en/tco-calculator), request a free [Moodle quickscan](https://ldesignmedia.nl/en/moodle-quickscan) of your current environment, or [get in touch](https://ldesignmedia.nl/en/contact) for a no-obligation conversation. Ldesign Media has been active with Moodle since 2010 and has delivered more than 300 custom plugins, so chances are we have solved your challenge before. --- ## What Does an LMS Cost? An Honest Pricing Guide for 2026 (NL) Source: https://ldesignmedia.nl/nl/blog/wat-kost-een-lms Published: 2026-07-28 "Wat kost een LMS?" is de vraag die we het vaakst horen van L&D-managers, HR-teams en opleiders die leerplatforms vergelijken. Het eerlijke antwoord: van enkele honderden euro's per jaar tot ruim een ton, afhankelijk van de route die je kiest. In deze gids zetten we de drie belangrijkste routes op een rij (een commercieel SaaS-LMS, een professioneel beheerd open-source LMS en maatwerk), de kostendrijvers die het bedrag echt bepalen, de kosten die in een eerste prijsvergelijking gemakkelijk worden gemist en hoe een realistische total cost of ownership er over drie tot vijf jaar uitziet. Alle bedragen in dit artikel zijn indicatieve bandbreedtes op basis van wat wij in de Nederlandse en Belgische markt zien. Prijzen verschillen per leverancier, contract en situatie; zie ze als orientatie, niet als offerte. ## 1. Het korte antwoord: drie routes Organisaties kiezen in de praktijk meestal uit drie routes: een commercieel SaaS-LMS, een professioneel beheerd open-source LMS of een grotendeels op maat ontwikkelde leeromgeving. Deze routes kunnen elkaar deels overlappen, maar hebben een duidelijk verschillende kostenstructuur. ### SaaS LMS: licentiekosten per gebruiker Bij een commercieel SaaS-platform betaal je een terugkerende licentievergoeding, meestal per actieve gebruiker per maand. Indicatief zien wij in de Nederlandse markt tarieven van ongeveer €2 tot €15 per actieve gebruiker per maand. Sommige leveranciers rekenen echter met vaste abonnementen, gebruikersbundels of enterprise-contracten in plaats van een prijs per gebruiker. Op basis van offertes en projecten die wij in de Nederlandse en Belgische markt tegenkomen, zien we grofweg de volgende bandbreedtes: - **Instappakketten:** circa 2 tot 5 euro per gebruiker per maand, vaak met een minimum van 50 tot 100 gebruikers - **Midmarket-platforms:** circa 5 tot 15 euro per gebruiker per maand, meestal met jaarlijkse platformkosten erbovenop - **Enterprise-suites:** 15 euro en hoger per gebruiker per maand, met implementatiekosten die in de tienduizenden euro's kunnen lopen Voor 500 gebruikers tegen een midmarket-tarief zit je al snel op 30.000 tot 90.000 euro aan licentiekosten per jaar, exclusief implementatie, support en add-ons. Elk jaar opnieuw, zolang je het platform gebruikt. ### Open source (Moodle): geen licentiekosten Moodle is open source, vrijgegeven onder de [GNU GPL-licentie](https://www.gnu.org/licenses/gpl-3.0.html) en gratis te downloaden via [moodle.org](https://moodle.org). Er zijn **geen licentiekosten per gebruiker**. Moodle kent vanuit de software geen gebruikerslimiet; praktische grenzen worden bepaald door hosting en infrastructuur. Er zijn geen softwarelicenties per gebruiker die jaarlijks opnieuw worden afgerekend. Een LMS zonder licentiekosten betekent niet een LMS zonder kosten: je betaalt voor hosting, implementatie, onderhoud en eventueel support. Maar de kostenstructuur is fundamenteel anders. Je budget gaat vooral naar implementatie, infrastructuur, beheer en doorontwikkeling, in plaats van naar terugkerende softwarelicenties per gebruiker. ### Maatwerk Bij maatwerk investeer je in een leeromgeving die is gebouwd rond jouw processen, meestal op een open-source fundament zoals Moodle. Een gerichte maatwerk-plugin begint bij enkele duizenden euro's. Wie vooral een eigen huisstijl, SSO en een paar plugins wil, zit doorgaans in de bandbreedte van 10.000 tot 20.000 euro. Complete maatwerkomgevingen met thema, integraties en plugins starten in de praktijk vaak rond de 25.000 euro en lopen op tot 100.000+ euro als eenmalige investering. Daarna zijn je lopende kosten hosting en een supportcontract. ## SaaS vs open source vs maatwerk in het kort - **Licentiekosten:** SaaS: per gebruiker per maand, jaarlijks opnieuw | Open source: geen licentiekosten | Maatwerk: geen licentiekosten, wel eenmalige ontwikkelkosten - **Gebruikerslimiet:** SaaS: kosten groeien mee met elke gebruiker | Open source: geen limiet in de software, praktische grens zit in hosting en infrastructuur | Maatwerk: idem, afgestemd op jouw infrastructuur - **Opstartkosten:** SaaS: laag, met vaak onboarding- en implementatiekosten | Open source: implementatie, thema en configuratie | Maatwerk: hoogste initiële investering - **Kosten bij groei:** SaaS: meegroeiende licentierekening | Open source: vooral extra hostingcapaciteit | Maatwerk: vooral hosting en doorontwikkeling - **Flexibiliteit en integraties:** SaaS: beperkt tot wat de leverancier aanbiedt | Open source: volledig aanpasbaar met plugins | Maatwerk: volledig op maat, inclusief integraties met jouw systemen - **Data en exit:** SaaS: afhankelijk van exportmogelijkheden en exitvoorwaarden van de leverancier | Open source en maatwerk: doorgaans meer controle over data, hosting en export, afhankelijk van de gekozen beheer- en contractvorm ## 2. De echte kostendrijvers De prijs van een LMS wordt minder bepaald door de leverancier dan door vijf drijfveren. Wie ze begrijpt, heeft grip op elke LMS-offerte. ### Aantal gebruikers De dominante variabele bij SaaS-platforms. Let goed op hoe "gebruiker" is gedefinieerd: geregistreerde gebruikers, maandelijks actieve gebruikers of gelijktijdige gebruikers leveren elk een heel andere rekening op. Bij open source bepaalt het aantal gebruikers vooral de benodigde hostingcapaciteit, niet de licentiekosten. ### Integraties De koppeling van je LMS met je HR-systeem, SSO (Azure AD, SAML), CRM of betaalprovider kan een aanzienlijk deel van het implementatiebudget vormen en bij complexe projecten de totale kosten sterk verhogen. Kant-en-klare connectoren kunnen voldoende zijn wanneer beide systemen dezelfde standaarden en gegevensstructuren ondersteunen. Integraties met organisatiespecifieke processen, datamodellen of uitzonderingen vragen vaak aanvullende configuratie of maatwerk. ### Hosting Bij SaaS zit hosting in de licentie verwerkt. Bij open source kies je zelf: professionele managed hosting begint vaak rond 100 euro per maand en loopt op tot enkele duizenden euro's per maand voor bedrijfskritische omgevingen met hoge beschikbaarheid. ### Support en onderhoud Als algemene softwarevuistregel wordt voor technisch onderhoud, beveiligingsupdates en beperkte doorontwikkeling vaak jaarlijks ongeveer 15 tot 25 procent van de oorspronkelijke technische realisatiekosten begroot. Langdurig uitstel van onderhoud kan leiden tot hogere upgrade-, beveiligings- en herstelkosten. ### Content Het platform is slechts de verpakking. Het ontwikkelen van e-learningcontent (didactisch ontwerp, video, interactieve modules) is een kostendrijver op zich. Bij organisaties die veel nieuwe cursussen moeten ontwikkelen, kan het contentbudget uiteindelijk groter worden dan het technische LMS-budget. Kant-en-klare cursusbibliotheken kosten 5 tot 30 euro per gebruiker per cursus; maatwerk e-learning loopt van 5.000 tot 25.000 euro per gerealiseerd lesuur, afhankelijk van de interactiviteit. Eenvoudige content kan aanzienlijk goedkoper zijn; video, animatie, simulaties en complexe interacties kunnen de kosten sterk verhogen. ## 3. Kosten die in een eerste prijsvergelijking gemakkelijk worden gemist In meer dan 15 jaar Moodle-projecten hebben we steeds dezelfde verrassingen terug zien komen in vrijwel elke LMS-budgetdiscussie: - **Onboarding- en implementatiekosten:** veel SaaS-leveranciers rekenen eenmalig 5.000 tot 25.000 euro voordat je van start kunt - **Prijs per gebruiker bij verlenging:** een contract dat scherp leek voor 200 gebruikers wordt pijnlijk bij 800 - **Premiumfuncties:** rapportages, API-toegang, SSO en white-labeling zitten vaak in een duurdere bundel - **Data-export en migratie:** sommige leveranciers rekenen kosten voor export of professionele begeleiding bij een migratie, waarbij de volledigheid, het formaat en de kosten van de export per leverancier verschillen - **Ongebruikte licenties:** licenties voor medewerkers die nooit inloggen - **Content lock-in:** content uit een leveranciersgebonden authoringtool is niet altijd als bewerkbaar bronbestand overdraagbaar; soms kun je alleen de gepubliceerde uitvoer exporteren ## 4. TCO: wat kost een LMS echt over 3 tot 5 jaar? Licentiekosten zijn slechts een regel in de total cost of ownership. Een realistische vergelijking voor een organisatie met 500 gebruikers, globaal en afhankelijk van omvang en complexiteit: **SaaS midmarket-platform (5 jaar):** - Licenties: 150.000 tot 450.000 euro (500 gebruikers × 5 tot 15 euro × 60 maanden) - Implementatie en onboarding: 10.000 tot 30.000 euro - Integraties: 10.000 tot 40.000 euro - Beheer, support en jaarlijkse indexatie: 10.000 tot 40.000 euro - **Totaal: circa 180.000 tot 560.000 euro, afhankelijk van omvang en complexiteit** **Open source Moodle, professioneel beheerd (5 jaar):** - Licenties: 0 euro - Implementatie, thema en configuratie: 15.000 tot 50.000 euro - Hosting: 6.000 tot 30.000 euro - Support, updates en kleine verbeteringen: 25.000 tot 75.000 euro - Upgrades, monitoring en datamigratie: 5.000 tot 25.000 euro - **Totaal: circa 51.000 tot 180.000 euro, afhankelijk van omvang en complexiteit** **Maatwerk LMS op Moodle (5 jaar):** - Eenmalige ontwikkeling: 25.000 tot 100.000+ euro - Hosting, support en doorontwikkeling: 40.000 tot 100.000 euro - Upgrades, monitoring en datamigratie: 5.000 tot 25.000 euro - **Totaal: circa 70.000 tot 225.000 euro, afhankelijk van omvang en complexiteit**, met een omgeving die exact op je processen aansluit Een complexe implementatie met veel integraties of specifieke eisen kan boven de genoemde bandbreedtes uitkomen; bij grote maatwerktrajecten kan de TCO ook boven de 250.000 euro uitstijgen. De vergelijking omvat de belangrijkste externe platformkosten, maar niet de interne uren voor functioneel beheer, contentbeheer, training en verandermanagement. Die kosten kunnen bij alle modellen aanzienlijk zijn. Het patroon is consistent: bij SaaS-modellen met gebruikersafhankelijke licenties groeien de kosten mee met het aantal geregistreerde of actieve gebruikers, terwijl bij open source en maatwerk de investering voorop ligt en de marginale kosten per extra gebruiker meestal beperkt blijven omdat er geen licentie per gebruiker wordt berekend. Daar vervallen de terugkerende licentiekosten per gebruiker, waardoor het kostenprofiel fundamenteel verschilt. Met onze [TCO-calculator](https://ldesignmedia.nl/nl/tco-calculator) reken je deze vergelijking door met je eigen cijfers. ## 5. Wanneer wordt een open-source of maatwerk-LMS aantrekkelijker dan SaaS? SaaS is vaak een goede keuze voor organisaties met een kleine, stabiele gebruikersgroep, standaard eisen en geen integratiebehoefte. Een professioneel beheerd open-source LMS, eventueel aangevuld met maatwerk, wordt vooral aantrekkelijk wanneer: - Je **meer dan enkele honderden gebruikers** hebt en prijzen per gebruiker groei duur maken - Je **integraties** nodig hebt met HR, SSO, planning of betaalsystemen - Je vanwege **AVG, informatiebeveiliging of intern beleid** specifieke eisen stelt aan datalocatie, verwerkers, bewaartermijnen en toegang tot gegevens - Je **eigen huisstijl en UX** wilt zonder beperkingen van een leverancier - Je **workflows** nodig hebt die geen standaardplatform ondersteunt Voor organisaties zoals KLM en Nedap hebben wij Moodle-functionaliteit ontwikkeld die aansloot op organisatiespecifieke trainingsprocessen. ## 6. Een LMS-offerte aanvragen: wat hoort erin te staan? Wanneer je een offerte voor een leerplatform aanvraagt, vergelijk dan meer dan alleen het eindbedrag. Een serieuze LMS-offerte specificeert: - Welk kostenmodel geldt en hoe gebruikers worden geteld - Wat is inbegrepen in de implementatie (datamigratie, thema, configuratie) - Welke integraties zijn inbegrepen en welke worden uurloon-gefactureerd - De hostingregeling en waar je data wordt opgeslagen - De supportscope: responstijden, updates en upgradebeleid - Vertrekvoorwaarden: kun je je data en content exporteren, en tegen welke kosten Toont een offerte alleen een prijs per gebruiker? Vraag dan naar het vijfjaarstotaal. Dat is het getal dat ertoe doet. ## 7. Veelgestelde vragen ### Wat kost Moodle zelf? Moodle is gratis te downloaden en te gebruiken. Voor Moodle LMS zelf betaal je geen licentiekosten per gebruiker, ongeacht het aantal gebruikers. Hosting, implementatie, beheer en eventuele commerciële plugins of aanvullende diensten kosten wel geld. Lees meer op onze [dienstpagina over LMS-ontwikkeling](https://ldesignmedia.nl/nl/diensten/lms-ontwikkeling). ### Wat kost het om een e-learning platform te laten maken? Een gerichte maatwerk-plugin begint bij enkele duizenden euro's. Een complete maatwerk leeromgeving met integraties begint doorgaans rond de 25.000 euro, afhankelijk van de scope. Bovenstaande bedragen zijn indicatief; elk project wordt individueel gescoped. ### Is een LMS zonder licentiekosten echt goedkoper? Bij organisaties vanaf enkele honderden gebruikers blijkt een professioneel beheerd open-source LMS in veel situaties over meerdere jaren financieel aantrekkelijker dan een per-gebruiker SaaS-model. De exacte omslag verschilt echter per situatie. Daaronder kunnen SaaS-instappakketten concurrerend zijn, tot je integraties nodig hebt of groeit. ### Kunnen we onze bestaande content meenemen bij een overstap? Vaak wel, maar dit hangt af van het gebruikte formaat en de beschikbare bronbestanden. SCORM-pakketten kunnen doorgaans worden overgezet naar een ander SCORM-compatibel LMS. Bij alle andere content kijken we samen wat er mogelijk is: welke exports biedt het huidige platform, is er een API beschikbaar, en kunnen voortgang, resultaten en certificaten mee? Dat inventariseren we bijvoorbeeld in een [quickscan van jullie huidige omgeving](https://ldesignmedia.nl/nl/moodle-quickscan). Content uit een leveranciersgebonden authoringtool is niet altijd als bewerkbaar bronbestand overdraagbaar; soms kun je alleen de gepubliceerde uitvoer exporteren. ## Conclusie De juiste vraag is niet "wat kost een LMS", maar "wat kost ons LMS ons over vijf jaar, inclusief alles". Voor organisaties met enkele honderden gebruikers of meer kan een professioneel beheerd open-source platform over meerdere jaren kosteneffectiever zijn, met name wanneer een SaaS-alternatief per gebruiker wordt afgerekend. Dit moet per situatie worden doorgerekend, inclusief implementatie, beheer, upgrades, interne uren en exitkosten. Benieuwd hoe dit er met jouw cijfers uitziet? Reken het door in onze [TCO-calculator](https://ldesignmedia.nl/nl/tco-calculator), vraag een gratis [Moodle-quickscan](https://ldesignmedia.nl/nl/moodle-quickscan) van je huidige omgeving aan, of [neem contact op](https://ldesignmedia.nl/nl/contact) voor een vrijblijvend gesprek. Ldesign Media is actief met Moodle sinds 2010 en heeft meer dan 300 maatwerkplugins opgeleverd; de kans is groot dat we jouw uitdaging al eens hebben opgelost. ## Bronnen - [Moodle.org](https://moodle.org): GPL-licentie en distributiemodel - [Gartner](https://www.gartner.com): Market Guide for Corporate Learning Technologies - [Fosway Group](https://www.fosway.com/9-grid/): 9-Grid Learning Systems - [Brandon Hall Group](https://brandonhall.com): LMS research - [Capterra](https://www.capterra.com/learning-management-system-software/): LMS-prijzen en reviews - [G2](https://www.g2.com/categories/learning-management-system-lms): LMS-prijzen en reviews - [Totara](https://totara.com/): product- en licentiedocumentatie - [TalentLMS](https://www.talentlms.com/prices): prijsoverzicht - [Docebo](https://www.docebo.com): productdocumentatie - [LearnUpon](https://www.learnupon.com): productdocumentatie --- ## How to Choose an LMS: A Practical Selection Guide (EN) Source: https://ldesignmedia.nl/en/blog/how-to-choose-an-lms Published: 2026-07-28 Choosing an LMS is a decision you will live with for five to ten years. Yet most selection processes start in the wrong place: with vendor demos instead of requirements. This guide turns that around. We walk through how to define what you actually need, how the three platform types (SaaS, open source, and custom development) compare, which questions to ask every vendor, and the pitfalls that cost organizations the most money. It is the same framework we use when advising organizations that come to us for LMS advice. ## 1. Start With Requirements, Not With Vendors Before you compare a single learning platform, write down what it must do. Five questions do most of the work. ### Who are your user groups? Employees, customers, partners, students, or a mix? Each group has different needs: external users need self-registration and possibly payment, employees need HR integration and certificates. A platform that is perfect for 200 employees can be the wrong choice for 20,000 customers. ### Which systems must it connect to? List every integration before you talk to vendors: HR systems (AFAS, SAP, Workday), SSO (Azure AD, SAML, SURFconext), planning tools, CRM, payment providers (iDEAL, Mollie). Integrations are where selection processes are won or lost, and where hidden costs live. ### What does compliance require? For Dutch and Belgian organizations, GDPR/AVG is rarely optional. Ask where data is hosted, who the data processor is, whether subprocessors outside the EU are involved, and how deletion requests are handled. Regulated sectors (healthcare, finance, aviation) add their own audit requirements. ### Where should the platform be hosted? Public cloud, private cloud, or on your own infrastructure? SaaS platforms decide for you. If your organization requires data on Dutch or EU soil, that requirement alone eliminates part of the market. ### What is the real budget? Not the license price: the five-year total, including implementation, integrations, content, and internal time. Our guide [What does an LMS cost?](https://ldesignmedia.nl/en/blog/what-does-an-lms-cost) breaks down realistic ranges per model. ## 2. Three Platform Types, One Decision Framework Comparing learning platforms becomes much simpler once you see that every LMS belongs to one of three types. ### SaaS LMS - **Strengths:** fast to start, vendor handles hosting and updates, predictable monthly cost at small scale - **Weaknesses:** per-user pricing that scales poorly, limited customization, vendor lock-in, features you pay for but never use - **Best for:** small, stable user groups with standard requirements ### Open source LMS (Moodle) - **Strengths:** no license costs, full data ownership, thousands of plugins, complete freedom to customize and integrate, no lock-in - **Weaknesses:** requires technical expertise for hosting and maintenance (your own team or a partner) - **Best for:** organizations above a few hundred users, with integration needs or compliance requirements ### Custom development (maatwerk) - **Strengths:** fits your processes exactly, your branding, your workflows, integrations with any system - **Weaknesses:** higher upfront investment, requires the right development partner - **Best for:** organizations whose training processes are a competitive advantage, or that no standard platform can serve In practice, the strongest solutions combine the last two: a custom learning environment built on open-source Moodle. That is the approach we have used for organizations like KLM and Nedap, and it is what our [LMS development service](https://ldesignmedia.nl/en/services/lms-development) delivers. ## 3. Comparing LMS Vendors: The Questions That Matter Whether you evaluate a SaaS vendor or an open-source LMS partner, these questions separate serious parties from polished sales decks: - How do you count users, and what happens to our price when we double? - Which integrations are standard, and which require custom work? - Where is our data hosted, and who are your subprocessors? - Can we export all data and content in standard formats if we leave? - What is included in support, and what are the response times? - Who actually builds our environment: your team, or subcontractors? - Can we speak with two reference customers in our sector? - What did your last three price increases look like? An LMS vendor in the Netherlands or Belgium has practical advantages for Dutch organizations: the same time zone, knowledge of AVG, and short communication lines. Ask for it explicitly. ## 4. The Five Most Expensive Pitfalls From 15+ years of Moodle projects and dozens of platform migrations, these are the mistakes we see organizations make most often: 1. **Choosing on features instead of fit.** A platform with 500 features sounds impressive; you will use 30. Unused features still cost money and complicate the interface. 2. **Ignoring the per-user scaling curve.** A sharp price for 100 users becomes a budget problem at 1,000. Always calculate the five-year scenario with growth. 3. **Underestimating lock-in.** Can you leave? Content in proprietary authoring tools, data in proprietary formats, and integrations built on vendor-only APIs make switching expensive by design. 4. **Treating the LMS as an IT purchase.** The platform succeeds or fails with didactics, content, and adoption. Involve L&D and end users from day one. 5. **No exit scenario in the contract.** Insist on data portability, export formats, and a defined transition period before you sign. ## 5. Why Open Source Removes the Biggest Risks Three of the five pitfalls above (pricing curve, lock-in, exit scenario) disappear almost automatically with an open-source LMS: - **No license costs:** your budget goes into the platform, not into the right to use it. Growth in users does not grow your license bill. - **No vendor lock-in:** the code is open, the database is documented, and any competent Moodle partner can take over your environment. You are never dependent on one company. - **Full data ownership:** you decide where data is hosted, which simplifies AVG compliance considerably. - **Proven at scale:** Moodle is the most widely used learning platform in the world, from universities to airlines. The trade-off is responsibility: someone has to host, update, and maintain the platform. For most organizations that is a specialized Moodle partner rather than an internal team. ## 6. Already on a Commercial Platform? Many organizations come to an LMS selection because their current platform no longer fits: prices rose at renewal, required features are missing, or support deteriorated. If you are comparing alternatives for a specific platform, our comparison pages show per vendor how a migration to Moodle works, what you keep, and what it costs. For example, read [Alternative to TalentLMS](https://ldesignmedia.nl/en/alternative-to-talentlms). Switching is usually less painful than staying one more contract period too long. ## 7. Your Selection Checklist Before you make the final decision, check: - Requirements documented and validated by L&D, HR, IT, and end users - Five-year TCO calculated for every shortlisted option (our [TCO calculator](https://ldesignmedia.nl/en/tco-calculator) helps) - Integration list tested against each vendor, in writing - Data hosting and AVG processing agreement verified - Exit scenario and export formats contractually agreed - References in your sector actually contacted ## 8. Frequently Asked Questions ### How long does an LMS selection process take? Allow two to four months: a few weeks for requirements, four to six weeks for vendor comparison and demos, and time for contract review. Rushing the requirements phase is the most common cause of a wrong choice. ### Is an open-source LMS professional enough for a company? Yes. Moodle is used worldwide by enterprises, governments, and universities for business-critical training. The difference lies in who implements and maintains it; with a professional partner you get the same service level as commercial vendors. ### Should we choose one LMS for everything, or multiple specialized tools? One central platform with good integrations almost always beats a collection of separate tools: one login, one reporting layer, one place where learning data lives. Specialized needs are usually better solved with plugins or custom development than with a second platform. ### What does LMS advice from an independent party cost? A selection guidance process typically ranges from a few thousand euros for a compact advice trajectory to more for a full tender. Our [Moodle quickscan](https://ldesignmedia.nl/en/moodle-quickscan) is a free starting point that maps your situation. ## Conclusion The best LMS is not the platform with the most features but the one that fits your requirements, your systems, and your five-year budget. Start with requirements, compare the three platform types honestly, and ask every vendor the uncomfortable questions about scaling, lock-in, and exit. Want a second opinion on your shortlist, or an honest look at whether open source fits your organization? Request a free [Moodle quickscan](https://ldesignmedia.nl/en/moodle-quickscan), explore our [LMS development service](https://ldesignmedia.nl/en/services/lms-development), or [contact us](https://ldesignmedia.nl/en/contact) directly. Since 2010 we have helped organizations build learning platforms on Moodle, with more than 300 custom plugins delivered along the way. --- ## How to Choose an LMS: A Practical Selection Guide (NL) Source: https://ldesignmedia.nl/nl/blog/lms-kiezen-waar-let-je-op Published: 2026-07-28 Een LMS-keuze heeft vaak gevolgen voor meerdere jaren. Implementatie, integraties, contentmigratie en gebruikersadoptie maken tussentijds overstappen kostbaar en tijdrovend. Toch begint de meeste selectie op de verkeerde plek: bij vendordemo's in plaats van bij je eisen. Deze gids draait dat om. We lopen door hoe je vaststelt wat je echt nodig hebt, hoe drie veelvoorkomende routes (SaaS, open source en maatwerk) zich verhouden, welke vragen je elke leverancier moet stellen en welke valkuilen organisaties het meeste geld kosten. Het is hetzelfde kader dat wij gebruiken bij LMS-advies aan organisaties. ## 1. Begin bij je eisen, niet bij leveranciers Voordat je ook maar een leerplatform vergelijkt, leg je vast wat het moet kunnen. Vijf vragen doen het meeste werk. ### Wie zijn je gebruikersgroepen? Medewerkers, klanten, partners, studenten of een mix? Elke groep heeft andere behoeften: externe gebruikers willen zelfregistratie en mogelijk betaling, medewerkers hebben HR-integratie en certificaten nodig. Een platform dat perfect is voor 200 medewerkers kan de verkeerde keuze zijn voor 20.000 klanten. ### Met welke systemen moet het koppelen? Noteer elke integratie voordat je met leveranciers praat: HR-systemen (AFAS, SAP, Workday), SSO (Azure AD, SAML, SURFconext), planningstools, CRM, betaalproviders (iDEAL, Mollie). Integraties zijn waar selectietrajecten worden gewonnen of verloren, en waar de verborgen kosten zitten. ### Wat vereist compliance? Voor Nederlandse en Belgische organisaties is de AVG zelden optioneel. Vraag waar data wordt gehost, wie de verwerker is, of er subverwerkers buiten de EU zijn en hoe verwijderverzoeken worden afgehandeld. Gereguleerde sectoren (zorg, financiën, luchtvaart) voegen daar hun eigen audit-eisen aan toe. ### Waar moet het platform draaien? Public cloud, private cloud of op eigen infrastructuur? Bij SaaS-platforms bepaalt de leverancier doorgaans welke hostingopties, cloudregio's en subverwerkers beschikbaar zijn. Controleer daarom of die mogelijkheden aansluiten op je interne privacy- en beveiligingseisen. Als jouw organisatie vereist dat data op Nederlandse of EU-bodem staat, valt daarmee al een deel van de markt af. ### Wat is het echte budget? Niet de licentieprijs: het vijfjaarstotaal, inclusief implementatie, integraties, content en interne tijd. Onze gids [Wat kost een LMS?](https://ldesignmedia.nl/nl/blog/wat-kost-een-lms) geeft realistische bandbreedtes per model. ## 2. Drie veelvoorkomende routes, een besliskader Voor een eerste vergelijking zijn drie veelvoorkomende routes te onderscheiden: een commercieel SaaS-LMS, een professioneel beheerd open-source-LMS en een grotendeels op maat ingerichte leeromgeving. In de praktijk bestaan ook hybride vormen, zoals open-source software als managed dienst of commerciële software met maatwerk. ### SaaS LMS - **Sterk:** relatief snel te implementeren, hosting en updates zijn inbegrepen en verantwoordelijkheden liggen grotendeels bij één leverancier - **Aandachtspunten:** aanpassingen zijn meestal beperkt tot de mogelijkheden van het product; kosten kunnen sterk meegroeien met gebruik, modules of aanvullende dienstverlening - **Past vaak bij:** organisaties die grotendeels met standaardprocessen kunnen werken en één leverancier verantwoordelijk willen maken voor software, hosting en updates ### Open-source-LMS (Moodle) - **Sterk:** geen licentiekosten voor Moodle LMS, toegang tot de broncode, ruime mogelijkheden voor aanpassing en meer vrijheid bij de keuze van hosting- en beheerpartner - **Aandachtspunten:** je organisatie of implementatiepartner moet hosting, beveiliging, updates, monitoring en continuïteit professioneel organiseren - **Past vaak bij:** organisaties boven de enkele honderden gebruikers, met integratiebehoefte of compliance-eisen ### Maatwerk - **Sterk:** sluit exact aan op je processen, je huisstijl, je workflows, integraties met elk systeem - **Aandachtspunten:** hogere initiële investering, vereist de juiste ontwikkelpartner - **Past vaak bij:** organisaties voor wie training een concurrentievoordeel is, of die geen standaardplatform kan bedienen In de praktijk combineren de sterkste oplossingen de laatste twee: een maatwerkleeromgeving gebouwd op open-source Moodle. Dat is de aanpak die wij hebben gebruikt voor organisaties als KLM en Nedap, en het is wat onze [dienst LMS-ontwikkeling](https://ldesignmedia.nl/nl/diensten/lms-ontwikkeling) levert. ## 3. LMS-leveranciers vergelijken: de vragen die ertoe doen Of je nu een SaaS-leverancier of een open-source-LMS-partner beoordeelt, deze vragen scheiden serieuze partijen van gepolijste verkooppresentaties: - Hoe tellen jullie gebruikers, en wat gebeurt er met onze prijs als wij verdubbelen? - Welke integraties zijn standaard en welke vereisen maatwerk? - Waar wordt onze data gehost en wie zijn jullie subverwerkers? - Kunnen we bij vertrek alle data en content exporteren in standaardformaten? - Wat valt onder support en wat zijn de responstijden? - Wie bouwt onze omgeving echt: jullie eigen team of onderaannemers? - Mogen we twee referentieklanten in onze sector spreken? - Hoe zagen jullie laatste drie prijsverhogingen eruit? Een leverancier in Nederland of België kan praktische voordelen bieden, zoals dezelfde tijdzone, communicatie in de eigen taal en ervaring met lokale inkoop-, privacy- en onderwijscontexten. Toets beveiliging en AVG-kennis echter inhoudelijk; een lokale vestiging is op zichzelf geen garantie. ## 4. De vijf duurste valkuilen Uit meer dan 15 jaar Moodle-projecten en tientallen platformmigraties: dit zijn de fouten die we organisaties het vaakst zien maken: 1. **Kiezen op functies in plaats van fit.** Een platform met 500 functies klinkt indrukwekkend; je gebruikt er 30. Ongebruikte functies kunnen de interface, inrichting en het beheer onnodig complex maken en zitten soms verwerkt in een duurdere bundel. 2. **De schaalcurve per gebruiker negeren.** Een scherpe prijs voor 100 gebruikers wordt een budgetprobleem bij 1.000. Reken altijd het vijfjaarsscenario door met groei. 3. **Leveranciersafhankelijkheid (vendor lock-in) onderschatten.** Kun je weg? Leverancierspecifieke API's, datamodellen en authoringtools kunnen een overstap technisch ingewikkeld en kostbaar maken. 4. **Het LMS behandelen als een IT-inkoop.** Het platform slaagt of faalt bij didactiek, content en adoptie. Betrek L&D en eindgebruikers vanaf dag één. 5. **Geen exit-scenario in het contract.** Leg dataportabiliteit, exportformaten en een overgangsperiode vast voordat je tekent. ## 5. Hoe open source bepaalde risico's kan verkleinen Open source neemt risico's zoals leveranciersafhankelijkheid, schaalbaarheid en dataportabiliteit niet automatisch weg. Het geeft een organisatie wel meer mogelijkheden om deze risico's zelf te beheersen. ### Geen licentiekosten per gebruiker Voor Moodle LMS betaal je geen softwarelicentie per gebruiker. Groei kan nog steeds leiden tot hogere kosten voor hosting, beheer, support en doorontwikkeling, maar niet tot een verplichte licentierekening vanuit de opensourcesoftware zelf. ### Meer keuzevrijheid in leveranciers Doordat de broncode beschikbaar is, kan de omgeving in beginsel door verschillende Moodle-specialisten worden beheerd en doorontwikkeld. De praktische overdraagbaarheid hangt wel af van goede documentatie, onderhoudbaar maatwerk, gebruikte plugins en contractuele afspraken. ### Meer invloed op hosting en gegevensverwerking Je kunt zelf eisen stellen aan infrastructuur, datalocatie, toegang, bewaartermijnen en subverwerkers. Dat kan helpen bij privacy- en beveiligingseisen, maar AVG-compliance blijft afhankelijk van techniek, processen en overeenkomsten. ### Bewezen inzet op grote schaal Moodle behoort wereldwijd tot de meest gebruikte leerplatforms en wordt ingezet door onderwijsinstellingen, overheden en bedrijven, van kleine leeromgevingen tot installaties met zeer grote gebruikersaantallen. De keerzijde is dat deze vrijheid ook verantwoordelijkheid meebrengt. Hosting, monitoring, beveiligingsupdates, back-ups, upgrades en continuïteit moeten professioneel worden georganiseerd, door een intern team of een gespecialiseerde partner. ## 6. Zit je al op een commercieel platform? Veel organisaties komen bij een LMS-selectie omdat hun huidige platform niet meer past: de prijs steeg bij verlenging, benodigde functies ontbreken of de support verslechterde. Als je alternatieven voor een specifiek platform vergelijkt, laten onze vergelijkingspagina's per leverancier zien hoe een migratie naar Moodle werkt, wat je behoudt en wat het kost. Lees bijvoorbeeld [Alternatief voor TalentLMS](https://ldesignmedia.nl/nl/alternatief-voor-talentlms). Een overstap vraagt voorbereiding, maar uitstel kan de afhankelijkheid en migratiekosten verder vergroten. Vergelijk daarom de kosten en risico's van migreren met die van nog een contractperiode blijven. ## 7. Jouw selectiechecklist Controleer voordat je de definitieve keuze maakt: - Eisen vastgelegd en gevalideerd door L&D, HR, IT en eindgebruikers - Vijfjaars-TCO berekend voor elke optie op de shortlist (onze [TCO-calculator](https://ldesignmedia.nl/nl/tco-calculator) helpt) - Integratielijst schriftelijk getoetst aan elke leverancier - Datahosting en AVG-verwerkersovereenkomst geverifieerd - Exit-scenario en exportformaten contractueel vastgelegd - Referenties in je sector daadwerkelijk gesproken ## 8. Veelgestelde vragen ### Hoe lang duurt een LMS-selectietraject? Een compact selectietraject duurt vaak twee tot vier maanden: enkele weken voor de eisen, vier tot zes weken voor vergelijking en demo's, en tijd voor contractbeoordeling. Bij aanbestedingen, uitgebreide securitybeoordelingen, pilots of complexe besluitvorming kan het traject zes tot twaalf maanden of langer duren. Haast in de eisenfase is de meest voorkomende oorzaak van een verkeerde keuze. ### Is een open-source-LMS professioneel genoeg voor een bedrijf? Ja. Moodle wordt wereldwijd ingezet door bedrijven, overheden en onderwijsinstellingen. Het uiteindelijke kwaliteits- en serviceniveau hangt af van de implementatie, hosting, beveiliging, beheerprocessen en de afspraken met de gekozen dienstverlener. ### Kiezen we een LMS voor alles, of meerdere gespecialiseerde tools? Een centraal LMS kan voordelen bieden voor identiteit, beheer, rapportage en gebruikerservaring. Toch kan een combinatie van gespecialiseerde tools beter passen wanneer leerprocessen sterk verschillen. Let dan vooral op SSO, gegevensuitwisseling, rapportage, eigenaarschap en een duidelijke systeemarchitectuur. Kies dus niet automatisch voor één of meerdere platforms, maar bepaal eerst welke functies centraal moeten worden georganiseerd. ### Wat kost LMS-advies van een onafhankelijke partij? Een selectiebegeleiding loopt van enkele duizenden euro's voor een compact adviestraject tot meer voor een volledige aanbesteding. Onze [Moodle-quickscan](https://ldesignmedia.nl/nl/moodle-quickscan) is een gratis startpunt dat je situatie in kaart brengt. ## Conclusie Het beste LMS is niet het platform met de meeste functies, maar het platform dat past bij je eisen, je systemen en je budget over vijf jaar. Begin bij je eisen, vergelijk de drie routes eerlijk en stel elke leverancier de ongemakkelijke vragen over schaling, leveranciersafhankelijkheid en vertrek. Wil je een second opinion op je shortlist, of een eerlijke blik op of open source bij je organisatie past? Vraag een gratis [Moodle-quickscan](https://ldesignmedia.nl/nl/moodle-quickscan) aan, bekijk onze [dienst LMS-ontwikkeling](https://ldesignmedia.nl/nl/diensten/lms-ontwikkeling), of [neem direct contact op](https://ldesignmedia.nl/nl/contact). Sinds 2010 helpen we organisaties met het bouwen van leerplatforms op Moodle, met inmiddels meer dan 300 maatwerkplugins. --- ## White Label Learning Platform: Sell Training Under Your Own Brand (EN) Source: https://ldesignmedia.nl/en/blog/white-label-learning-platform Published: 2026-07-29 A white label learning platform lets you offer online training completely under your own brand: your logo, your colours, your domain, your tone of voice, with no trace of the vendor behind it. For training providers, trainers, industry associations and agencies that resell courses, that brand control is not a luxury but a core business requirement. In this guide we explain what white label really means for learning platforms, who it serves, what your options are, and which pitfalls to avoid. At [Ldesign Media](https://ldesignmedia.nl/en) we build white label learning environments on Moodle for organizations that sell training or run academies under their own brand. This is what we have learned from 15+ years of doing exactly that. ## 1. What Does White Label Mean for a Learning Platform? White label originally comes from manufacturing: one producer makes the product, another company sells it under its own brand. For a learning platform it means the technology behind your academy is invisible to your learners and customers: - The platform runs on **your domain** (academy.yourbrand.com), not on a vendor subdomain - The interface carries **your corporate identity**: logo, colours, typography, imagery - Certificates, emails and notifications come **from your brand** - There is **no "powered by" badge**, no vendor logo in the footer, no vendor URL in the address bar That last point is where many SaaS tools quietly fail. More on that in the pitfalls section. ## 2. Who Needs a White Label Learning Platform? ### Training providers and trainers If you sell courses, the platform is your storefront. Customers who pay for your expertise should experience your brand from the first login to the final certificate. A visible third-party tool undermines the premium positioning you charge for. ### Industry associations and sector organizations Industry associations that offer certified training to members need an academy that members recognize as theirs, with certificates that carry the association's authority, not a software vendor's name. ### Agencies and resellers Marketing agencies, consultancies and e-learning studios that resell training to their clients need something stronger still: a platform where each of their clients gets a branded environment, managed centrally. That requires multi-tenancy, which we cover below. ### Corporates that want full brand control Even for internal academies, branding matters. An onboarding platform in the company's own look and feel, on its own domain, feels like part of the organization instead of another external tool. If you are weighing that scenario, our [corporate academy](https://ldesignmedia.nl/en/services/corporate-academy) service covers the full process. ## 3. The Options Spectrum: From Logo Swap to Fully Custom "White label" is a marketing term that covers very different realities. Broadly there are three levels. ### Level 1: SaaS with a logo swap Most commercial LMS vendors offer a white label tier: upload your logo, pick your accent colour, maybe map a custom domain. Fast to set up, but the limits show quickly: - The theme options stop at colours and a logo; the layout and interaction patterns stay the vendor's - Custom domains are often restricted to higher pricing tiers - URLs, mobile apps, login pages or email templates still reveal the vendor in places - **Per-user pricing** keeps growing with your success ### Level 2: SaaS with deeper theming Some platforms allow custom CSS and page builders. Better, but you are still theming inside someone else's product, renting your storefront by the month, per user. ### Level 3: Fully custom-branded open source Moodle With open source Moodle there is no vendor brand to hide in the first place. You own the platform, so white label is the default state, not an enterprise add-on: - **Your own theme**, designed and built in your corporate identity, down to the last pixel - **Your own domain and hosting**, with data stored where you choose (EU hosting for GDPR) - **Your own mobile app**: a branded Moodle app or a fully custom app in the app stores under your name - **Unlimited customization**: plugins, workflows, enrolment logic and integrations built for your business model - **No licence fees per user**: you pay for building and hosting, not for growth The trade-off is that you need a partner to build and maintain it. For organizations whose training is a revenue stream rather than a cost center, that investment behaves like any other business asset. ## 4. Multi-Tenancy: Selling Courses to Multiple Client Organizations The most powerful white label pattern is multi-tenancy: one platform, many branded sub-academies. Each tenant, whether a department, a franchise or a paying client organization, gets: - Its own subdomain or domain, logo and colour scheme - Its own course catalogue, users and managers - Its own certificates and email branding - Full separation of data and reporting Multi-tenancy is not part of standard Moodle, but it is exactly the kind of custom development we build: tenant provisioning, per-tenant payment flows and automated onboarding of new client organizations. A training provider can onboard a new corporate customer by creating a tenant, not by installing a new platform. This structure also future-proofs internal academies: an employee academy can later open selected tenants for customers, partners or resellers without rebuilding anything. ## 5. Monetization: Turning the Platform Into a Revenue Stream For commercial training businesses the platform must handle money as naturally as it handles courses. A custom Moodle setup supports the full commercial stack: - **Course sales per seat or per group:** individual checkout, or bulk enrolment where a client organization buys seats for its employees - **Payment integration:** iDEAL, credit card, SEPA and invoicing through processors like Mollie or Stripe - **Self-service purchasing:** a client admin buys 50 seats and assigns them to colleagues without touching your back office - **Subscriptions and bundles:** recurring access to a catalogue instead of one-off course sales - **Per-tenant pricing:** different catalogues and price lists per client organization Because there are no per-user platform fees, your margin per sold seat stays yours. With SaaS platforms, every new customer you win also increases your platform bill, sometimes dramatically. ## 6. Pitfalls to Avoid ### "White label" that still shows the vendor Before signing with a SaaS vendor, check every learner touchpoint: the login page, the URL, password reset emails, certificate PDFs, the mobile app listing, the help widget, the page footer. If any of them carry the vendor's brand, your customers will find it. Ask for a demo tenant and click through the entire journey. ### Per-user fees eating your margins A platform fee of €5-15 per user per month sounds reasonable at 100 learners. At 5,000 learners across 40 client organizations it becomes your largest cost line. Run the five-year numbers before committing, especially if selling training is your business model. ### Migrating content later is painful SCORM packages migrate reasonably; interactive content built in a vendor's proprietary authoring tool often does not. If portability matters, favour platforms and formats you can take with you. ### Underestimating maintenance An owned platform needs updates, security patches and hosting. Budget for managed hosting or a support contract, and treat it like any other business-critical system. The freedom of open source comes with the responsibility of ownership, which a good partner largely takes off your hands. ## 7. How to Decide Ask yourself three questions: 1. **Is training a revenue stream or an internal cost?** Revenue streams justify owning the platform. 2. **How many learners and client organizations will you serve in three years?** Multiply by the per-user SaaS fee and compare with a custom build. 3. **How important is complete brand control?** If your brand is what customers pay for, a logo swap is not enough. If you sell training, serve multiple client organizations, or simply refuse to rent your own storefront, a custom-branded Moodle platform is almost always the stronger long-term choice. ## Conclusion A white label learning platform is about owning the learner experience end to end: domain, design, data and margin. SaaS tools offer a quick start with hidden brand and cost ceilings. A custom-branded Moodle environment, optionally with custom-built multi-tenant structures, gives training providers, associations and resellers full control without per-user licence fees. At Ldesign Media we design and build [white label learning environments](https://ldesignmedia.nl/en/services/white-label-academy) on Moodle: your brand, your domain, multi-tenant structures for your clients, and payment integrations that turn courses into revenue. Curious what that looks like for your organization? [Get in touch](https://ldesignmedia.nl/en/contact) for a no-obligation consultation. --- ## White Label Learning Platform: Sell Training Under Your Own Brand (NL) Source: https://ldesignmedia.nl/nl/blog/white-label-leerplatform Published: 2026-07-29 Met een white label leerplatform bied je online training volledig onder je eigen merk aan: jouw logo, jouw kleuren, jouw domein, jouw toon, zonder enig spoor van de leverancier erachter. Voor opleiders, trainers, brancheorganisaties en agencies die cursussen doorverkopen is die merkcontrole geen luxe, maar een harde business requirement. In deze gids leggen we uit wat white label voor leerplatformen echt betekent, voor wie het is, welke opties je hebt en welke valkuilen je moet vermijden. Bij [Ldesign Media](https://ldesignmedia.nl/nl) bouwen we white label leeromgevingen op Moodle voor organisaties die training verkopen of academies onder hun eigen merk draaien. Dit is wat we daarvan hebben geleerd in meer dan 15 jaar. ## 1. Wat betekent white label bij een leerplatform? White label komt oorspronkelijk uit de industrie: één producent maakt het product, een ander bedrijf verkoopt het onder het eigen merk. Bij een leerplatform betekent het dat de technologie achter je academie onzichtbaar is voor je deelnemers en klanten: - Het platform draait op **jouw domein** (academie.jouwmerk.nl), niet op een subdomein van een leverancier - De interface draagt **jouw huisstijl**: logo, kleuren, typografie, beeldtaal - Certificaten, e-mails en notificaties komen **van jouw merk** - Er is **geen "powered by"-badge**, geen leverancierslogo in de footer, geen vreemde URL in de adresbalk Juist dat laatste punt is waar veel SaaS-tools stilletjes tekortschieten. Daarover meer bij de valkuilen. ## 2. Voor wie is een white label leerplatform bedoeld? ### Opleiders en trainers Als je cursussen verkoopt, is het platform je winkel. Klanten die betalen voor jouw expertise moeten jouw merk ervaren van de eerste login tot het laatste certificaat. Een zichtbare tool van een derde partij ondermijnt de premium positionering waarvoor je factureert. ### Brancheorganisaties en sectororganisaties Brancheorganisaties die gecertificeerde trainingen aan leden aanbieden, hebben een academie nodig die leden als die van henzelf herkennen, met certificaten die de autoriteit van de vereniging dragen en niet de naam van een softwareleverancier. ### Agencies en resellers Marketingbureaus, adviesbureaus en e-learningstudio's die training aan hun klanten doorverkopen, hebben iets sterkers nodig: een platform waar elke klant een eigen branded omgeving krijgt, centraal beheerd. Dat vraagt multi-tenancy, waar we verderop op ingaan. ### Bedrijven die volledige merkcontrole willen Ook voor interne academies telt branding. Een onboardingplatform in de eigen huisstijl, op het eigen domein, voelt als onderdeel van de organisatie en niet als weer een externe tool. Als je dat scenario afweegt: onze dienst [bedrijfsacademie](https://ldesignmedia.nl/nl/diensten/bedrijfsacademie) behandelt het volledige traject. ## 3. Het optiespectrum: van logo-wissel tot volledig maatwerk "White label" is een marketingterm die heel verschillende werkelijkheden dekt. Grofweg zijn er drie niveaus. ### Niveau 1: SaaS met een logo-wissel De meeste commerciële LMS-leveranciers bieden een white label variant: upload je logo, kies je accentkleur, misschien een eigen domein koppelen. Snel geregeld, maar de grenzen worden snel zichtbaar: - De thema-opties stoppen bij kleuren en een logo; de layout en interactiepatronen blijven die van de leverancier - Eigen domeinen zitten vaak alleen in de duurdere prijsstaffels - URL's, mobiele apps, loginpagina's of e-mailtemplates verraden de leverancier op plekken die je over het hoofd zag - **Prijs per gebruiker** blijft meegroeien met je succes ### Niveau 2: SaaS met diepere theming Sommige platforms staan eigen CSS en pagebuilders toe. Beter, maar je themat nog steeds binnen het product van een ander en je huurt je winkel per maand, per gebruiker. ### Niveau 3: Volledig gebrand open source Moodle Bij open source Moodle is er geen leveranciersmerk om te verbergen. Je bezit het platform, dus white label is de uitgangspositie en geen enterprise add-on: - **Je eigen thema**, ontworpen en gebouwd in je huisstijl, tot op de pixel - **Je eigen domein en hosting**, met data opgeslagen waar jij kiest (EU-hosting voor de AVG) - **Je eigen mobiele app**: een gebrande Moodle-app of een volledig eigen app in de app stores onder jouw naam - **Onbeperkt aanpasbaar**: plugins, workflows, inschrijflogica en integraties gebouwd voor jouw businessmodel - **Geen licentiekosten per gebruiker**: je betaalt voor bouwen en hosten, niet voor groei Het nadeel is dat je een partner nodig hebt om het te bouwen en te beheren. Voor organisaties waarvoor training een inkomstenstroom is in plaats van een kostenpost, gedraagt die investering zich als elke andere bedrijfsasset. ## 4. Multi-tenancy: cursussen verkopen aan meerdere klantorganisaties Het krachtigste white label patroon is multi-tenancy: één platform, vele gebrande sub-academies. Elke tenant, of het nu een afdeling, een franchise of een betalende klantorganisatie is, krijgt: - Een eigen subdomein of domein, logo en kleurstelling - Een eigen cursuscatalogus, gebruikers en beheerders - Eigen certificaten en e-mailbranding - Volledige scheiding van data en rapportages Multi-tenancy is geen standaard Moodle-functie, maar precies het soort maatwerk dat wij bouwen: tenant-provisioning, betaalflows per tenant en geautomatiseerde onboarding van nieuwe klantorganisaties. Een opleider neemt een nieuwe zakelijke klant in dienst door een tenant aan te maken, niet door een nieuw platform te installeren. Deze structuur maakt ook interne academies toekomstbestendig: een medewerkersacademie kan later geselecteerde tenants openen voor klanten, partners of resellers, zonder iets te herbouwen. ## 5. Verdienmodellen: van platform naar inkomstenstroom Voor commerciële opleiders moet het platform even vanzelfsprekend met geld omgaan als met cursussen. Een maatwerk Moodle-opzet ondersteunt de volledige commerciële stack: - **Cursusverkoop per seat of per groep:** individuele checkout, of bulk-inschrijving waarbij een klantorganisatie seats koopt voor haar medewerkers - **Betaalintegratie:** iDEAL, creditcard, SEPA en facturatie via processors zoals Mollie of Stripe - **Self-service aankopen:** een klantbeheerder koopt 50 seats en wijst ze toe aan collega's, zonder jouw backoffice - **Abonnementen en bundels:** terugkerende toegang tot een catalogus in plaats van eenmalige cursusverkoop - **Prijzen per tenant:** verschillende catalogi en prijslijsten per klantorganisatie Omdat er geen platformkosten per gebruiker zijn, blijft je marge per verkochte seat van jou. Bij SaaS-platforms vergroot elke nieuwe klant die je wint ook je platformrekening, soms fors. ## 6. Valkuilen die je moet vermijden ### "White label" dat de leverancier toch laat zien Controleer vóór ondertekening van een SaaS-contract elk deelnemerscontactpunt: de loginpagina, de URL, wachtwoord-resetmails, certificaat-pdf's, de vermelding van de mobiele app, de helpwidget, de footer van elke pagina. Als ergens het merk van de leverancier op prijkt, vinden je klanten het. Vraag om een demo-tenant en klik de hele journey door. ### Per-gebruikerskosten vreten je marge Een platformvergoeding van 5 tot 15 euro per gebruiker per maand klinkt redelijk bij 100 deelnemers. Bij 5.000 deelnemers verspreid over 40 klantorganisaties wordt het je grootste kostenpost. Reken de vijfjaarscijfers door voordat je committeert, zeker als het verkopen van training je businessmodel is. ### Content migreren is later pijnlijk SCORM-pakketten migreren redelijk; interactieve content die is gebouwd in de eigen authoringtool van een leverancier vaak niet. Als overdraagbaarheid telt, kies dan platforms en formaten die je kunt meenemen. ### Onderhoud onderschatten Een eigen platform vraagt updates, security patches en hosting. Budgetteer managed hosting of een supportcontract en behandel het als elk ander bedrijfskritisch systeem. De vrijheid van open source komt met de verantwoordelijkheid van eigenaarschap, en een goede partner neemt die grotendeels van je over. ## 7. Hoe je de keuze maakt Stel jezelf drie vragen: 1. **Is training een inkomstenstroom of een interne kostenpost?** Inkomstenstromen rechtvaardigen eigenaarschap van het platform. 2. **Hoeveel deelnemers en klantorganisaties bedien je over drie jaar?** Vermenigvuldig met de SaaS-prijs per gebruiker en vergelijk met een maatwerkbouw. 3. **Hoe belangrijk is volledige merkcontrole?** Als je merk is waar klanten voor betalen, is een logo-wissel niet genoeg. Verkoop je training, bedien je meerdere klantorganisaties of weiger je simpelweg je eigen winkel te huren, dan is een volledig gebrand Moodle-platform bijna altijd de sterkere keuze voor de lange termijn. ## Conclusie Een white label leerplatform draait om eigenaarschap van de leerervaring van begin tot eind: domein, design, data en marge. SaaS-tools bieden een snelle start met verborgen plafonds op branding en kosten. Een volledig gebrande Moodle-omgeving, eventueel met maatwerk multi-tenant structuren, geeft opleiders, brancheorganisaties en resellers volledige controle zonder licentiekosten per gebruiker. Bij Ldesign Media ontwerpen en bouwen we [white label leeromgevingen](https://ldesignmedia.nl/nl/diensten/white-label-leeromgeving) op Moodle: jouw merk, jouw domein, multi-tenant structuren voor je klanten en betaalintegraties die van cursussen omzet maken. Benieuwd hoe dat er voor jouw organisatie uitziet? [Neem contact op](https://ldesignmedia.nl/nl/contact) voor een vrijblijvend gesprek. --- ## Moodle Hosting and Maintenance: Why Generic Hosting Makes Moodle Slow (EN) Source: https://ldesignmedia.nl/en/blog/moodle-hosting-and-maintenance-guide Published: 2026-07-30 ## The short answer: Moodle needs hosting that is tuned to the application Moodle is not a simple website but a full-fledged PHP application with a relational database, file storage, caching, background tasks, and external integrations. On generic shared hosting it often seems to work fine, until the number of users grows or everyone opens an exam at the same time. That is when you find out whether the stack is truly tuned to Moodle. Moodle can scale to large numbers of users, but that requires a suitable architecture and carefully configured shared components ([MoodleDocs](https://docs.moodle.org/)). After more than fifteen years of working with Moodle environments, we know which choices determine speed and stability. This guide covers what good Moodle hosting requires, why Moodle sometimes feels slow, when self-hosting makes sense, and how to choose a hosting and maintenance partner. ## 1. What does Moodle need from the hosting stack? Which versions Moodle supports differs per release. Moodle 5.2 requires at least PHP 8.3 and also supports PHP 8.4. Supported databases are PostgreSQL, MySQL, MariaDB, Aurora MySQL, and Microsoft SQL Server; Oracle has not been supported since Moodle 5.0 ([Moodle Developer Resources](https://moodledev.io/general/releases)). Meeting these minimum requirements is not enough, though. For a fast and stable production environment, the components have to be configured as one coherent whole: - **OPcache enabled and properly configured**, so PHP does not have to recompile Moodle's many files on every request. - **Enough PHP workers and memory**: too few workers create queues at peak moments, too many put pressure on memory and the database. - **A tuned database** with enough memory for data and indexes, slow query monitoring, and table maintenance; there is no universal configuration, the right settings depend on actual usage. - **Cron running at least every minute** and monitored: a stalled task queue shows up as unsent emails, lagging synchronizations, and stuck reports. - **Appropriate caching**: the default configuration often suffices for small sites; Redis as a cache and session store is mainly worthwhile for larger and load-balanced setups, not as a fix for every performance complaint. - **Fast storage for moodledata**: in a cluster, shared storage latency is decisive; slow NFS storage can drag down the entire environment. - **Backups, monitoring, and an update process** covering Moodle, plugins, PHP, the database, and the operating system; Moodle ships a major release every six months and point releases roughly every two months containing bug fixes and security fixes. ## 2. Why does Moodle sometimes feel slow? A slow Moodle rarely has a single cause. In practice, these are the most common culprits: - **OPcache disabled or sized too small**, forcing scripts to be reprocessed over and over. - **Too few or wrongly sized PHP workers**, causing queues or memory pressure. - **A database that does not match usage**, for example insufficient memory, missing indexes, or one heavy report. - **Caching that is not configured appropriately** and ends up on slow storage or in the database. - **A backlog in cron and ad-hoc tasks**, making heavy processes compete with user traffic. - **Tables growing without bounds**, such as `logstore_standard_log`, historical grades, and session tables. - **Heavy or poorly optimized plugins** running inefficient queries on every page view. - **External integrations** (SSO, HR systems, video services) that a page request has to wait on. Optimization therefore starts with measuring, not guessing. Use a baseline measurement and monitoring to find out where time is actually spent (in the server, the database, cron, caching, external integrations, or the Moodle code itself) and then address the biggest bottleneck deliberately ([MoodleDocs](https://docs.moodle.org/)). Is your Moodle environment structurally slow? With a [Moodle quickscan](https://ldesignmedia.nl/en/moodle-quickscan) we systematically map configuration, database health, caching, cron, plugins, and security. ## 3. Self-hosting Moodle or choosing managed hosting? Self-hosting can work well when your organization has system administrators with PHP, database, and Linux knowledge as well as demonstrable Moodle experience, and when monitoring, backups, updates, and incidents have clear owners. You keep maximum control, but you also carry full responsibility for availability, security, and recovery. In practice we often see environments that were set up once and barely maintained since: they seem to run fine for a long time, until an upgrade becomes unavoidable or a security issue demands immediate action. With managed Moodle hosting, technical responsibility lies with a specialized team, from provisioning and tuning to updates, backups, and incident handling. Managed hosting does not automatically cover functional administration, so agree upfront who handles infrastructure, technical Moodle administration, functional administration, and custom code. For many organizations this is more predictable than spreading those tasks across internal staff and external suppliers. ## 4. What should managed Moodle maintenance include? Outsourcing administration only has value when the scope is clear. A serious maintenance agreement covers at least: - **Moodle and plugin updates**, with an agreement on how quickly security updates are assessed and where updates are tested first. - **Controlled version upgrades** with an inventory of plugins and custom code, a trial upgrade, testing, and a rollback plan; we bring outdated environments to a supported version via such a controlled migration path rather than keeping them artificially alive indefinitely. - **Security and hardening**, from OS and PHP patches and certificate management to secured admin accounts and logging of administrative actions. - **Monitoring with a clear SLA**: what is monitored, what happens when a threshold is crossed, and what "response time" actually means. - **Tested backups** of the database, moodledata, and code, with periodic restore tests and explicit agreements on RPO and RTO. - **Access to Moodle developers** who can investigate problems in plugins, cron tasks, and integrations; in our own marketing materials we use the experience of more than 300 developed Moodle plugins as an indication of that technical background. ## 5. GDPR and data residency Moodle processes a lot of personal data: names, email addresses, enrollments, progress, grades, exam attempts, and audit logs. The GDPR does not require this data to be stored in the Netherlands or the EU. What it does require is insight into where data is processed, who has access, and on what legal basis any transfer outside the European Economic Area takes place. Hosting within the Netherlands or the EEA makes that assessment more straightforward, among other things through shorter lines of communication and contracts under European law, but it does not automatically mean no international transfer takes place. So also check the subprocessors used for monitoring, email, support, and backups. Large US cloud providers can likewise be deployed in a GDPR-compliant way, provided they are deliberately configured with region selection, access management, and data processing agreements. Ask any provider at least where the primary data and backups are located, which subprocessors are used, who has technical access, and how data is deleted after the contract ends. ## 6. How do you choose a Moodle hosting partner? When comparing providers, these six questions help: - **Is the infrastructure tuned specifically to Moodle?** "We support PHP and MySQL" says little; ask about OPcache, PHP-FPM, Redis, cron, and moodledata. - **Who applies Moodle and plugin updates**, within what timeframe, and with what testing process? - **How are backups set up**, and are RPO and RTO defined and tested? - **What does the SLA cover**, and what is explicitly excluded? - **Can the provider debug Moodle itself**, looking further than whether the server is reachable? - **Can you take the environment and data with you** if you leave, including code, files, and configuration? ## Conclusion: hosting is part of the Moodle experience Users do not see PHP workers or database indexes; they only notice that a course opens quickly and an exam stays available. Infrastructure, configuration, plugins, and maintenance together determine how reliable the learning platform is. Good Moodle hosting therefore means a supported stack, appropriate capacity, monitoring, controlled updates, tested backups, and specialists who also understand the Moodle code. Curious about the technical state of your environment? With our [Moodle quickscan](https://ldesignmedia.nl/en/moodle-quickscan) we map configuration, database, cron, caching, plugins, and security, with concrete improvement points. Read more about [Moodle hosting and technical maintenance](https://ldesignmedia.nl/en/services/hosting) or [get in touch](https://ldesignmedia.nl/en/contact) for a no-obligation conversation. --- ## Moodle Hosting and Maintenance: Why Generic Hosting Makes Moodle Slow (NL) Source: https://ldesignmedia.nl/nl/blog/moodle-hosting-en-beheer Published: 2026-07-30 ## Het korte antwoord: Moodle vraagt om hosting die op de applicatie is afgestemd Moodle is geen eenvoudige website, maar een uitgebreide PHP-applicatie met een relationele database, bestandsopslag, caching, achtergrondtaken en externe koppelingen. Op generieke shared hosting lijkt dat vaak prima te werken, tot het aantal gebruikers groeit of iedereen tegelijk een toets opent. Dan pas blijkt of de stack echt op Moodle is afgestemd. Moodle kan opschalen naar grote aantallen gebruikers, maar dat vraagt een passende architectuur en zorgvuldig ingerichte gedeelde onderdelen ([MoodleDocs](https://docs.moodle.org/)). Na meer dan vijftien jaar werken met Moodle-omgevingen weten we welke keuzes bepalend zijn voor snelheid en stabiliteit. In deze gids bespreken we wat goede Moodle-hosting nodig heeft, waarom Moodle soms traag aanvoelt, wanneer zelf hosten verstandig is en hoe je een hosting- en beheerpartner kiest. ## 1. Wat heeft Moodle nodig van de hostingstack? Welke versies Moodle ondersteunt, verschilt per release. Moodle 5.2 vereist minimaal PHP 8.3 en ondersteunt ook PHP 8.4. Als database worden PostgreSQL, MySQL, MariaDB, Aurora MySQL en Microsoft SQL Server ondersteund; Oracle wordt sinds Moodle 5.0 niet meer ondersteund ([Moodle Developer Resources](https://moodledev.io/general/releases)). Aan deze minimumeisen voldoen is echter niet genoeg. Voor een snelle en stabiele productieomgeving moeten de onderdelen als één geheel zijn ingericht: - **OPcache ingeschakeld en passend geconfigureerd**, zodat PHP de vele Moodle-bestanden niet bij ieder verzoek opnieuw hoeft te compileren. - **Voldoende PHP-workers en geheugen**: te weinig workers veroorzaken wachtrijen op piekmomenten, te veel workers leggen druk op geheugen en database. - **Een getunede database** met voldoende geheugen voor data en indexen, monitoring van trage queries en onderhoud van tabellen; er bestaat geen universele configuratie, de juiste instellingen hangen af van het werkelijke gebruik. - **Cron die ten minste iedere minuut draait** en wordt gemonitord: een vastgelopen taakwachtrij uit zich als niet-verstuurde e-mails, achterlopende synchronisaties en hangende rapportages. - **Passende caching**: de standaardconfiguratie volstaat vaak voor kleine sites; Redis als cache- en sessiestore is vooral zinvol bij grotere en load-balanced omgevingen, niet als oplossing voor iedere performanceklacht. - **Snelle opslag voor moodledata**: in een cluster is de latency van gedeelde opslag bepalend; trage NFS-opslag kan de hele omgeving vertragen. - **Back-ups, monitoring en een updateproces** voor Moodle, plugins, PHP, database en besturingssysteem; er verschijnt iedere zes maanden een hoofdversie en ongeveer iedere twee maanden een point release met bugfixes en beveiligingsupdates. ## 2. Waarom voelt Moodle soms traag aan? Een trage Moodle heeft zelden één oorzaak. In de praktijk zijn dit de meest voorkomende boosdoeners: - **OPcache uit of te klein ingesteld**, waardoor scripts voortdurend opnieuw worden verwerkt. - **Te weinig of verkeerd gedimensioneerde PHP-workers**, met wachtrijen of geheugendruk als gevolg. - **Een database die niet bij het gebruik past**, bijvoorbeeld door onvoldoende geheugen, ontbrekende indexen of één zwaar rapport. - **Caching die niet passend is ingericht** en op trage opslag of in de database terechtkomt. - **Een achterstand in cron en ad-hoctaken**, waardoor zware processen met gebruikersverkeer concurreren. - **Onbegrensd groeiende tabellen** zoals `logstore_standard_log`, historische cijfers en sessietabellen. - **Zware of slecht geoptimaliseerde plugins** die bij ieder paginabezoek inefficiënte queries uitvoeren. - **Externe koppelingen** (SSO, HR-systemen, videodiensten) waarop tijdens een paginaverzoek wordt gewacht. Optimaliseren begint daarom met meten, niet met gokken. Bepaal eerst met een nulmeting en monitoring waar de tijd werkelijk wordt besteed (in de server, de database, cron, caching, externe koppelingen of de Moodle-code zelf) en pak daarna gericht de grootste bottleneck aan ([MoodleDocs](https://docs.moodle.org/)). Is jouw Moodle-omgeving structureel traag? Met een [Moodle-quickscan](https://ldesignmedia.nl/nl/moodle-quickscan) brengen we de configuratie, databasegezondheid, caching, cron, plugins en beveiliging systematisch in kaart. ## 3. Zelf Moodle hosten of kiezen voor managed hosting? Zelf hosten kan prima wanneer je organisatie systeembeheerders in huis heeft met kennis van PHP, databases en Linux én met aantoonbare Moodle-ervaring, en wanneer monitoring, back-ups, updates en incidenten duidelijk zijn belegd. Je houdt dan maximale controle, maar draagt ook zelf de volledige verantwoordelijkheid voor beschikbaarheid, beveiliging en herstel. In de praktijk zien we vaak omgevingen die ooit zijn ingericht en daarna beperkt zijn onderhouden: ze lijken lang probleemloos te draaien, tot een upgrade noodzakelijk wordt of een beveiligingslek direct handelen vereist. Bij managed Moodle-hosting ligt de technische verantwoordelijkheid bij een gespecialiseerd team, van provisioning en tuning tot updates, back-ups en incidentafhandeling. Managed hosting neemt niet automatisch ook het functionele beheer over; maak daarom vooraf duidelijke afspraken over wie infrastructuur, technisch Moodle-beheer, functioneel beheer en maatwerk oppakt. Voor veel organisaties is dat voorspelbaarder dan deze taken te verdelen over interne medewerkers en externe leveranciers. ## 4. Wat moet managed Moodle-beheer omvatten? Beheer uitbesteden heeft alleen waarde als de scope duidelijk is. Een serieus beheercontract dekt in ieder geval: - **Updates van Moodle en plugins**, met een afspraak over hoe snel beveiligingsupdates worden beoordeeld en waar updates eerst worden getest. - **Gecontroleerde versie-upgrades** met inventarisatie van plugins en maatwerk, een proefupgrade, tests en een rollbackplan; verouderde omgevingen brengen wij via zo'n gecontroleerd migratiepad naar een ondersteunde versie in plaats van ze onbeperkt kunstmatig in stand te houden. - **Beveiliging en hardening**, van OS- en PHP-patches en certificaatbeheer tot beveiligde beheeraccounts en logging van beheerhandelingen. - **Monitoring met een duidelijke SLA**: wat wordt gemonitord, wat gebeurt er bij een overschrijding en wat betekent "reactietijd" precies. - **Geteste back-ups** van database, moodledata en code, met periodieke restore-tests en expliciete afspraken over RPO en RTO. - **Toegang tot Moodle-ontwikkelaars** die problemen in plugins, cron-taken en integraties kunnen onderzoeken; in ons eigen promotiemateriaal gebruiken we inmiddels de ervaring van meer dan 300 ontwikkelde Moodle-plugins als indicatie van die technische achtergrond. ## 5. AVG en dataresidentie Moodle verwerkt veel persoonsgegevens: namen, e-mailadressen, inschrijvingen, voortgang, cijfers, toetspogingen en auditlogs. De AVG schrijft niet voor dat deze gegevens in Nederland of de EU moeten worden opgeslagen. Wel moet je inzicht hebben in waar ze worden verwerkt, wie toegang heeft en op welke juridische grondslag eventuele doorgifte buiten de Europese Economische Ruimte plaatsvindt. Hosting binnen Nederland of de EER maakt die beoordeling overzichtelijker, onder meer door kortere lijnen en contracten onder Europees recht, maar betekent niet automatisch dat er geen internationale doorgifte plaatsvindt. Controleer daarom ook de subprocessors voor monitoring, e-mail, support en back-ups. Ook grote Amerikaanse cloudproviders kunnen AVG-conform worden ingezet, mits bewust ingericht met regioselectie, toegangsbeheer en verwerkersafspraken. Vraag een partij in ieder geval waar primaire data en back-ups staan, welke subprocessors worden gebruikt, wie technisch toegang heeft en hoe gegevens na afloop van het contract worden verwijderd. ## 6. Hoe kies je een Moodle-hostingpartner? Bij het vergelijken van providers helpen deze zes vragen: - **Is de infrastructuur specifiek op Moodle afgestemd?** "Wij ondersteunen PHP en MySQL" zegt weinig; vraag naar OPcache, PHP-FPM, Redis, cron en moodledata. - **Wie voert Moodle- en pluginupdates uit**, binnen welke termijn en met welk testproces? - **Hoe zijn back-ups ingericht** en zijn RPO en RTO vastgelegd en getest? - **Wat dekt de SLA** en wat valt er expliciet buiten? - **Kan de partij Moodle zelf debuggen**, dus verder kijken dan of de server bereikbaar is? - **Kun je de omgeving en data meenemen** als je vertrekt, inclusief code, bestanden en configuratie? ## Conclusie: hosting is onderdeel van de Moodle-ervaring Gebruikers zien geen PHP-workers of database-indexen; zij merken alleen dat een cursus snel opent en een toets beschikbaar blijft. Infrastructuur, configuratie, plugins en beheer bepalen samen hoe betrouwbaar het leerplatform is. Goede Moodle-hosting betekent daarom een ondersteunde stack, passende capaciteit, monitoring, gecontroleerde updates, geteste back-ups en specialisten die ook de Moodle-code begrijpen. Benieuwd naar de technische staat van jouw omgeving? Met onze [Moodle-quickscan](https://ldesignmedia.nl/nl/moodle-quickscan) brengen we configuratie, database, cron, caching, plugins en beveiliging in kaart, met concrete verbeterpunten. Lees meer over [Moodle-hosting en technisch beheer](https://ldesignmedia.nl/nl/diensten/hosting) of [neem contact op](https://ldesignmedia.nl/nl/contact) voor een vrijblijvend gesprek. --- ## Moodle Migration Guide: Switching LMS or Upgrading Legacy Moodle to 5.x (EN) Source: https://ldesignmedia.nl/en/blog/moodle-migration-guide Published: 2026-07-30 ## Two Very Different Projects Called "Moodle Migration" When an organization talks about a Moodle migration, they mean one of two things. Either they are moving to Moodle from another learning platform (aNewSpring, Studytube, Totara, Canvas, or a homegrown LMS), or they are moving an existing Moodle installation forward, from a legacy 2.x or 3.x version to a current 5.x release. Both are migrations. Both fail in predictable ways when they are treated as an IT checkbox instead of a planned project. At Ldesign Media we have been executing both scenarios since 2010: LMS migrations for organizations replacing commercial platforms, and Moodle upgrades for environments that have been running since the Moodle 1.8 and 2.x era. We support every Moodle version from 2.0 up to the latest 5.2, which means no environment is too old to bring forward safely. This guide walks through both scenarios and the step-by-step plan that makes them succeed. ## Scenario A: Migrating to Moodle From Another LMS Switching learning platforms ("lms overstappen") is primarily a data project, not a software installation. Moodle itself can be set up in a day. The work is getting your users, courses, content, and history across without loss. ### What can and cannot be migrated - **User accounts.** Names, email addresses, and organizational structure (departments, cohorts) migrate well via CSV or direct database mapping. Passwords usually cannot: most platforms store hashes that Moodle cannot verify, so plan a password reset flow or switch to SSO at the same time. - **Course content.** SCORM packages are portable by design and import into Moodle's SCORM activity directly. Native content (pages, quizzes, assignments built inside the old platform) is not portable; it must be rebuilt or converted. Budget time for this: it is consistently the most underestimated part of an LMS migration. - **Completion history and certificates.** For compliance training, completion records often carry legal weight. Export them from the source platform, map them to Moodle's completion and grade structures, or archive them in a reporting layer if live import is not meaningful. - **SSO and integrations.** A platform switch is the ideal moment to move authentication to your central identity provider (Entra ID/Azure AD, SAML, OAuth2) and to reconnect HR sync, so user provisioning is automatic from day one. If you are specifically evaluating the move away from aNewSpring, our [comparison of aNewSpring and Moodle](https://ldesignmedia.nl/en/alternative-to-anewspring) covers the functional and licensing differences in detail, and what a migration trajectory looks like. ### Practical advice for the switch Run both platforms in parallel for one enrollment period where possible. Migrate one pilot group first, validate their experience and their completion data, and only then move the full organization. And freeze content changes on the old platform from the moment the data export is taken, or you will be migrating the same courses twice. ## Scenario B: Upgrading a Legacy Moodle Installation The second scenario is an existing Moodle that has fallen behind. We regularly encounter Moodle 2.7, 3.1, or 3.5 in production: versions that stopped receiving security patches years ago. Upgrading ("moodle upgraden") from these versions to 5.x is very doable, but it is not a single button press. ### Why legacy upgrades require planning - **Stepwise upgrades.** Moodle does not support jumping from 2.x directly to 5.x in one step. Depending on the starting version, the upgrade path goes through intermediate releases, each with its own database migrations. A Moodle 2.7 site, for example, typically upgrades via 3.x milestones before reaching current versions. - **Plugin compatibility.** Every installed plugin must be checked against the target version. Community plugins may have been abandoned; custom plugins may use APIs that no longer exist. This audit decides the real timeline of the project. - **Theme rebuild.** Themes from the 2.x and early 3.x era do not survive into modern Moodle, which moved to Bootstrap-based theming. A legacy upgrade almost always includes a theme rebuild or a move to a maintained theme with your branding applied. - **PHP and database versions.** Each Moodle version requires a matching PHP version. Moving from Moodle 2.x to 5.x usually means the server stack itself (PHP 5.x or 7.x to PHP 8.2+) must be upgraded in step with Moodle. Organizations sometimes ask whether they should instead reinstall Moodle from scratch and migrate content into a clean site. For heavily customized legacy installs, that can genuinely be the better route. The audit phase answers this question with facts instead of gut feeling. ## The Migration Plan, Step by Step Whether you are switching platforms or upgrading Moodle, the shape of a successful project is the same. ### Step 1: Inventory and audit Catalog everything before touching anything: Moodle or platform version, installed plugins and their purpose, custom code, integrations (SSO, HR systems, payment providers), content volume, user counts, and the reports the organization depends on. For legacy Moodle upgrades, this audit determines the upgrade path and flags blocking plugins. For LMS switches, it determines what is migrated, rebuilt, or retired. ### Step 2: Data mapping Define where each data category lands in the new environment: users to accounts and cohorts, courses to courses and categories, completions to completion records or an archive. Write the mapping down and have the business owner sign off on it. Discovering mid-migration that the completion history mapping is wrong is expensive; discovering it in a mapping document is free. ### Step 3: Test migration on a copy Never rehearse on production. Take a full copy of the source environment, run the complete migration or upgrade on a staging server, and measure it: how long does it take, what breaks, what data does not survive. For legacy Moodle upgrades this also means running the plugin compatibility check and the actual upgrade scripts, not just reading the release notes. ### Step 4: Validation with real users Let course owners and a group of end users validate the migrated environment. Check course content, gradebooks, completion records, certificates, and reports against the source. Validation by the people who own the data catches the edge cases that technical checks miss, like gradebook aggregation settings that produce different totals than the old system. ### Step 5: Plan the cutover and downtime Schedule the production migration in a low-usage window, communicate downtime in advance, take a final fresh backup or export, and freeze content changes. A well-rehearsed migration typically means hours of downtime, not days, because every step has already been executed on staging. ### Step 6: Go live, verify, and keep a fallback After cutover, verify the critical flows immediately: login and SSO, course access, a quiz attempt, a completion registration, cron execution. Keep the old environment available read-only for a defined period. You will rarely need it, but the one time you do, it is priceless. Our free [Moodle upgrade checklist](https://ldesignmedia.nl/en/moodle-upgrade-checklist) structures these steps for a legacy Moodle upgrade specifically: download it if you are preparing a 3.x or 4.x to 5.x upgrade. ## Common Pitfalls We See in Practice After fifteen years of migrations, the failure modes repeat themselves: - **Corrupt or incomplete backups.** The source backup fails to restore and the project stalls on day one. Test every backup by actually restoring it before the migration starts. - **Custom plugins blocking the upgrade.** An organization depends on a custom plugin built for Moodle 2.5, and nobody knows who wrote it. The plugin must be updated, replaced, or retired before the upgrade can proceed. As a team that has delivered 300+ custom Moodle plugins, updating or rebuilding abandoned custom plugins is a large share of our migration work. - **Gradebook and completion edge cases.** Grade histories, manual grade overrides, and completion states set by now-removed plugins behave unexpectedly after migration. These need explicit validation, not assumptions. - **Underestimated content rebuild.** Native content from the old LMS cannot be converted automatically. Teams that discover this halfway through have already spent their budget on the technical migration. - **No fallback plan.** The old environment is decommissioned the day after go-live, and two weeks later someone needs a completion record that only exists there. ## When to Bring in a Moodle Migration Specialist Small, standard environments migrate fine with an experienced in-house admin. Bring in a Moodle migration specialist when any of these apply: the environment is heavily customized, completion history has compliance value, multiple integrations (SSO, HR, e-commerce) are involved, the version gap spans several major releases, or the platform simply cannot afford a failed first attempt. The cost of specialist help is predictable; the cost of a botched migration during enrollment week is not. Planning an LMS switch or a legacy Moodle upgrade? Read more about our [Moodle upgrade and migration services](https://ldesignmedia.nl/en/services/moodle-upgrade-migration), download the [upgrade checklist](https://ldesignmedia.nl/en/moodle-upgrade-checklist), or [contact us](https://ldesignmedia.nl/en/contact) to discuss your environment. We migrate and upgrade every Moodle version from 2.0 to 5.2. --- ## Moodle Migration Guide: Switching LMS or Upgrading Legacy Moodle to 5.x (NL) Source: https://ldesignmedia.nl/nl/blog/moodle-migratie-stappenplan Published: 2026-07-30 ## Twee heel verschillende projecten die "Moodle migratie" heten Wanneer een organisatie over een Moodle migratie praat, bedoelt ze een van twee dingen. Of ze stappen over naar Moodle vanaf een ander leerplatform (aNewSpring, Studytube, Totara, Canvas of een zelfgebouwd LMS), of ze brengen een bestaande Moodle-installatie vooruit, van een legacy 2.x- of 3.x-versie naar een actuele 5.x-release. Beide zijn migraties. Beide mislukken op voorspelbare manieren wanneer ze worden behandeld als een ICT-vinkje in plaats van een gepland project. Bij Ldesign Media voeren we beide scenario's al uit sinds 2010: LMS-migraties voor organisaties die commerciële platforms vervangen, en Moodle-upgrades voor omgevingen die al draaien sinds het Moodle 1.8- en 2.x-tijdperk. We ondersteunen elke Moodle-versie van 2.0 tot en met de nieuwste 5.2, wat betekent dat geen omgeving te oud is om veilig naar voren te halen. Deze gids behandelt beide scenario's en het stappenplan dat ze tot een succes maakt. ## Scenario A: overstappen naar Moodle vanaf een ander LMS Een leerplatform vervangen ("lms overstappen") is vooral een dataproject, geen software-installatie. Moodle zelf is in een dag ingericht. Het werk zit in het zonder verlies overbrengen van je gebruikers, cursussen, content en historie. ### Wat wel en niet te migreren is - **Gebruikersaccounts.** Namen, e-mailadressen en organisatiestructuur (afdelingen, cohorten) migreren goed via CSV of directe database-mapping. Wachtwoorden meestal niet: de meeste platforms slaan hashes op die Moodle niet kan verifiëren, dus plan een wachtwoord-resetflow of schakel tegelijk over naar SSO. - **Cursuscontent.** SCORM-pakketten zijn per ontwerp overdraagbaar en importeren direct in de SCORM-activiteit van Moodle. Native content (pagina's, quizzen en opdrachten die in het oude platform zijn gebouwd) is niet overdraagbaar; die moet worden herbouwd of geconverteerd. Reserveer hiervoor tijd: het is consequent het meest onderschatte deel van een LMS-migratie. - **Voltooiingshistorie en certificaten.** Bij verplichte trainingen hebben voltooiingsregistraties vaak juridisch gewicht. Exporteer ze uit het bronplatform, map ze naar de voltooiings- en cijferstructuren van Moodle, of archiveer ze in een rapportagelaag als live import niet zinvol is. - **SSO en integraties.** Een platformwissel is het ideale moment om authenticatie naar je centrale identity provider te verplaatsen (Entra ID/Azure AD, SAML, OAuth2) en de HR-koppeling opnieuw te verbinden, zodat gebruikersvoorziening vanaf dag een automatisch verloopt. Evalueer je specifiek de overstap weg van aNewSpring? Onze [vergelijking van aNewSpring en Moodle](https://ldesignmedia.nl/nl/alternatief-voor-anewspring) behandelt de functionele en licentieverschillen in detail, en hoe een migratietraject eruitziet. ### Praktisch advies voor de overstap Draai waar mogelijk één inschrijvingsperiode beide platforms parallel. Migreer eerst een pilotgroep, valideer hun ervaring en hun voltooiingsdata, en verplaats pas daarna de hele organisatie. En bevries contentwijzigingen op het oude platform vanaf het moment dat de data-export is gemaakt, anders migreer je dezelfde cursussen twee keer. ## Scenario B: een legacy Moodle-installatie upgraden Het tweede scenario is een bestaande Moodle die is achtergebleven. We komen regelmatig Moodle 2.7, 3.1 of 3.5 in productie tegen: versies die al jaren geen beveiligingspatches meer ontvangen. Upgraden ("moodle upgraden") van deze versies naar 5.x is goed te doen, maar het is geen enkele knopdruk. ### Waarom legacy-upgrades planning vereisen - **Stapsgewijs upgraden.** Moodle ondersteunt geen sprong van 2.x direct naar 5.x in een stap. Afhankelijk van de beginversie loopt het upgradepad via tussenreleases, elk met eigen databasemigraties. Een Moodle 2.7-site upgrade bijvoorbeeld doorgaans via 3.x-mijlpalen voordat actuele versies bereikt worden. - **Plugincompatibiliteit.** Elke geïnstalleerde plugin moet worden getoetst aan de doelversie. Community-plugins kunnen verlaten zijn; maatwerkplugins kunnen API's gebruiken die niet meer bestaan. Deze audit bepaalt de echte doorlooptijd van het project. - **Theme-rebuild.** Themes uit het 2.x- en vroege 3.x-tijdperk overleven de overstap naar modern Moodle niet, dat is overgegaan op Bootstrap-gebaseerde theming. Een legacy-upgrade omvat bijna altijd een theme-rebuild of een overstap naar een onderhouden theme met jouw huisstijl toegepast. - **PHP- en databaseversies.** Elke Moodle-versie vereist een passende PHP-versie. De stap van Moodle 2.x naar 5.x betekent meestal dat de serverstack zelf (PHP 5.x of 7.x naar PHP 8.2+) gelijk op moet met Moodle. Organisaties vragen soms of ze Moodle niet beter schoon kunnen herinstalleren en content naar een nieuwe site kunnen migreren. Bij sterk aangepaste legacy-installaties kan dat oprecht de betere route zijn. De auditfase beantwoordt die vraag met feiten in plaats van onderbuikgevoel. ## Het migratieplan, stap voor stap Of je nu van platform wisselt of Moodle upgrade: de vorm van een succesvol project is dezelfde. ### Stap 1: Inventarisatie en audit Catalogiseer alles voordat je iets aanraakt: Moodle- of platformversie, geïnstalleerde plugins en hun doel, maatwerkcode, integraties (SSO, HR-systemen, betaalproviders), contentvolume, gebruikersaantallen en de rapportages waar de organisatie op leunt. Bij legacy Moodle-upgrades bepaalt deze audit het upgradepad en signaleert hij blokkerende plugins. Bij een LMS-wissel bepaalt hij wat gemigreerd, herbouwd of uitgefaseerd wordt. ### Stap 2: Data-mapping Bepaal waar elke datacategorie in de nieuwe omgeving landt: gebruikers naar accounts en cohorten, cursussen naar cursussen en categorieën, voltooiingen naar voltooiingsregistraties of een archief. Leg de mapping vast en laat de business owner er akkoord op geven. Halverwege de migratie ontdekken dat de voltooiingshistorie-mapping verkeerd is, is duur; hetzelfde ontdekken in een mappingdocument is gratis. ### Stap 3: Testmigratie op een kopie Oefen nooit op productie. Maak een volledige kopie van de bronomgeving, voer de complete migratie of upgrade uit op een stagingserver en meet alles: hoe lang duurt het, wat breekt, welke data overleeft het niet. Bij legacy Moodle-upgrades betekent dit ook de plugincompatibiliteitscontrole en de echte upgradescripts draaien, niet alleen de release notes lezen. ### Stap 4: Validatie met echte gebruikers Laat cursuseigenaren en een groep eindgebruikers de gemigreerde omgeving valideren. Controleer cursuscontent, cijferboeken, voltooiingsregistraties, certificaten en rapportages tegen de bron. Validatie door de mensen die eigenaar zijn van de data vangt de randgevallen die technische controles missen, zoals aggregatie-instellingen van het cijferboek die andere totalen opleveren dan het oude systeem. ### Stap 5: Plan de cutover en downtime Plan de productiemigratie in een rustig venster, communiceer de downtime vooraf, maak een laatste verse back-up of export en bevries contentwijzigingen. Een goed geoefende migratie betekent uren downtime in plaats van dagen, omdat elke stap al op staging is uitgevoerd. ### Stap 6: Livegang, verificatie en een terugvaloptie Verifieer na de cutover direct de kritieke flows: login en SSO, cursustoegang, een quizpoging, een voltooiingsregistratie, cron-uitvoering. Houd de oude omgeving voor een afgesproken periode alleen-lezen beschikbaar. Je zult hem zelden nodig hebben, maar die ene keer dat het wel zo is, is hij van onschatbare waarde. Onze gratis [Moodle upgrade checklist](https://ldesignmedia.nl/nl/moodle-upgrade-checklist) structureert deze stappen specifiek voor een legacy Moodle-upgrade: download hem als je een 3.x- of 4.x- naar 5.x-upgrade voorbereidt. ## Valkuilen die we in de praktijk zien Na vijftien jaar migraties herhalen de faalmodi zichzelf: - **Corrupte of incomplete back-ups.** De bronback-up blijkt niet te restoren en het project staat op dag een stil. Test elke back-up door hem daadwerkelijk terug te zetten voordat de migratie begint. - **Maatwerkplugins die de upgrade blokkeren.** Een organisatie is afhankelijk van een maatwerkplugin gebouwd voor Moodle 2.5, en niemand weet wie hem geschreven heeft. De plugin moet worden bijgewerkt, vervangen of uitgefaseerd voordat de upgrade verder kan. Als team dat meer dan 300 maatwerk Moodle-plugins heeft opgeleverd, is het bijwerken of herbouwen van verlaten maatwerkplugins een groot deel van ons migratiewerk. - **Randgevallen in cijferboek en voltooiing.** Cijferhistorie, handmatige cijferoverschrijvingen en voltooiingsstatussen die door inmiddels verwijderde plugins zijn gezet, gedragen zich onverwacht na migratie. Die vragen expliciete validatie, geen aannames. - **Onderschatte content-rebuild.** Native content uit het oude LMS is niet automatisch te converteren. Teams die dit halverwege ontdekken, hebben hun budget al aan de technische migratie besteed. - **Geen terugvalplan.** De oude omgeving wordt de dag na livegang afgebouwd, en twee weken later heeft iemand een voltooiingsregistratie nodig die alleen daar bestaat. ## Wanneer schakel je een Moodle-migratiespecialist in? Kleine, standaard omgevingen migreren prima met een ervaren beheerder in huis. Schakel een Moodle migratie specialist in wanneer een van deze situaties geldt: de omgeving is sterk aangepast, de voltooiingshistorie heeft complianceswaarde, er zijn meerdere integraties (SSO, HR, e-commerce) in het spel, het versieverschil beslaat meerdere major releases, of het platform kan simpelweg geen mislukte eerste poging veroorloven. De kosten van specialistische hulp zijn voorspelbaar; de kosten van een mislukte migratie tijdens de inschrijfweek niet. Ben je een LMS-overstap of een legacy Moodle-upgrade aan het plannen? Lees meer over onze [diensten voor Moodle upgrade en migratie](https://ldesignmedia.nl/nl/diensten/moodle-upgrade-migratie), download de [upgrade checklist](https://ldesignmedia.nl/nl/moodle-upgrade-checklist), of [neem contact op](https://ldesignmedia.nl/nl/contact) om jouw omgeving te bespreken. Wij migreren en upgraden elke Moodle-versie van 2.0 tot en met 5.2. --- ## The Moodle Marketplace Is Here: What the Launch Means for the Plugin Ecosystem (EN) Source: https://ldesignmedia.nl/en/blog/moodle-marketplace-is-here Published: 2026-07-24 On 20 July 2026 Moodle officially launched the [Moodle Marketplace](https://marketplace.moodle.com), and with it closed a chapter that lasted fifteen years: the classic Plugins Directory. If you now visit [moodle.org/plugins](https://moodle.org/plugins), you are redirected straight to the new marketplace. This is not a cosmetic redesign. It is a new platform with a new model — and for anyone who builds, buys, or maintains Moodle plugins, it changes how the ecosystem works. "At Moodle, we're committed to building a learning ecosystem that can extend as your needs evolve — without replacing what's already working," said Moodle CEO Scott Anderberg in the [launch announcement](https://moodle.com/news/moodle-marketplace-is-here/). "That's exactly what Moodle Marketplace is built to support." The launch catalogue counts **1,517 listings**, with version filters stretching from Moodle 1.9 all the way to 5.2, plus badge filters for Certified Integrations and Certified Partners. ![The Moodle Marketplace plugin catalogue — 1,517 listings at launch](/images/blog/moodle-marketplace/marketplace-plugins-browse.png) ## What Is New for Users The biggest improvement is discoverability. The marketplace introduces **natural-language search**: instead of guessing the exact technical name of a plugin, you can describe what you need. Under the hood, plugins that were updated recently or are maintained regularly are **prioritised by default**, so abandoned code sinks instead of cluttering the results. Plugin pages are now standardised. Every listing shows the same structured information — supported versions, maintenance status, and statistics — organised in tabs for Description, Support, Versions, Translations, and Stats. That consistency makes comparing two plugins for the same job far less painful than it used to be. The second big change: free and paid plugins now live in **one catalogue**. You can install a free plugin or purchase a paid one without leaving the site, thanks to built-in e-commerce. Paid listings show their price options, a "Buy now" button, the seller's Terms of Sale, and a "Reviewed annually for quality" label. One detail we particularly like: plugins last released **three or more years ago are hidden by default**. There is a toggle to include them, but out of the box the catalogue favours living software. For a community where adopting an unmaintained plugin is the classic pitfall, that matters. ## What Is New for Developers For plugin developers, the marketplace opens something the directory never offered: **a direct channel to sell their work**. Paid plugins go through an internal review by Moodle HQ and are re-reviewed annually. From agencies that went through the process, we know a Privacy API provider is mandatory and automated tests are expected for paid plugins — which raises the bar for everyone, in a good way. On the commercial side, sellers can offer fixed annual pricing, monthly subscriptions, or tiered models, with prices in USD and payouts handled via Stripe Connect. Moodle has not published an official revenue-share figure, so we will not speculate on one. As Moodle's Chief Product Officer Marie Achour put it: "Moodle Marketplace is about supporting that spirit — connecting organisations with solutions, helping developers showcase their work, and making it easier for everyone to benefit from the strength of the Moodle ecosystem." ## From a Forum Database to a Marketplace: 20 Years of Moodle Plugins The road here is worth remembering: - **2006** — the first 'Modules and plugins' and 'Themes' databases appear on moodle.org, little more than structured community listings. - **October 2011** — the new Plugins directory launches at moodle.org/plugins, with approval through automated checks plus peer review by volunteer 'Plugins guardians'. - **December 2022** — the directory passes **2,000 open-source plugins** contributed by 1,147 developers. Along the way it introduces awards the community learned to trust: 'Early bird' badges per release, 'Automated testing support' (around since at least 2015), and 'Privacy friendly' (since the GDPR Privacy API landed in Moodle 3.5 in 2018). - **June 2025** — the marketplace is first publicly revealed in the run-up to MoodleMoot Global. - **September 2025** — at MoodleMoot Global in Edinburgh, Moodle HQ confirms the directory "will be replaced by a full-featured e-commerce and revenue-share marketplace". - **26 February 2026** — developers are invited to submit paid plugins; the old directory goes read-only. - **20 July 2026** — the Moodle Marketplace officially launches. ## Our Own Small Place in It We will be honest: we are biased, and happily so. Our plugin **Information Banner** is among the very first paid listings on the marketplace — plugin ID 53, no less. The Premium plan is **$49 USD per year**, supports **Moodle 4.5 through 5.2**, and carries both the **Privacy friendly** and **Automated testing support** awards we wrote about when the plugin first launched. You can find it here: [Information Banner on the Moodle Marketplace](https://marketplace.moodle.com/plugins/local_informationbanner). Information Banner puts scheduled, site-wide announcements at the top of every page — dismissable per user, capability-controlled, and fully GDPR-compliant. Seeing it sit in the very first wave of paid plugins, next to vendors many times our size, is a milestone for our small Dutch team. ## What This Means for Your Moodle Site If you administer a Moodle site, the practical takeaway is simple: the marketplace is now the place to look, and its defaults — maintained-first ranking, stale plugins hidden, standardised pages — make it safer to browse than the directory ever was. If a plugin you rely on has not made the move yet, that is worth a conversation with its maintainer. And if you need something that does not exist in a catalogue of 1,517 listings — a custom plugin, an integration, or help choosing and combining the right tools — that is exactly what we do all day at Ldesign Media. Get in touch; we would love to hear about it. --- ## The Moodle Marketplace Is Here: What the Launch Means for the Plugin Ecosystem (NL) Source: https://ldesignmedia.nl/nl/blog/moodle-marketplace-is-er Published: 2026-07-24 Op 20 juli 2026 maakte Moodle HQ het officieel: de **Moodle™ Marketplace** is live op [marketplace.moodle.com](https://marketplace.moodle.com). De vertrouwde pluginsdirectory op moodle.org/plugins, vijftien jaar lang dé plek om Moodle-plugins te vinden, verwijst voortaan door naar de nieuwe marketplace. Het is de grootste verandering in het plugin-ecosysteem sinds de lancering van die directory in 2011, en er zit ook iets echt nieuws in: voor het eerst kun je betaalde plugins direct bij Moodle kopen. "At Moodle, we're committed to building a learning ecosystem that can extend as your needs evolve — without replacing what's already working. That's exactly what Moodle Marketplace is built to support," aldus CEO Scott Anderberg in de [lanceringsaankondiging](https://moodle.com/news/moodle-marketplace-is-here/). En we mogen het zelf van dichtbij meemaken: onze eigen plugin **Information Banner** is een van de allereerste betaalde listings in de marketplace. Daarover later meer. ## Wat is er nieuw voor gebruikers? Wie regelmatig plugins zocht in de oude directory herkent de pijnpunten: zoeken werkte alleen als je de exacte naam kende, en verlaten plugins stonden vermengd met actief onderhouden projecten. De marketplace pakt dat aan: - **Zoeken in natuurlijke taal**: beschrijf wat je zoekt in je eigen woorden; je hoeft de exacte pluginnaam niet meer te kennen. - **Recent bijgewerkte plugins eerst**: de catalogus toont standaard vooral plugins die recent en regelmatig worden bijgewerkt, zodat je sneller iets vindt dat onderhouden wordt en werkt op jouw versie. - **Verouderde plugins standaard verborgen**: plugins die drie jaar of langer niet zijn bijgewerkt verschijnen alleen als je dat expliciet aanzet. - **Consistente pluginpagina's**: versies, onderhoudsstatus en statistieken staan op elke pagina op dezelfde plek, met vaste tabs als Description, Support, Versions, Translations en Stats. Geen zoektocht meer tussen wisselende layouts. - **Gratis én betaald in één catalogus**: je haalt gratis plugins op én koopt betaalde plugins zonder de site te verlaten. Betaalde listings tonen prijsopties, een 'Buy now'-knop, de verkoopvoorwaarden van de verkoper en het label 'Reviewed annually for quality'. De lanceringscatalogus telt **1.517 listings**, met versiefilters van Moodle 1.9 tot en met 5.2 en badgefilters voor Certified Integrations en Certified Partners. ![De plugincatalogus van de Moodle Marketplace: 1.517 listings bij de lancering](/images/blog/moodle-marketplace/marketplace-plugins-browse.png) ## Wat is er nieuw voor ontwikkelaars? De grootste verandering zit aan de aanbodkant: de marketplace heeft ingebouwde e-commerce, waarmee pluginontwikkelaars een direct verkoopkanaal krijgen voor hun werk. Zoals senior projectmanager Setara Singh het verwoordt: "Moodle Marketplace builds on that strength, making it easier than ever to find the right tools to make Moodle your own. And this is just the beginning." Uit de ervaringen van bureaus die het verkoopproces al doorliepen weten we hoe het in de praktijk werkt: - betaalde plugins worden intern door Moodle HQ beoordeeld, met een **jaarlijkse kwaliteitsreview**; - een **Privacy API-provider is verplicht** en geautomatiseerde tests worden verwacht; - uitbetalingen lopen via **Stripe Connect**, met prijzen in USD; - als prijsmodel kies je een vast jaartarief, een maandelijks abonnement of een gelaagde prijsstelling. Dat is een bewuste koers: wie geld vraagt voor een plugin, moet ook aantoonbaar kwaliteit leveren. Precies de richting die het ecosysteem volwassener maakt. ## Van forumdatabase naar marketplace: 20 jaar Moodle-plugins De marketplace staat op de schouders van twintig jaar communitygeschiedenis: - **2006**: de eerste 'Modules and plugins'- en 'Themes'-databases verschijnen op moodle.org. - **Oktober 2011**: de nieuwe Plugins directory gaat live op moodle.org/plugins, met goedkeuring via geautomatiseerde checks en peer review door vrijwillige 'Plugins guardians'. - **Vanaf circa 2015**: de directory kent awards toe, zoals **Automated testing support**, de per-release **Early bird**-badges en, sinds de GDPR Privacy API van 2018, **Privacy friendly**. - **December 2022**: de directory telt meer dan 2.000 open-source plugins van 1.147 ontwikkelaars. - **Juni 2025**: rond MoodleMoot Global wordt de marketplace voor het eerst publiekelijk aangekondigd. - **September 2025**: op MoodleMoot Global in Edinburgh bevestigt HQ dat de directory vervangen wordt door een volwaardige e-commerce marketplace. - **26 februari 2026**: Moodle HQ roept ontwikkelaars op betaalde plugins in te dienen; de oude directory wordt read-only. - **20 juli 2026**: de officiële lancering van de Moodle Marketplace. ## Information Banner: een van de eerste betaalde listings Bij Ldesign Media zijn we er trots op dat **Information Banner**, onze plugin voor geplande, sitewide aankondigingen bovenaan elke Moodle-pagina, bij de lancering al live staat als betaalde listing. Nummer 53 in de catalogus, zelfs. De Premium-versie kost **$49 USD per jaar**, ondersteunt **Moodle 4.5 tot en met 5.2** en draagt de awards **Privacy friendly** en **Automated testing support**, met de verplichte Privacy API-provider en testdekking die je van een betaalde plugin mag verwachten. Bekijk de listing op de [pluginpagina van Information Banner](https://marketplace.moodle.com/plugins/local_informationbanner). ![De pluginpagina van Information Banner op de Moodle Marketplace](/images/blog/moodle-marketplace/marketplace-information-banner-detail.png) ## Wat betekent dit voor jou? Voor beheerders wordt het makkelijker om onderhouden, betrouwbare plugins te vinden, en er is voor het eerst een officieel kanaal voor premium-functionaliteit met kwaliteitsgarantie. Voor de community blijft alles wat gratis en open source was gewoon beschikbaar; de marketplace voegt er een duurzame inkomstenstroom voor ontwikkelaars aan toe. Zoek je een plugin die nog niet bestaat, of wil je sparren over wat de marketplace voor jouw Moodle-omgeving betekent? Dat is precies waar wij elke dag mee bezig zijn. Neem contact op; we horen graag van je. --- ## Information Banner Is Now Live in the Moodle Plugins Directory (EN) Source: https://ldesignmedia.nl/en/blog/information-banner-plugin-moodle-marketplace Published: 2026-07-24 We have a small milestone to celebrate: our plugin **Information Banner** has been reviewed, approved, and is now live in the official Moodle plugins directory. It is the kind of plugin that looks simple from the outside — a banner at the top of every page — but it solves a problem every Moodle administrator runs into sooner or later: how do you make sure *every* user actually sees an important message? You can find it here: [Information Banner on marketplace.moodle.com](https://marketplace.moodle.com/plugins/53). ## The Problem It Solves Every organization running Moodle has messages that cannot be missed: a planned maintenance window, a policy change, an upcoming event, or an urgent alert. The usual options all leak: - Mass emails get ignored or land in spam; - a notice pinned in one course only reaches the people who visit that course; - editing the theme for a temporary announcement is fragile, and someone has to remember to remove it again. Information Banner takes a more direct route: it puts your message at the top of **every page**, the moment a user logs in and everywhere they navigate after that. ## What the Plugin Does - **Site-wide display** — the banner shows on every page via Moodle's modern Hooks API. No theme edits, no hacks in your layout files. - **Scheduled visibility** — set an exact start and end date/time. The banner appears and disappears automatically, so no one has to flip a switch at 07:00 before a maintenance window. - **Dismissable** — users can close a banner once they have read it. Their choice is remembered per user, so they are not nagged again on every page load. - **Rich HTML messages** — format your announcement with links, bold text, and styling. - **Marquee mode** — an optional scrolling-text display for high-visibility notices. - **Capability-controlled** — show banners only to users with the right permission, using a dedicated `local/informationbanner:viewbanner` capability. Ideal for messages meant only for teachers or staff. - **Test mode** — preview your banner before it goes live to all users. ## Built the Modern Moodle Way Under the hood this is exactly how we think community plugins should be built. The banner is injected through Moodle's Hooks API rather than by overriding renderers or patching themes, which keeps it robust across upgrades. The plugin supports **Moodle 4.5 through 5.2**. It also ships with a complete **Privacy API provider**. The only thing stored per user is a single preference — whether they dismissed the banner — and that data is properly declared, exported, and deleted. That earned the plugin the **Privacy friendly** award in the plugins directory, along with the **Automated testing support** award for its test coverage. Both matter to us: they are the difference between a plugin you can adopt with confidence and one you have to audit first. ## Why We Released It At Ldesign Media we mostly build custom Moodle plugins for clients, but this one kept coming back as a recurring need — in our own projects and in conversations with administrators. Instead of rebuilding a slightly different banner for every organization, we built one properly and released it so the whole community can use it. ## Get the Plugin Information Banner is free and open source. Install it from the [Moodle plugins directory](https://marketplace.moodle.com/plugins/53), or search for it directly from your site's plugin installer. We maintain it actively, and feedback, bug reports, and feature ideas are very welcome. And if your organization needs something that does not exist yet — a plugin, an integration, or a full custom LMS — that is exactly what we do all day. Get in touch; we would love to hear about it. --- ## Information Banner Is Now Live in the Moodle Plugins Directory (NL) Source: https://ldesignmedia.nl/nl/blog/information-banner-plugin-in-de-moodle-marketplace Published: 2026-07-24 We hebben een kleine mijlpaal te vieren: onze plugin **Information Banner** is beoordeeld, goedgekeurd en staat nu live in de officiële Moodle-pluginsdirectory. Het is het soort plugin dat er van buiten simpel uitziet: een banner bovenaan elke pagina. Maar het lost een probleem op waar elke Moodle-beheerder vroeg of laat tegenaan loopt: hoe zorg je dat *elke* gebruiker een belangrijk bericht daadwerkelijk ziet? Je vindt hem hier: [Information Banner op marketplace.moodle.com](https://marketplace.moodle.com/plugins/53). ## Het probleem dat het oplost Elke organisatie met Moodle heeft berichten die niemand mag missen: een gepland onderhoudsvenster, een beleidswijziging, een aankomend evenement of een urgente melding. De gebruikelijke opties lekken allemaal: - massa-e-mails worden genegeerd of belanden in de spam; - een mededeling in één cursus bereikt alleen de mensen die die cursus bezoeken; - het thema aanpassen voor een tijdelijke aankondiging is fragiel, en iemand moet eraan denken om hem ook weer te verwijderen. Information Banner kiest een directere route: jouw bericht staat bovenaan **elke pagina**, vanaf het moment dat een gebruiker inlogt en op elke pagina die daarna wordt bezocht. ## Wat de plugin doet - **Sitewide weergave**: de banner verschijnt op elke pagina via de moderne Hooks API van Moodle. Geen thema-aanpassingen, geen hacks in je layoutbestanden. - **Geplande zichtbaarheid**: stel een exacte begin- en einddatum/tijd in. De banner verschijnt en verdwijnt automatisch, dus niemand hoeft om 07:00 een knop om te zetten voor een onderhoudsvenster. - **Wegklikbaar**: gebruikers kunnen een banner sluiten zodra ze hem hebben gelezen. Die keuze wordt per gebruiker onthouden, dus ze worden niet op elke pagina opnieuw lastiggevallen. - **Rijke HTML-berichten**: maak je aankondiging op met links, vetgedrukte tekst en styling. - **Marquee-modus**: een optionele weergave met scrollende tekst voor meldingen die extra moeten opvallen. - **Rechten gestuurd**: toon banners alleen aan gebruikers met de juiste permissie, via een eigen `local/informationbanner:viewbanner`-capability. Ideaal voor berichten die alleen voor docenten of medewerkers bedoeld zijn. - **Testmodus**: bekijk een voorbeeld van je banner voordat hij live gaat voor alle gebruikers. ## Gebouwd op de moderne Moodle-manier Onder de motorkap is dit precies hoe wij vinden dat community-plugins gebouwd moeten worden. De banner wordt geïnjecteerd via de Hooks API van Moodle in plaats van renderers te overschrijven of thema's te patchen, wat hem robuust maakt bij upgrades. De plugin ondersteunt **Moodle 4.5 tot en met 5.2**. Hij wordt ook geleverd met een complete **Privacy API-provider**. Het enige dat per gebruiker wordt opgeslagen is een enkele voorkeur (of de banner is weggeklikt), en die data wordt correct gedeclareerd, geëxporteerd en verwijderd. Dat leverde de plugin de **Privacy friendly**-award op in de pluginsdirectory, samen met de **Automated testing support**-award voor de testdekking. Beide zijn belangrijk voor ons: ze zijn het verschil tussen een plugin die je met vertrouwen adopteert en een plugin die je eerst moet auditen. ## Waarom we hem hebben uitgebracht Bij Ldesign Media bouwen we vooral maatwerk-Moodle-plugins voor klanten, maar deze behoefte kwam steeds terug, zowel in onze eigen projecten als in gesprekken met beheerders. In plaats van voor elke organisatie een nét iets andere banner te bouwen, hebben we er één goed gebouwd en uitgebracht, zodat de hele community hem kan gebruiken. ## Download de plugin Information Banner is gratis en open source. Installeer hem vanuit de [Moodle-pluginsdirectory](https://marketplace.moodle.com/plugins/53), of zoek ernaar via de plugin-installer van je eigen site. We onderhouden hem actief, en feedback, bugrapporten en ideeën voor nieuwe features zijn van harte welkom. En heeft jouw organisatie iets nodig dat nog niet bestaat (een plugin, een integratie of een compleet LMS op maat), dan is dat precies waar wij elke dag mee bezig zijn. Neem contact op; we horen graag van je. --- ## Why Custom Moodle Plugins Beat Off-the-Shelf Solutions for Enterprise (EN) Source: https://ldesignmedia.nl/en/blog/why-custom-moodle-plugins-beat-off-the-shelf Published: 2026-04-01 When you need Moodle to do something it doesn't do out of the box, the instinct is to search the Moodle plugins directory. There are nearly 2,800 plugins listed there, surely someone has already solved your problem. And sometimes they have. But after building more than 300 custom plugins over fifteen years, we've seen the full cost of relying on community plugins for enterprise-grade requirements, and it's rarely as cheap as it first appears. This isn't an argument against open-source community plugins. Many are excellent, and we use them ourselves. This is an argument for being deliberate about when custom development is the right call, and understanding what you're actually getting when you commission a plugin built specifically for your organization. ## The Hidden Costs of Off-the-Shelf Plugins ### Version Compatibility: The Upgrade Tax Moodle releases a major version roughly every six months. Each release cycle, organizations running community plugins face what we've come to call the upgrade tax: the time and risk associated with checking whether every installed plugin has been updated for the new Moodle version, testing plugins that claim compatibility but behave differently against your data, and dealing with plugins whose maintainers have moved on. We've audited Moodle installations for clients, KLM, Nedap, BSL Media & Learning, where between 10 and 30 percent of installed plugins were either unmaintained or running on versions two or three major releases behind. Those plugins don't just cause technical debt. They become the reason Moodle upgrades get postponed, which compounds into larger and more disruptive migrations later. A custom plugin built to your organization's specifications is maintained by a party with a direct contractual interest in keeping it working. When Moodle 5.x introduces breaking API changes, we update our clients' plugins as part of the engagement, not as an afterthought if the original developer happens to be available. ### Performance Bloat Community plugins are built to serve many organizations with different needs. This means they carry configuration options you'll never use, database tables storing data you don't need, and event listeners firing on every page load regardless of whether that feature is relevant to your context. We've profiled Moodle instances where a single community activity module was responsible for 30 to 40 percent of total database query time, because it was issuing broad queries optimized for flexibility rather than for the specific access pattern of the host organization. When we build a custom activity module or report plugin, we design the schema around the actual queries it will run. Indexes are placed where they'll be used. Caching is implemented for the specific data that's expensive to compute. The result isn't just faster, it's predictably fast, because the plugin isn't doing anything it doesn't need to do. ### Security Risks You Can't Control The Moodle security team does excellent work, but they cannot review the entire plugin directory continuously. Community plugins vary enormously in their approach to security: some follow Moodle's security guidelines meticulously, others were written quickly to solve a specific problem and haven't been revisited since. We've conducted more than 50 security audits of Moodle installations for Dutch organizations, and the findings follow a pattern. The core Moodle installation is usually in reasonable shape. The plugins are where the vulnerabilities accumulate, SQL injection through unsanitized parameters, cross-site scripting through unescaped output, access control checks that can be bypassed with a crafted URL. With a custom plugin, you control the codebase. We apply Moodle's full security API, `required_capability()`, `$DB->get_records()` with parameterized queries, `clean_param()` on every external input, proper session key validation on form submissions. And because we wrote it, we know exactly where to look when a security review surfaces a concern. ### The Support Gap When a community plugin breaks during a Moodle upgrade, your options are limited. You can wait for the maintainer to release a fix. You can fork the plugin and fix it yourself, taking on maintenance responsibility. Or you can pay a developer, possibly us, to dig into a codebase we didn't write and don't know intimately. None of these are good options when the plugin in question handles critical functionality: course completions feeding into HR systems, certification tracking for regulated industries, or the custom enrollment workflow that 15,000 users interact with every day. ## What Custom Plugin Development Actually Looks Like The process of building a custom Moodle plugin is more structured than people sometimes expect. It's not a matter of writing some PHP and dropping it into the plugins directory. Moodle has a well-defined plugin API, and working within it correctly is what makes plugins maintainable, upgradeable, and secure. ### Phase 1: Requirements and Architecture We start every plugin project with a requirements session where we push back on vague specifications. "We need a custom certificate plugin" is a starting point, not a spec. We need to know: what data goes on the certificate, who can generate it, what triggers issuance, where the PDFs are stored, how certificates are verified, what happens when a course is updated after a certificate is issued. These conversations surface constraints that change the architecture. A certificate plugin for a healthcare training provider (like Dentallect) has different requirements than one for a corporate training platform, regulated professions may require certificates to reference specific qualification frameworks, include verifiable identifiers, and survive the organization's Moodle installation being replaced. The output of this phase is a technical specification that identifies the plugin type (activity module, block, local plugin, auth plugin, format, report, admin tool), the database schema, the capability definitions, and the integration points with Moodle core. ### Phase 2: Plugin Structure Every Moodle plugin starts with a `version.php` that tells Moodle who made it, what version it is, and what version of Moodle it requires: ```php component = 'mod_clientactivity'; $plugin->version = 2026021500; $plugin->requires = 2024042200; // Moodle 4.4 $plugin->maturity = MATURITY_STABLE; $plugin->release = '1.2.0'; ``` The version number follows the date convention Moodle uses: YYYYMMDDXX. Every time we release an update, this number increments, which tells Moodle's upgrade system that database changes need to be applied. For an activity module, `lib.php` defines the mandatory functions that Moodle calls to integrate the activity into the course flow: ```php timecreated = time(); $moduleinstance->timemodified = time(); return $DB->insert_record('clientactivity', $moduleinstance); } function clientactivity_supports(int $feature): ?bool { return match ($feature) { FEATURE_MOD_INTRO => true, FEATURE_COMPLETION_TRACKS_VIEWS => true, FEATURE_GRADE_HAS_GRADE => true, FEATURE_BACKUP_MOODLE2 => true, default => null, }; } ``` The `clientactivity_supports()` function is what tells Moodle which platform features this activity works with, completion tracking, grading, backup/restore. Getting this right matters: if you claim `FEATURE_BACKUP_MOODLE2` support without implementing the backup API properly, courses containing your activity will produce corrupt backup files. ### Phase 3: Database and Upgrades The `db/install.xml` file defines the initial schema using Moodle's XMLDB format. When the plugin is first installed, Moodle's upgrade system creates these tables automatically. When we release an update that changes the schema, we add a step to `db/upgrade.php`: ```php get_manager(); if ($oldversion < 2026021500) { $table = new xmldb_table('clientactivity'); $field = new xmldb_field('externalref', XMLDB_TYPE_CHAR, '255', null, null, null, null, 'timemodified'); if (!$dbman->field_exists($table, $field)) { $dbman->add_field($table, $field); } upgrade_mod_savepoint(true, 2026021500, 'clientactivity'); } return true; } ``` This is how schema changes survive upgrades without data loss. The version check ensures each migration only runs once, even if an administrator runs the upgrade process multiple times. ### Phase 4: Testing We test plugins at multiple levels depending on the project's scope and budget. Sometimes clients request unit tests, where PHP classes that implement the plugin's core functionality are tested with PHPUnit, with Moodle's test data generator providing realistic fixture data. In other cases the budget is limited or the plugin is straightforward enough that unit tests don't add proportional value, so we focus testing effort where it matters most. Integration tests run against a real Moodle database to verify that the plugin installs cleanly, that the database schema is created correctly, and that core Moodle APIs interact with the plugin as expected. And before any plugin goes to production, we do manual acceptance testing against a staging instance that mirrors the client's production configuration. We also run Moodle's built-in code checker tools: `phpcbf` for code style, `phplint` for syntax errors, and Moodle's own `moodlecheck` plugin for API compliance. The community plugins directory requires these checks to pass, but for custom plugins, we apply them because they catch real problems. All of this is tied together with CI pipelines. Every commit triggers automated checks: code style, linting, and any configured tests run automatically before code can be merged. For deployment, we use CI/CD pipelines that handle staging and production releases, so updates reach the right environment without manual intervention or human error. ## Types of Plugins We Build ### Activity Modules The most complex plugin type. Activity modules appear in the course section list alongside Moodle's built-in activities (Assignment, Quiz, Forum). Real examples from our portfolio include: - **KLM Travel Journal** for cabin crew training, where crew members document real-world experiences as structured learning activities - **Open Webinar** for live and recorded webinar sessions with attendance tracking and completion integration - **Custom certificates** with automated generation based on course completion and configurable templates - **Self-assessment modules** and **360-degree feedback** tools for professional development programs - **Time registration activities** for tracking study hours in regulated training environments - **Canvas-based interactive activities** for creative and visual learning assignments ### Authentication and Enrollment Plugins Auth plugins control how users authenticate. Enrol plugins control how users get into courses. These two areas are where enterprise system integration happens. We have built dozens of authentication integrations for organizations like KLM, AFAS, SURFconext, Fontys, and UWV. These range from SAML2 and OpenID Connect (OIDC) implementations to fully custom SSO solutions. Each handles organization-specific attribute mapping: taking attributes from the identity provider and using them to populate Moodle profile fields, assign cohorts, or trigger enrollment in specific course categories. For HR-system integrations (SAP, AFAS, Workday), we have built enrollment sync plugins that poll an API on a schedule, create users who have arrived, suspend users who have left, and update profile data in between. We also build enrollment plugins for payment integrations (Mollie, course payment gateways) and voucher-based access. ### Reports and Analytics Moodle's built-in reporting is adequate for simple use cases. For enterprise clients who need to answer questions like "which of our 8,000 employees completed the mandatory safety training this quarter, broken down by department and employment type," the built-in tools reach their limits quickly. We build report plugins using Moodle's report API, which integrates them into the administration and course-level navigation. Examples include certificate reports, coach view completion dashboards, group progress overviews, and SCORM attempt analytics. These reports can join completion data with profile fields, custom user info fields, and cohort membership to produce the exact views that HR and compliance teams need. ### Course Formats Course formats control how a course's section list is presented to students. Beyond the built-in Topics, Weeks, and Social formats, we have built: - **VSF (Vertical Section Format)** for clean, scrollable course layouts - **Tab-based formats** like TabTiles for VUmc, organizing sections into navigable tabs - **Grid formats** customized for KLM, UWV, and other enterprise clients - **ANWB Streetwise format** for primary school traffic safety education - **Game dashboard formats** with interactive progression elements ### Blocks Blocks are sidebar components that can be added to any page in Moodle. We use them for dashboard widgets, notification systems, quick-access menus, and embedding content from external systems. Real examples include voucher management blocks, recertification tracking, user avatar (webcam snapshot) blocks, course note widgets, Streetwise navigation for ANWB, and custom dashboard blocks for various enterprise clients. We have also built Commander, a quick-navigation block that lets administrators and teachers find pages instantly. ### Themes Moodle's theme system controls the entire front-end presentation. For enterprise clients, this usually means a custom theme built on Moodle's Boost base theme, implementing the organization's design system, adjusting navigation structure, and ensuring accessibility compliance. We have built themes for Nedap, De Schoolschrijver, Vakmedia, Citaverde, and others, each matching strict brand guidelines. ### Availability Conditions and Local Plugins Beyond the main plugin types, we build availability conditions that control access to activities based on criteria like IP address restrictions, voucher codes, or payment status. Our local plugins handle everything from GDPR compliance tools and OneRoster data synchronization to CSV user imports and quiz monitoring. ## The Cost-Benefit Analysis: When Does Custom Make Sense? Community plugins make sense when the functionality they provide closely matches what you need, when they're actively maintained, and when their security posture is acceptable for your environment. Custom development makes sense when: - **The community plugin exists but doesn't fit.** If you need to modify a community plugin significantly, you've effectively forked it, and now you're responsible for maintaining a diverged codebase through every Moodle upgrade. It's often cheaper to build what you actually need. - **The functionality involves sensitive data or access control.** Enrollment logic, grade calculations, and certificate issuance are areas where a bug has real consequences. These are not places to accept code you can't fully audit. - **The plugin needs to integrate with your systems.** Community plugins are built for a general audience. A plugin that syncs with your specific HR system, using your specific API authentication scheme and your specific data model, needs to be written for your situation. - **You're operating at scale.** A plugin that performs acceptably for 500 users may not perform acceptably for 50,000. Custom plugins can be optimized for your specific load profile and access patterns. - **You need guaranteed support continuity.** For functionality that's critical to your operations, you need to know that someone with intimate knowledge of the code is available when something goes wrong. ## How to Evaluate Whether You Need a Custom Plugin Before commissioning custom development, work through these questions: ### Does a community plugin exist that covers 80% or more of your requirements without modification? If yes, evaluate whether the remaining 20% is truly necessary or whether you can adapt your process. ### Is the community plugin actively maintained? Check the last update date, the number of open issues, and whether the maintainer has responded to recent bug reports. A plugin last updated for Moodle 3.9 is effectively unmaintained. ### Have you read the community plugin's code? For any plugin handling authentication, enrollment, grades, or financial transactions, you should review the code or have someone review it for you. The Moodle plugin directory does not guarantee security. ### What's the cost of the plugin failing? If the answer is "we lose compliance records" or "enrollment for 10,000 users breaks," the calculus shifts toward custom development with guaranteed maintenance. ### Does the plugin need to survive your organization across multiple Moodle versions? Longevity requirements favor custom development with a maintenance agreement. ## Realistic Expectations Custom plugin development takes longer and costs more upfront than installing a community plugin. That's a real difference, and it matters for organizations with tight timelines or limited budgets. What it buys you is a plugin that does exactly what you need, performs well at your scale, can be audited and maintained by people who know the code, and won't hold up your Moodle upgrade because its maintainer disappeared. For [Ldesign Media](https://ldesignmedia.nl/en)'s clients, organizations like KLM running training for thousands of employees, or Yuverta managing student progression across a network of MBO schools, that reliability is the point. The training platform is infrastructure, and infrastructure needs to be dependable. The 300+ plugins we've built since 2010 range from small utility plugins that solve one specific problem, to complex multi-component systems that sit at the center of a client's entire learning operation. The common thread isn't complexity, it's that in every case, the plugin does what the organization actually needs, and it keeps working when Moodle updates. --- ## Why Custom Moodle Plugins Beat Off-the-Shelf Solutions for Enterprise (NL) Source: https://ldesignmedia.nl/nl/blog/waarom-maatwerk-moodle-plugins-beter-zijn Published: 2026-04-01 Als Moodle iets niet standaard kan, is de eerste reflex om de Moodle-plugindirectory te doorzoeken. Er staan bijna 2.800 plugins in, iemand heeft jouw probleem vast al opgelost. En soms is dat zo. Maar na het bouwen van meer dan 300 maatwerkaplugins over vijftien jaar kennen we de echte kosten van afhankelijkheid van community-plugins voor enterprise-eisen, en die zijn zelden zo laag als ze er aanvankelijk uitzien. Dit is geen pleidooi tegen open source community-plugins. Veel zijn uitstekend, en we gebruiken ze zelf ook. Dit is een pleidooi voor bewuste keuzes: wanneer is maatwerkontwikkeling het juiste antwoord, en wat krijg je precies als je een plugin laat bouwen die specifiek voor jouw organisatie is gemaakt? ## De verborgen kosten van standaard plugins ### Versiecompatibiliteit: de upgradebelasting Moodle brengt ruwweg elke zes maanden een hoofdversie uit. Elke releasecyclus worden organisaties die community-plugins gebruiken geconfronteerd met wat wij de upgradebelasting noemen: de tijd en het risico van controleren of elke geïnstalleerde plugin voor de nieuwe Moodle-versie is bijgewerkt, het testen van plugins die compatibiliteit claimen maar anders gedragen bij jouw data, en het omgaan met plugins waarvan de beheerder al lang is vertrokken. We hebben Moodle-installaties geaudit bij klanten als KLM, Nedap en BSL Media & Learning, waarbij tien tot dertig procent van de geïnstalleerde plugins ofwel niet meer onderhouden werd, ofwel draaide op versies die twee of drie hoofdreleases achterliepen. Die plugins zorgen niet alleen voor technische schuld. Ze worden de reden dat Moodle-upgrades worden uitgesteld, wat op termijn leidt tot grotere en ingrijpendere migraties. Een maatwerk-plugin die is gebouwd naar de specificaties van jouw organisatie, wordt onderhouden door een partij met een directe contractuele verantwoordelijkheid om hem werkend te houden. Als Moodle 5.x breaking API-wijzigingen introduceert, updaten wij de plugins van onze klanten als onderdeel van de samenwerking, niet als nagedachte als de oorspronkelijke ontwikkelaar toevallig beschikbaar is. ### Onnodige complexiteit en trage performance Community-plugins zijn gebouwd voor veel verschillende organisaties met uiteenlopende wensen. Dat betekent: configuratie-opties die je nooit gebruikt, databasetabellen die data opslaan die je niet nodig hebt, en event-listeners die bij iedere paginaweergave vuren, ongeacht of die functie in jouw context relevant is. We hebben Moodle-omgevingen geprofileerd waarbij één community-activiteitsmodule verantwoordelijk was voor dertig tot veertig procent van de totale databasequerytijd. De queries waren geoptimaliseerd voor flexibiliteit, niet voor het specifieke toegangspatroon van de organisatie. Wanneer we een maatwerk-activiteitsmodule of rapportage-plugin bouwen, ontwerpen we het schema rondom de queries die het daadwerkelijk gaat uitvoeren. Indexen zitten waar ze gebruikt worden. Caching is geïmplementeerd voor de specifieke data die duur is om te berekenen. Het resultaat is niet alleen sneller, het is voorspelbaar snel, omdat de plugin niets doet wat hij niet hoeft te doen. ### Beveiligingsrisico's die je niet kunt beheersen Het Moodle-securityteam levert uitstekend werk, maar kan niet de volledige plugindirectory continu reviewen. Community-plugins variëren enorm in hun benadering van beveiliging: sommige volgen de richtlijnen van Moodle nauwgezet, andere zijn snel geschreven om een specifiek probleem op te lossen en sindsdien niet meer aangeraakt. We hebben meer dan vijftig beveiligingsaudits uitgevoerd bij Nederlandse Moodle-omgevingen. De bevindingen vertonen een patroon. De Moodle-core is doorgaans in redelijke staat. De plugins zijn waar de kwetsbaarheden zich ophopen, SQL-injectie via ongesaniteerde parameters, cross-site scripting via ontbroken output-escaping, toegangscontroles die te omzeilen zijn met een aangepaste URL. Met een maatwerk-plugin heb je controle over de codebase. We passen de volledige Moodle-beveiligings-API toe: `required_capability()`, `$DB->get_records()` met geparameteriseerde queries, `clean_param()` op elke externe invoer, en correcte sessiesleutelvalidatie bij formulierindieningen. En omdat wij het geschreven hebben, weten we precies waar we moeten kijken als een beveiligingsreview een punt van aandacht oplevert. ### Het ondersteuningsgat Als een community-plugin kapot gaat tijdens een Moodle-upgrade, zijn je opties beperkt. Je kunt wachten tot de beheerder een fix uitbrengt. Je kunt de plugin forken en zelf repareren, waarmee je de onderhoudsverantwoordelijkheid overneemt. Of je kunt een ontwikkelaar betalen, mogelijk ons, om zich in een codebase te verdiepen die we niet kennen. Geen van deze opties is goed als de betreffende plugin kritieke functionaliteit afhandelt: cursusafrondingendie doorgaan naar HR-systemen, certificering voor gereguleerde sectoren, of de aangepaste inschrijfworkflow waar vijftienduizend gebruikers elke dag mee werken. ## Hoe maatwerk-pluginontwikkeling er in de praktijk uitziet Het bouwen van een maatwerk-Moodle-plugin is gestructureerder dan mensen soms verwachten. Het is niet een kwestie van wat PHP schrijven en in de pluginmap gooien. Moodle heeft een goed gedefinieerde plugin-API, en daar correct binnen werken is wat plugins onderhoudbaar, upgradeable en veilig maakt. ### Fase 1: Requirements en architectuur Elk pluginproject begint met een requirementssessie waarbij we doorvragen op vage specificaties. "We hebben een maatwerk-certificaatplugin nodig" is een startpunt, geen spec. We willen weten: welke data staat op het certificaat, wie kan het genereren, wat triggert de uitgifte, waar worden de PDF's opgeslagen, hoe worden certificaten geverifieerd, en wat gebeurt er als een cursus wordt aangepast nadat een certificaat is uitgegeven? Deze gesprekken brengen beperkingen naar boven die de architectuur veranderen. Een certificaatplugin voor een zorgopleidingsaanbieder zoals Dentallect heeft andere eisen dan één voor een corporate trainingsplatform, gereguleerde beroepen kunnen vereisen dat certificaten verwijzen naar specifieke kwalificatiekaders, verifieerbare identificatoren bevatten, en blijven bestaan als de Moodle-installatie van de organisatie wordt vervangen. De uitkomst van deze fase is een technische specificatie die het plugintype identificeert (activiteitsmodule, blok, lokale plugin, auth-plugin, format, rapport, beheertool), het databaseschema, de capability-definities en de integratiepunten met Moodle-core. ### Fase 2: Pluginstructuur Elke Moodle-plugin begint met een `version.php` die Moodle vertelt wie hem heeft gemaakt, welke versie het is, en welke Moodle-versie vereist is: ```php component = 'mod_klantactiviteit'; $plugin->version = 2026021500; $plugin->requires = 2024042200; // Moodle 4.4 $plugin->maturity = MATURITY_STABLE; $plugin->release = '1.2.0'; ``` Het versienummer volgt de datumconventie die Moodle gebruikt: JJJJMMDDXX. Elke keer dat we een update uitbrengen, wordt dit nummer verhoogd, zodat het upgradesysteem van Moodle weet dat er databasewijzigingen toegepast moeten worden. Voor een activiteitsmodule definieert `lib.php` de verplichte functies die Moodle aanroept om de activiteit in de cursusflow te integreren: ```php timecreated = time(); $moduleinstance->timemodified = time(); return $DB->insert_record('klantactiviteit', $moduleinstance); } function klantactiviteit_supports(int $feature): ?bool { return match ($feature) { FEATURE_MOD_INTRO => true, FEATURE_COMPLETION_TRACKS_VIEWS => true, FEATURE_GRADE_HAS_GRADE => true, FEATURE_BACKUP_MOODLE2 => true, default => null, }; } ``` De functie `klantactiviteit_supports()` vertelt Moodle met welke platformfuncties deze activiteit samenwerkt, voltooiingsbeheer, beoordelingen, back-up en herstel. Dit goed doen is belangrijk: als je `FEATURE_BACKUP_MOODLE2` claimt zonder de back-up-API correct te implementeren, leveren cursussen met jouw activiteit beschadigde back-upbestanden op. ### Fase 3: Database en upgrades Het bestand `db/install.xml` definieert het beginschema in het XMLDB-formaat van Moodle. Bij de eerste installatie maakt het upgradesysteem van Moodle deze tabellen automatisch aan. Als we een update uitbrengen die het schema wijzigt, voegen we een stap toe aan `db/upgrade.php`: ```php get_manager(); if ($oldversion < 2026021500) { $table = new xmldb_table('klantactiviteit'); $field = new xmldb_field('externreferentie', XMLDB_TYPE_CHAR, '255', null, null, null, null, 'timemodified'); if (!$dbman->field_exists($table, $field)) { $dbman->add_field($table, $field); } upgrade_mod_savepoint(true, 2026021500, 'klantactiviteit'); } return true; } ``` Zo overleven schemawijzigingen upgrades zonder dataverlies. De versiecontrole zorgt ervoor dat elke migratie slechts één keer wordt uitgevoerd, ook als een beheerder het upgradeproces meerdere keren uitvoert. ### Fase 4: Testen We testen plugins op meerdere niveaus, afhankelijk van de scope en het budget van het project. Soms vragen klanten om unit tests, waarbij PHP-klassen die de kernfunctionaliteit van de plugin implementeren worden getest met PHPUnit, met Moodle's testdatagenerator voor realistische testdata. In andere gevallen is het budget beperkt of is de plugin eenvoudig genoeg dat unit tests geen evenredige waarde toevoegen, en richten we de testinspanning op waar het het meest telt. Integratietests draaien op een echte Moodle-database om te verifiëren dat de plugin correct installeert, het databaseschema goed aangemaakt wordt, en kern-Moodle-API's op de verwachte manier met de plugin interacteren. En vóór elke plugin naar productie gaat, doen we handmatige acceptatietests op een stagingomgeving die de productieconfiguratie van de klant spiegelt. We gebruiken ook de ingebouwde codecontrolestools van Moodle: `phpcbf` voor codestijl, `phplint` voor syntaxfouten, en de `moodlecheck`-plugin voor API-compliance. De plugindirectory vereist dat deze controles slagen, maar voor maatwerk-plugins passen we ze toe omdat ze echte problemen opsporen. Dit alles is gekoppeld aan CI-pipelines. Elke commit triggert automatische controles: codestijl, linting en eventueel geconfigureerde tests draaien automatisch voordat code gemerged kan worden. Voor deployment gebruiken we CI/CD-pipelines die staging- en productiereleases afhandelen, zodat updates de juiste omgeving bereiken zonder handmatige tussenkomst of menselijke fouten. ## De soorten plugins die wij bouwen ### Activiteitsmodules Het meest complexe plugintype. Activiteitsmodules verschijnen in de cursussectielijst naast de ingebouwde activiteiten van Moodle (Opdracht, Toets, Forum). Concrete voorbeelden uit ons portfolio: - **KLM Travel Journal** voor cabinetraining, waarin bemanningsleden praktijkervaringen documenteren als gestructureerde leeractiviteiten - **Open Webinar** voor live en opgenomen webinarsessies met aanwezigheidsregistratie en voltooiingsintegratie - **Aangepaste certificaten** met automatische generatie op basis van cursusvoltooiing en configureerbare templates - **Zelfbeoordelingsmodules** en **360-gradenfeedback** tools voor professionele ontwikkelingsprogramma's - **Tijdregistratieactiviteiten** voor het bijhouden van studieuren in gereguleerde trainingsomgevingen - **Canvas-gebaseerde interactieve activiteiten** voor creatieve en visuele leeropdrachten ### Authenticatie- en inschrijfplugins Auth-plugins bepalen hoe gebruikers zich aanmelden. Inschrijfplugins bepalen hoe gebruikers in cursussen komen. Dit zijn de twee gebieden waar enterprise-systeemintegratie plaatsvindt. We hebben tientallen authenticatie-integraties gebouwd voor organisaties als KLM, AFAS, SURFconext, Fontys en UWV. Deze variëren van SAML2- en OpenID Connect (OIDC)-implementaties tot volledig maatwerk SSO-oplossingen. Elke integratie handelt organisatiespecifieke attribuutmapping af: attributen van de identiteitsprovider worden omgezet naar Moodle-profielvelden, cohorten worden toegewezen of inschrijving in specifieke cursuscategorieën wordt getriggerd. Voor HR-systeemintegraties (SAP, AFAS, Workday) hebben we inschrijfsynchronisatieplugins gebouwd die op een schema een API bevragen, gebruikers aanmaken die nieuw zijn binnengekomen, gebruikers deactiveren die vertrokken zijn, en profieldata bijhouden. Daarnaast bouwen we inschrijfplugins voor betaalintegraties (Mollie, cursusbetalingsgateways) en vouchergebaseerde toegang. ### Rapportages en analyses De ingebouwde rapportage van Moodle is toereikend voor eenvoudige gevallen. Voor enterprise-klanten die vragen moeten beantwoorden als "welke van onze 8.000 medewerkers heeft dit kwartaal de verplichte veiligheidstraining afgerond, uitgesplitst naar afdeling en arbeidscontract", bereiken de ingebouwde tools snel hun grenzen. We bouwen rapportage-plugins via de report-API van Moodle, die ze integreert in de navigatie op beheer- en cursusniveau. Voorbeelden zijn certificaatrapporten, coachview-voltooiingsdashboards, groepsvoortgangsoverzichten en SCORM-pogingsanalyses. Deze rapporten kunnen voltooiingsdata combineren met profielvelden, aangepaste gebruikersinformatievelden en cohortlidmaatschap om precies de overzichten te genereren die HR- en complianceteams nodig hebben. ### Cursusformaten Cursusformaten bepalen hoe de sectielijst van een cursus aan studenten wordt gepresenteerd. Naast de ingebouwde formaten Onderwerpen, Weken en Sociaal hebben we gebouwd: - **VSF (Vertical Section Format)** voor overzichtelijke, scrollbare cursusindelingen - **Tabgebaseerde formaten** zoals TabTiles voor VUmc, die secties organiseren in navigeerbare tabbladen - **Grid-formaten** op maat gemaakt voor KLM, UWV en andere enterprise-klanten - **ANWB Streetwise-formaat** voor verkeerseducatie op basisscholen - **Game-dashboardformaten** met interactieve voortgangselementen ### Blokken Blokken zijn zijbalkcomponenten die aan elke pagina in Moodle kunnen worden toegevoegd. We gebruiken ze voor dashboardwidgets, meldingssystemen, sneltoegangsmenu's en het inbedden van inhoud uit externe systemen. Concrete voorbeelden zijn voucherbeheersblokken, hercertificeringstrackers, gebruikersavatar (webcam-snapshot) blokken, cursusnotitiewidgets, Streetwise-navigatie voor ANWB, en aangepaste dashboardblokken voor diverse enterprise-klanten. We hebben ook Commander gebouwd, een snelnavigatieblok waarmee beheerders en docenten direct pagina's kunnen vinden. ### Thema's Het thema-systeem van Moodle bepaalt de volledige presentatie van de front-end. Voor enterprise-klanten betekent dit doorgaans een maatwerk-thema gebouwd op het Boost-basisthema van Moodle, waarbij het designsysteem van de organisatie wordt geïmplementeerd, de navigatiestructuur wordt aangepast, en wordt gewaarborgd dat aan toegankelijkheidsvereisten wordt voldaan. We hebben thema's gebouwd voor Nedap, De Schoolschrijver, Vakmedia, Citaverde en anderen, elk passend bij strikte huisstijlrichtlijnen. ### Beschikbaarheidscondities en lokale plugins Naast de belangrijkste plugintypes bouwen we beschikbaarheidscondities die toegang tot activiteiten regelen op basis van criteria zoals IP-adresrestricties, vouchercodes of betaalstatus. Onze lokale plugins handelen alles af van GDPR-compliancetools en OneRoster-datasynchronisatie tot CSV-gebruikersimport en toetsmonitoring. ## De kosten-batenanalyse: wanneer is maatwerk zinvol? Community-plugins zijn zinvol wanneer de functionaliteit nauw aansluit bij wat je nodig hebt, wanneer ze actief worden onderhouden, en wanneer hun beveiligingsniveau acceptabel is voor jouw omgeving. Maatwerkontwikkeling is zinvol wanneer: - **De community-plugin bestaat maar past niet.** Als je een community-plugin significant moet aanpassen, heb je hem in feite geforkt, en nu ben je verantwoordelijk voor het onderhouden van een afwijkende codebase bij elke Moodle-upgrade. Het is vaak goedkoper om te bouwen wat je daadwerkelijk nodig hebt. - **De functionaliteit gaat over gevoelige data of toegangscontrole.** Inschrijflogica, berekeningen van beoordelingen en certificaatuitgifte zijn gebieden waarbij een bug echte gevolgen heeft. Dit zijn niet de plekken om code te accepteren die je niet volledig kunt auditen. - **De plugin moet integreren met jouw systemen.** Community-plugins zijn gebouwd voor een breed publiek. Een plugin die synchroniseert met jouw specifieke HR-systeem, gebruikmakend van jouw specifieke API-authenticatieschema en jouw specifieke datamodel, moet voor jouw situatie worden geschreven. - **Je opereert op schaal.** Een plugin die acceptabel presteert voor 500 gebruikers, presteert mogelijk niet acceptabel voor 50.000. Maatwerk-plugins kunnen worden geoptimaliseerd voor jouw specifieke belastingsprofiel en toegangspatronen. - **Je hebt gegarandeerde ondersteuningscontinuïteit nodig.** Voor functionaliteit die cruciaal is voor je bedrijfsvoering, heb je de zekerheid nodig dat iemand met grondige kennis van de code beschikbaar is als er iets misgaat. ## Hoe beoordeel je of je een maatwerk-plugin nodig hebt? Werk vóór het inschakelen van maatwerkontwikkeling deze vragen door: ### Bestaat er een community-plugin die tachtig procent of meer van je eisen dekt zonder aanpassing? Als ja, beoordeel dan of het resterende deel echt noodzakelijk is of dat je jouw proces kunt aanpassen. ### Wordt de community-plugin actief onderhouden? Controleer de datum van de laatste update, het aantal openstaande issues, en of de beheerder heeft gereageerd op recente bugrapporten. Een plugin die voor het laatst is bijgewerkt voor Moodle 3.9 is in de praktijk niet meer onderhouden. ### Heb je de code van de community-plugin gelezen? Voor elke plugin die authenticatie, inschrijving, beoordelingen of financiële transacties afhandelt, zou je de code moeten reviewen of iemand die review voor je moeten laten doen. De plugindirectory van Moodle garandeert geen beveiliging. ### Wat zijn de gevolgen als de plugin uitvalt? Als het antwoord is "we verliezen complianceregistraties" of "de inschrijving van tienduizend gebruikers loopt vast," verschuift de afweging naar maatwerkontwikkeling met gegarandeerd onderhoud. ### Moet de plugin jouw organisatie meerdere Moodle-versies meegaan? Langetermijneisen pleiten voor maatwerkontwikkeling met een onderhoudsovereenkomst. ## Realistische verwachtingen Maatwerk-pluginontwikkeling kost meer tijd en een hogere initiële investering dan het installeren van een community-plugin. Dat is een reëel verschil, en het telt voor organisaties met strakke deadlines of beperkte budgetten. Wat je ervoor terugkrijgt is een plugin die precies doet wat je nodig hebt, goed presteert op jouw schaal, geaudit en onderhouden kan worden door mensen die de code kennen, en jouw Moodle-upgrade niet zal vertragen omdat de beheerder is verdwenen. Voor de klanten van [Ldesign Media](https://ldesignmedia.nl/nl), organisaties zoals KLM die training verzorgen voor duizenden medewerkers, of Yuverta dat studentvoortgang beheert over een netwerk van mbo-scholen, is die betrouwbaarheid het punt. Het trainingsplatform is infrastructuur, en infrastructuur moet betrouwbaar zijn. De 300+ plugins die we hebben gebouwd sinds 2010 variëren van kleine hulpprogramma's die één specifiek probleem oplossen, tot complexe systemen met meerdere componenten die centraal staan in de volledige leeromgeving van een klant. De rode draad is niet complexiteit, het is dat de plugin in elk geval precies doet wat de organisatie werkelijk nodig heeft, en blijft werken als Moodle wordt bijgewerkt. --- ## From Moodle 1.8 to 5.1: Lessons from 15 Years of LMS Evolution (EN) Source: https://ldesignmedia.nl/en/blog/moodle-1-8-to-5-1-fifteen-years-lms-evolution Published: 2026-04-15 ## How It Started: Moodle 1.8 and a Platform Still Finding Itself When [Ldesign Media](https://ldesignmedia.nl/en) first started developing for Moodle in 2010, we were running version 1.8. The platform was powerful but still clearly rough: heavily admin- and form-driven, with extensions leaning on fixed entry points and callbacks. At the same time, Moodle was already clearly modular, with plugin types such as activity modules, blocks, themes, auth and enrolment plugins, each with fixed entry points like lib.php. The familiar plugin structure with db/install.xml, db/upgrade.php and version.php was in practice already there, though the exact requirements varied by plugin type and older Moodle version. Moodle 1.8 did exactly what it said on the tin: it was a course management system, built by educators, for educators. It could handle quizzes, assignments, forums, and gradebooks. For Dentallect, one of our earliest large clients, that was enough. They needed a platform where dental professionals could complete continuing education and have their completions logged. Moodle 1.8 delivered that, even if making it look and feel like a professional corporate system required a lot of custom PHP we are not entirely proud of today. What we learned quickly: Moodle's community was the real product. The forums at [moodle.org](https://marketplace.moodle.com/?q=luuk+verhoeven) were already active, the tracker was already filling up with bugs and feature requests, and a global mix of developers, educators, and translators had gathered around Martin Dougiamas's project, contributing on their own initiative because they genuinely cared about open-source education. ## Moodle 2.0: The Big Backend Rewrite (2010-2011) Moodle 2.0, released on 24 November 2010, rightly felt like a fault line. That release brought major changes to repository support, the file picker, file metadata and storage, web services across the entire codebase, cohorts, course completion and prerequisites, conditional activities, and a completely rewritten backup/restore layer. For teams with a lot of customizations, it felt in practice like an almost new platform. For plugin developers, this was brutal. Every plugin we had built or customized, and by 2010 we already had dozens, needed to be rewritten. Hook names changed, function signatures changed, and the conventions around file handling and output changed. What 2.0 did not do, however, was invent the plugin installation and upgrade mechanism from scratch. The XMLDB-based model with install.xml and upgrade.php had existed since Moodle 1.7, and the roles and capabilities model also predated 2.0. Moodle remained strongly transaction-script, lib.php and callback-driven for a long time after; the modern Events API only arrived in 2.6. The ones running heavily customized installations, especially those with custom code that hooked deep into the gradebook, required almost a complete rebuild of the custom code. The lesson was painful but lasting: never couple your business logic to Moodle internals. Build against the stable APIs, and when no stable API exists, isolate the coupling in one place so it is easy to replace. The 2.0 architecture, for all the pain of the migration, was genuinely better. The file API meant we could finally build plugins that handled file attachments reliably. The capability system matured into something much more serious. And the backup/restore layer became, for the first time, a foundation you could seriously build on. ## The 2.x Years: Rhythm, Stabilization, and a First Frontend Turning Point (2011-2015) In the years after 2.0, Moodle settled into a more predictable release cadence. Officially, Moodle targets a six-month cycle for major releases, traditionally in April and October. That rhythm gave the ecosystem calm: plugins, documentation, and upgrade expectations became less erratic. The plugin directory at moodle.org became genuinely useful, coding standards got written down, and the developer documentation visibly improved. For us, this was a productive period. We were building serious custom plugins for training organizations with specific requirements around certification tracking that no off-the-shelf plugin could meet. We built a custom report plugin that queried completion data across multiple courses and generated PDF certificates using TCPDF. It worked, it was maintainable, and upgrading it through 2.2, 2.3, 2.4 was straightforward because the APIs we depended on were stable. For frontend development, Moodle 2.9 is a more important turning point than often credited. From 2.9 onwards, templates became the preferred route for HTML output instead of building HTML in PHP, and Moodle supported AMD JavaScript modules. The 3.x series then made that approach dominant, but it did not start halfway through 3.x. The 2.x era also taught us about Moodle's governance model. By governance we mean: who decides what does and does not land in Moodle core, by which rules, and how the community gets heard. In practice it works like this: Moodle HQ in Perth owns the roadmap, decides on breaking changes, and ultimately approves or rejects core contributions. Proposals and bugs are tracked publicly via tracker.moodle.org, substantive discussion happens on the moodle.org forums, and code contributions arrive as patches that go through peer review before landing in a release branch. The model is not always fast, controversial features can sit in discussion for years, but it produces a platform with a coherent vision and clear accountability. When we disagreed with decisions (and sometimes we did), we learned to engage constructively through the tracker rather than patching around them. ## Moodle 3.2-3.11: Boost, Mustache, Privacy, and a Mature 3.x Line The real Bootstrap shift does not belong to Moodle 3.0 but to Moodle 3.2, released on 5 December 2016. The official 3.2 release notes explicitly call out the new core Boost theme based on Bootstrap 4, along with block and navigation changes. Historically, that is the right moment to place the big theming and frontend shift. For healthcare clients that were starting to require mobile-accessible training for clinical staff, this was transformative. A nurse could now complete a compliance module on a tablet during a break. But the theme architecture change was another migration headache. Custom themes built for 2.x and early 3.x needed to be rewritten for Bootstrap. We had built themes for several clients that were tightly coupled to the old markup structure. Each one needed a full front-end rebuild. Alongside Boost, Mustache became the preferred route to render HTML from a plugin. That approach actually started in 2.9, but from 3.2 it clearly became the default. Mustache templates are testable, they separate concerns properly, and they make it easier for theme developers to override plugin output without touching plugin PHP. We rebuilt our output layer across a significant portion of our plugin catalog during 2016 and 2017. The web services API, which had existed in rudimentary form since 2.0, matured significantly through the 3.x series. By 3.5, it was robust enough to support real mobile applications. For Dentallect, a dental continuing education platform we helped build during this period, the web services API let us build a companion mobile app that synced course progress back to Moodle. The REST API was well-documented and reliable. That experience gave us confidence in Moodle's external API as a foundation for integration work. Another hard milestone in this period is Moodle 3.5. That release formalized that plugins must implement the Privacy API to correctly report, export, and delete which personal data they store for GDPR purposes. That is a much more precise hook than simply saying "privacy became more important in 3.x". We had several Dutch clients, healthcare organizations in particular, for whom data subject access requests had previously been a manual nightmare. The Privacy API made it automatable. Moodle 3.11 was released on 17 May 2021 and is now unsupported: no more fixes for security risks are being issued. As the historical end of the 3.x line, 3.11 is relevant, but technically it is genuinely an old version today. ## Moodle 4.0: The Real UX Reset (2022) Moodle 4.0, released on 19 April 2022, was the biggest visible UX reset since 2.0. That release brought primary, secondary and tertiary navigation, a new course index, page drawers, and a further shift of course rendering to output components and Mustache templates. For plugin and format builders that was a serious change, precisely because a lot of course output formally moved into a newer render layer. For users, this was long overdue and broadly positive. The old Moodle interface had been a barrier to adoption for years, clients would complain that their learners found it confusing. Moodle 4.0 fixed many of those complaints. For plugin developers, it was another migration. Navigation node handling changed again. Block plugins had to be reviewed because blocks now lived in the right-hand block drawer, with reworked regions and the old dock removed. Themes built for 3.x needed updating, with Boost as the official core base for custom theming. For quiz and question plugins, 4.0 was also a real turning point. The release introduced the new qbank plugin type and question versions, updated mod_quiz for that new question bank, integrated BigBlueButton into core Moodle LMS, and explicitly called out accessibility improvements as part of the release. For clients in the healthcare and education sectors, the accessibility improvements were meaningful. Healthcare institutions that had to comply with web accessibility legislation appreciated not having to build accessibility patches into their custom plugins. ## Moodle 4.1-4.5: Stabilization, LTS, and AI in Core Moodle 4.1 was the LTS release of that generation and raised the minimum PHP version to 7.4. After that, 4.5 became the new LTS. According to the official release overview, 4.5 is the most recent LTS, with 5.3 designated as the next LTS. Moodle 4.5 was released on 7 October 2024 and requires PHP 8.1 minimum. Importantly, the AI story does not start with Moodle 5.1. Moodle 4.5 already added an AI subsystem to Moodle LMS, including placements and provider plugins such as Open AI and Azure AI. 5.x builds on that, but 4.5 is the real start of AI in core LMS. The organizational shift during this period was also notable. Moodle HQ rebranded the platform as "Moodle LMS" to distinguish it from their growing suite of products (Moodle Workplace, MoodleNet, MoodleCloud). For us as a specialist agency, this clarified the landscape. When clients asked about "Moodle," we could now point to a specific product with a clear roadmap. ## Moodle 5.0 and 5.1: Modern PHP, Routing, and Further AI Expansion Moodle 5.0 was released on 14 April 2025 and Moodle 5.1 on 6 October 2025. Both require Moodle 4.2.3 minimum as a source version, and PHP 8.2 minimum. For any plugin that had lingered on PHP 7 syntax, this required updates: typed properties, named arguments, enum support, readonly properties, intersection types. Modern PHP is genuinely more expressive and safer than PHP 7, but the upgrade path requires attention. Moodle 5.1 also introduced a new /public directory structure and a new routing engine. On AI, 5.0 expanded the 4.5 base with, among other things, an Ollama provider, multiple provider instances, and admin reporting on AI usage, while 5.1 added course and activity-level access controls, better placement error messaging, and a DeepSeek provider. 5.1 also shipped a refreshed activity chooser and a more central course overview page. As of today, the situation is: Moodle 4.5 is the current LTS/security line, 5.0 and 5.1 are current stable, 5.2 is still planned as a future release, and 5.3 is designated as the next LTS. ## What We Learned About Long-Lived Plugins As a long-standing [Moodle plugin developer](https://ldesignmedia.nl/en/services/moodle-developer), three hundred plugins across fifteen years teaches you patterns. Here is what we know: **Build against the stable plugin API, not against internals.** Core functions prefixed with an underscore, internal database tables not managed through the XMLDB schema, renderer methods that are not in the documented API, these all change between versions. The stable plugin API moves slower and is documented. Use it. **Own your database schema.** Define all your tables through the XMLDB schema in `db/install.xml` and `db/upgrade.php`. Never create tables by running raw SQL from plugin code. The upgrade system exists precisely to handle schema migrations across Moodle versions. **Test against the next version before it releases.** Moodle publishes release candidates. Running your plugin test suite against RC builds catches breaking changes before they hit production. We built a CI pipeline that runs against the current stable, current LTS, and current RC. It has caught many problems early. **Keep your JavaScript modular.** Every time we had AMD modules with clear inputs and outputs, upgrades were smooth. Every time we had inline JavaScript tangled with PHP string output, upgrades were painful. **Respect the Mustache boundary.** Plugin PHP should prepare data arrays. Mustache templates should render HTML. When you blur this boundary, putting business logic in templates, or generating HTML in PHP, maintenance suffers immediately and upgrade complexity accumulates. ## The Human Side: Community and Governance Moodle's community has been one of the most consistent positive forces across fifteen years. The moodle.org forums, the developer chat, the annual MoodleMoot conferences, these are places where genuine knowledge sharing happens. We have contributed code back to the community, we have had contributions from community members improve our own plugins, and we have learned from other developers who were working through the same problems. The governance model, HQ-led with community input through the tracker, has its frustrations. Decision cycles can be slow. Priorities do not always align with what agencies on the ground need. But the model produces a platform with a coherent vision and a genuine commitment to backward compatibility within major versions. The annual MoodleMoot NL events gave us direct connections to the Dutch Moodle community. Those relationships matter, when a client has an unusual problem, knowing who to call in the broader ecosystem is part of delivering good service. ## Advice for Organizations Still Running Older Versions If you are reading this while running Moodle 3.9 or 3.11, you are demonstrably outside supported territory. Security fixes for 3.9 ended on 11 December 2023; 3.11 receives no security fixes at all. The gap with current Moodle versions is not just cosmetic, it is operational and security-related. More importantly, the current upgrade path is staged. Moodle 4.5 requires 4.1.2 minimum as a source version, and Moodle 5.0 and 5.1 require 4.2.3 minimum. From 3.9 or 3.11 you can no longer jump directly to any modern line; at least one intermediate step is unavoidable. Our recommendation: start with an audit. Catalogue every customization, custom plugins, theme overrides, core patches, third-party plugins. For each one, determine the maintenance status. For third-party plugins, check whether they have 4.x/5.x compatible releases. For custom code, estimate the update effort. Then plan a phased upgrade: test environment first, staging second, production last, with each phase having a rollback plan. The organizations that have the hardest time upgrading are the ones that let technical debt accumulate while delaying the upgrade decision. Every year on an old version adds to that debt. ## Looking Forward The core of the story holds: in fifteen years Moodle has changed from a rough, PHP-heavy course platform into a mature, modular LMS. The historical markers sit slightly differently than often assumed: 2.0 was the big backend rupture, 2.9 and 3.2 were the frontend turning point, 4.0 was the UX reset, 4.5 brought AI into core Moodle LMS, and 5.x continues the line with PHP 8.2+, routing, and further AI integration. We have rebuilt alongside it. Each major version has required us to grow, as PHP developers, as front-end engineers, as architects of learning systems. The migration from 1.8 to 2.0 forced us to learn proper plugin architecture. The 2.9/3.2 era forced us to learn modern JavaScript and templating. The 4.0 UX overhaul forced us to invest in UX thinking. Moodle 5.x is pushing us deeper into modern PHP, routing, and AI-augmented development. That is, we think, the right kind of challenge for a team that intends to be doing this for the next fifteen years too. --- ## From Moodle 1.8 to 5.1: Lessons from 15 Years of LMS Evolution (NL) Source: https://ldesignmedia.nl/nl/blog/moodle-1-8-naar-5-1-vijftien-jaar-lms-evolutie Published: 2026-04-15 ## Hoe het begon: Moodle 1.8 en een platform dat zichzelf nog zocht Toen [Ldesign Media](https://ldesignmedia.nl/nl) 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](https://marketplace.moodle.com/?q=luuk+verhoeven) 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](https://ldesignmedia.nl/nl/diensten/moodle-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. --- ## Integrating Moodle with Your Enterprise Stack: SSO, HR Sync, and Payment Systems (EN) Source: https://ldesignmedia.nl/en/blog/integrating-moodle-enterprise-stack Published: 2026-04-24 Moodle is a powerful learning management system, but in enterprise environments it rarely functions as a standalone platform. Organizations typically already operate an identity provider, HR system, CRM, reporting environment, and payment infrastructure. The real value emerges when Moodle becomes a seamless part of that existing landscape. Without proper integration, Moodle quickly becomes yet another system that adds administrative overhead: separate credentials, manual account creation, stale user permissions, detached payment flows, and learning data that does not connect to HR or management reporting. With a professionally integrated Moodle environment, this happens automatically. New employees get timely access to the right courses, departing employees are suspended immediately, payments are processed correctly, and learning data can feed into existing dashboards and compliance processes. In this guide we cover the main integration categories we work with at Ldesign Media: SSO, HR synchronization, payment systems, LTI, xAPI, and Moodle's REST API. We close with a realistic production scenario combining Azure AD, SAP SuccessFactors, and Mollie. ## Why Moodle Should Not Be an Island The most common complaint about poorly integrated LMS environments is simple: users have to "log in separately yet again". It sounds minor, but at scale it causes concrete problems: - users forget credentials and flood the helpdesk; - new employees have no access to mandatory onboarding on day one; - departing employees retain access far too long; - management cannot correlate learning data with HR records; - finance maintains disconnected payment or invoicing flows. A well-integrated Moodle environment removes this friction. Moodle stops being an administrative silo and becomes a node within the organization's existing information flows. ## Single Sign-On: One Identity, One Access Flow Single Sign-On is usually the first and most important integration. Users authenticate with their existing corporate identity and reach Moodle without a separate username or password. ### SAML, OpenID Connect, and LDAP Three approaches are common in enterprise environments. **SAML 2.0** remains a widely used enterprise standard. Moodle acts as the Service Provider while Azure AD, ADFS, Okta, or another identity provider handles authentication. SAML fits best when attribute mapping, signed assertions, and compliance requirements are important. **OpenID Connect**, built on top of OAuth 2.0, is more modern and aligns well with API-first architectures and SaaS platforms like Microsoft Entra ID, Google Workspace, and Auth0. For new cloud-first environments, OIDC is often a strong choice. **LDAP** is mostly used in legacy environments with on-premises Active Directory or OpenLDAP. It works reliably but does not deliver a true modern SSO experience and requires direct network connectivity between Moodle and the directory. ### Azure AD / Microsoft Entra ID A common integration is Moodle with Microsoft Entra ID, formerly Azure AD. In a standard SAML configuration Moodle is registered as an Enterprise Application. Entity ID, ACS URL, and Name ID are then configured, after which attributes such as first name, last name, email, department, and employee ID are mapped into Moodle. On the Moodle side, Catalyst IT's SAML2 plugin is frequently used. It supports multiple identity providers, Just-In-Time provisioning, and attribute-based cohort assignment. ## HR Synchronization: Automated Provisioning Authentication governs who may log in, but not which accounts should exist, which roles users hold, or which courses they should be enrolled in. That requires HR synchronization. For enterprise clients we often integrate with systems such as SAP SuccessFactors and Workday. The HR system remains the source of truth. Typically we build a middleware layer that receives HR events, translates them into Moodle actions, and calls Moodle's web services. Typical actions include: - creating new users; - updating existing users; - suspending users on termination; - adding users to cohorts based on department, job, or role; - letting course enrollments follow automatically through cohort links. ### Cohorts as a Scalable Enrollment Model In enterprise environments it is more efficient to link cohorts to courses rather than individual users. The HR sync then drives assignments such as: - DEPT_SALES → Sales cohort → sales onboarding and product training; - DEPT_IT → IT cohort → security awareness and compliance; - ROLE_MANAGER → manager cohort → leadership training. When an employee changes role or department, Moodle adjusts access automatically. Completion data is preserved, which matters for audit and compliance requirements. ### Termination: Suspend, Do Not Delete (Within GDPR Limits) On termination we almost always recommend suspending accounts rather than deleting them immediately. Learning history remains available for compliance and reporting while the user can no longer access the system. Deletion is permanent; suspension is auditable and reversible. Suspension, however, must not become an indefinite state. GDPR requires that personal data is not kept longer than necessary for the original purpose (storage limitation, Article 5(1)(e)) and preserves the data subject's right to erasure (Article 17). In practice this means: - define an explicit retention period per data category, backed by a lawful basis (for example, audit or compliance obligations for mandatory training); - automatically anonymize or delete suspended accounts once the retention period expires; - extract the required completion and audit data upfront into aggregated or pseudonymized reports, so downstream reporting no longer depends on identifiable user data; - honour erasure requests within the GDPR deadline, unless a statutory retention duty explicitly applies; - document the retention and deletion policy in the records of processing and the privacy notice. Suspension gives the right operational control on termination, but must always sit inside a broader GDPR-compliant retention and deletion policy. ## Payment Integrations: Mollie, Stripe, and iDEAL For organizations selling training externally, or charging internal cost centers, Moodle must connect to a payment infrastructure. In the Netherlands iDEAL is often essential, which makes Mollie a natural choice. A payment integration usually takes the form of a custom enrolment plugin. It displays the course price, redirects the user to the hosted checkout at Mollie or Stripe, and only enrolls the user once the payment has been confirmed server-side via webhook. That webhook pattern matters. A browser redirect alone is not reliable enough because users may close the window before the return trip completes. The webhook confirms the payment independently of the browser session. Common payment models include: - one-time payment per course; - subscription access to a course library; - bulk purchase with seat licenses; - internal cost-center allocation without direct payment. ## LTI: Connecting External Learning Tools Learning Tools Interoperability, or LTI, is used to securely connect external learning tools to Moodle. Think simulations, virtual labs, assessment platforms, or content libraries. Moodle can act as an LTI consumer, where external tools open inside a Moodle course. The external tool receives context about user, course, and activity. Conversely, Moodle can act as an LTI provider, for example when another platform needs to surface Moodle content. For new integrations, LTI 1.3 is the recommended standard. It uses OAuth 2.0 and JWTs, supports deep linking, and is more secure than older LTI 1.1 integrations. ## xAPI: Sending Learning Data to an External LRS xAPI, also known as the Experience API or Tin Can, allows learning activities to be emitted as statements to an external Learning Record Store. This is particularly valuable when learning data from multiple systems needs to be aggregated. An xAPI integration is often used for: - central compliance audits; - reporting outside of Moodle; - connecting to enterprise learning analytics; - storing learning activity in an independent LRS platform. With Moodle's Logstore xAPI plugin you can forward course completions, quiz attempts, activity views, and custom events, among others. ## Moodle REST API: Building Custom Integrations Virtually every serious Moodle integration ends up using Moodle's web services framework. Through it, external systems can manage users, courses, cohorts, enrollments, and results. Frequently used functions include: - core_user_create_users; - core_user_update_users; - core_cohort_add_cohort_members; - enrol_manual_enrol_users; - core_course_get_courses; - gradereport_user_get_grade_items. When the standard functions are insufficient, we build custom external functions in a plugin. That allows a single business API call to cover a full HR mutation, including user update, cohort change, and audit logging. ## Middleware or Direct Moodle Plugin? There are two broad architectural choices. With a **direct plugin integration** Moodle talks to the external system directly. This suits relatively simple integrations such as a single SSO provider or a single payment provider. With a **middleware architecture** a dedicated integration layer sits between Moodle and external systems. It receives events, translates payloads, retries on failure, logs errors, and calls Moodle's API. This is more robust when multiple systems or complex data flows are involved. For enterprise environments with three or more connected systems, middleware is usually the better long-term choice. ## Event-Driven and Scheduled Synchronization Not every synchronization needs to be real time. For critical processes such as onboarding and termination, event-driven synchronization is ideal. The HR system pushes an event directly to the middleware, and Moodle is updated almost immediately. For reconciliation a scheduled task remains useful. It periodically verifies that all systems are still consistent and corrects any drift. In practice we combine both models: real time where needed, batch processing where it is more efficient. ## Security: Essential in Every Integration Enterprise integrations handle sensitive data: personal information, roles, learning history, payment details, and authentication tokens. Security measures are not optional. Key principles include: - use dedicated service accounts per integration; - restrict Moodle web service tokens to minimal privileges; - use HTTPS exclusively and validate certificates; - verify webhook signatures; - log synchronization actions and errors; - forward only the data the receiving system actually needs; - where possible, restrict server-to-server access to known IP addresses. ## Production Scenario: Azure AD, SAP SuccessFactors, and Mollie For a Dutch enterprise organization with roughly 2,000 employees we built an integrated Moodle environment with three main connections: 1. SSO via Microsoft Entra ID; 2. automated HR provisioning from SAP SuccessFactors; 3. external training sales through Mollie and iDEAL. Moodle was registered as an Enterprise Application in Entra ID. Attributes such as employee ID, department, and cost center were passed to Moodle at login. SAP SuccessFactors delivered HR events to a middleware layer that created, updated, or suspended users and synchronized cohorts. For external partners, a Mollie integration allowed them to purchase training and be enrolled automatically after successful payment. The result was an LMS that fit into existing processes rather than sitting alongside them. Employees logged in with their Microsoft account, course enrollments flowed automatically from HR data, and external participants could register through a familiar payment flow. ## Conclusion Moodle integration is not a technical afterthought; it is a defining factor for adoption, manageability, and compliance. SSO, HR synchronization, and payments typically form the foundation. LTI tools, xAPI reporting, CRM connections, dashboards, and custom portals layer on top. Organizations that treat Moodle as part of their enterprise architecture get more value from their LMS: less manual administration, fewer support tickets, better data quality, and a smoother learning experience for users. At Ldesign Media we help organizations design, build, and maintain Moodle integrations. Whether it is a single Entra ID connection or a full middleware layer between Moodle, SAP, Salesforce, and a payment platform, we make sure Moodle fits inside your existing digital landscape. --- ## Integrating Moodle with Your Enterprise Stack: SSO, HR Sync, and Payment Systems (NL) Source: https://ldesignmedia.nl/nl/blog/moodle-integreren-met-enterprise-stack Published: 2026-04-24 Moodle is een krachtige leeromgeving, maar in enterprise-omgevingen functioneert het zelden als losstaand platform. Organisaties beschikken vaak al over een identity provider, HR-systeem, CRM, rapportageomgeving en betaalinfrastructuur. De echte waarde ontstaat wanneer Moodle naadloos onderdeel wordt van dat bestaande landschap. Zonder goede integratie wordt Moodle al snel een extra systeem dat beheerlast veroorzaakt: aparte inloggegevens, handmatige accountaanmaak, verouderde gebruikersrechten, losse betaalstromen en leerdata die niet aansluit op HR- of managementrapportages. Met een professioneel geïntegreerde Moodle-omgeving gebeurt dit automatisch. Nieuwe medewerkers krijgen tijdig toegang tot de juiste cursussen, vertrekkende medewerkers worden direct geschorst, betalingen worden correct verwerkt en leerdata kan worden gebruikt in bestaande dashboards en complianceprocessen. In deze gids behandelen we de belangrijkste integratiecategorieën waar wij bij Ldesign Media mee werken: SSO, HR-synchronisatie, betaalsystemen, LTI, xAPI en Moodle's REST API. We sluiten af met een herkenbaar praktijkscenario rond Azure AD, SAP SuccessFactors en Mollie. ## Waarom Moodle geen eiland mag zijn De meest gehoorde klacht bij slecht geïntegreerde LMS-omgevingen is eenvoudig: gebruikers moeten "alweer ergens apart inloggen". Dat lijkt klein, maar veroorzaakt op schaal concrete problemen: - gebruikers vergeten inloggegevens en belasten de helpdesk; - nieuwe medewerkers hebben op hun eerste werkdag nog geen toegang tot verplichte onboarding; - vertrekkende medewerkers behouden onnodig lang toegang; - management kan leerdata niet koppelen aan HR-gegevens; - finance beheert losse betaal- of facturatiestromen. Een goed geïntegreerde Moodle-omgeving voorkomt deze frictie. Moodle wordt dan geen administratieve silo, maar een knooppunt in de bestaande informatiestromen van de organisatie. ## Single Sign-On: één identiteit, één toegangsstroom Single Sign-On is meestal de eerste en belangrijkste integratie. Gebruikers melden zich aan via de bestaande bedrijfsidentiteit en krijgen toegang tot Moodle zonder aparte gebruikersnaam of wachtwoord. ### SAML, OpenID Connect en LDAP Voor enterprise-omgevingen zijn er drie veelvoorkomende benaderingen. **SAML 2.0** is nog altijd een veelgebruikte enterprise-standaard. Moodle fungeert als Service Provider, terwijl Azure AD, ADFS, Okta of een andere identity provider de authenticatie verzorgt. SAML is vooral geschikt wanneer attribuutmapping, ondertekende assertions en compliance-eisen belangrijk zijn. **OpenID Connect**, gebouwd bovenop OAuth 2.0, is moderner en sluit goed aan bij API-first architecturen en SaaS-platformen zoals Microsoft Entra ID, Google Workspace en Auth0. Voor nieuwe cloudgerichte omgevingen is OIDC vaak een sterke keuze. **LDAP** wordt vooral gebruikt in legacy-omgevingen met on-premises Active Directory of OpenLDAP. Het werkt betrouwbaar, maar biedt geen echte moderne SSO-ervaring en vereist directe netwerkverbinding tussen Moodle en de directory. ### Azure AD / Microsoft Entra ID Een veelvoorkomende integratie is Moodle met Microsoft Entra ID, voorheen Azure AD. In een standaard SAML-configuratie wordt Moodle geregistreerd als Enterprise Application. Vervolgens worden onder andere de Entity ID, ACS URL en Name ID ingesteld, waarna attributen zoals voornaam, achternaam, e-mailadres, afdeling en employee ID naar Moodle worden gemapt. Voor Moodle wordt vaak de SAML2-plugin van Catalyst IT gebruikt. Deze ondersteunt onder andere meerdere identity providers, Just-In-Time provisioning en attribuutgebaseerde cohortindeling. ## HR-synchronisatie: automatische provisioning Authenticatie regelt wie mag inloggen, maar niet welke accounts moeten bestaan, welke rollen gebruikers hebben en voor welke cursussen ze moeten worden ingeschreven. Daarvoor is HR-synchronisatie nodig. Bij enterprise-klanten integreren wij vaak met systemen zoals SAP SuccessFactors en Workday. Het HR-systeem blijft daarbij de bron van waarheid. Wij bouwen meestal een middlewarelaag die HR-events ontvangt, vertaalt naar Moodle-acties en vervolgens Moodle's webservices aanroept. Typische acties zijn: - nieuwe gebruikers aanmaken; - bestaande gebruikers bijwerken; - gebruikers schorsen bij uitdiensttreding; - gebruikers toevoegen aan cohorten op basis van afdeling, functie of rol; - cursusinschrijvingen automatisch laten verlopen via cohortkoppelingen. ### Cohorten als schaalbaar inschrijvingsmodel In enterprise-omgevingen is het efficiënter om niet individuele gebruikers, maar cohorten aan cursussen te koppelen. De HR-sync bepaalt dan bijvoorbeeld: - DEPT_SALES → Sales-cohort → Sales onboarding en producttraining; - DEPT_IT → IT-cohort → security awareness en compliance; - ROLE_MANAGER → managerscohort → leiderschapstraining. Wanneer een medewerker van functie of afdeling verandert, past Moodle de toegang automatisch aan. Voltooiingsdata blijft behouden, wat belangrijk is voor audit- en compliance-eisen. ### Uitdiensttreding: schorsen, niet verwijderen (binnen AVG-kaders) Bij uitdiensttreding adviseren wij vrijwel altijd om accounts te schorsen in plaats van direct te verwijderen. Zo blijft leerhistorie beschikbaar voor compliance en rapportage, terwijl de gebruiker geen toegang meer heeft. Verwijdering is definitief; schorsing is controleerbaar en omkeerbaar. Schorsing mag echter geen permanente oplossing zijn. De AVG/GDPR vereist dat persoonsgegevens niet langer worden bewaard dan nodig voor het oorspronkelijke doel (opslagbeperking, art. 5 lid 1 sub e) en dat betrokkenen recht houden op verwijdering (art. 17). In de praktijk betekent dit: - leg een concrete bewaartermijn vast per datacategorie, onderbouwd door een wettelijke grondslag (bijvoorbeeld compliance- of audit-eisen voor verplichte trainingen); - anonimiseer of verwijder accounts automatisch zodra de bewaartermijn verstrijkt; - extraheer benodigde voltooiings- en auditgegevens vooraf naar geaggregeerde of gepseudonimiseerde rapportages, zodat losse rapportages later geen herleidbare userdata meer nodig hebben; - honoreer verwijderverzoeken binnen de AVG-termijn, tenzij een wettelijke bewaarplicht expliciet van toepassing is; - documenteer het bewaar- en verwijderbeleid in het verwerkingsregister en de privacyverklaring. Schorsen geeft dus de juiste controle bij uitdiensttreding, maar moet altijd onderdeel zijn van een breder AVG-conform bewaar- en verwijderbeleid. ## Betaalintegraties: Mollie, Stripe en iDEAL Voor organisaties die trainingen extern verkopen, of interne kostenplaatsen willen belasten, moet Moodle gekoppeld worden aan een betaalinfrastructuur. In Nederland is iDEAL vaak essentieel, waardoor Mollie een logische keuze is. Een betaalintegratie bestaat meestal uit een aangepaste enrolment-plugin. Die toont de cursusprijs, stuurt de gebruiker naar de hosted checkout van Mollie of Stripe en schrijft de gebruiker pas in wanneer de betaling server-side is bevestigd via een webhook. Dat webhookpatroon is belangrijk. Een browserredirect alleen is onvoldoende betrouwbaar, omdat gebruikers het venster kunnen sluiten voordat de terugkoppeling is afgerond. De webhook bevestigt de betaling onafhankelijk van de browsersessie. Veelvoorkomende betaalmodellen zijn: - eenmalige betaling per cursus; - abonnementstoegang tot een cursusbibliotheek; - bulkinkoop met stoellicenties; - interne kostplaatsregistratie zonder directe betaling. ## LTI: externe leertools koppelen Learning Tools Interoperability, kortweg LTI, wordt gebruikt om externe leertools veilig te koppelen aan Moodle. Denk aan simulaties, virtuele labs, toetsplatformen of contentbibliotheken. Moodle kan optreden als LTI-consumer, waarbij externe tools binnen een Moodle-cursus worden geopend. De externe tool ontvangt dan context over gebruiker, cursus en activiteit. Andersom kan Moodle ook als LTI-provider fungeren, bijvoorbeeld wanneer een ander platform Moodle-content wil tonen. Voor nieuwe integraties is LTI 1.3 de aangewezen standaard. Deze gebruikt OAuth 2.0 en JWT's, ondersteunt deep linking en is veiliger dan oudere LTI 1.1-integraties. ## xAPI: leerdata naar een externe LRS xAPI, ook bekend als Experience API of Tin Can, maakt het mogelijk om leeractiviteiten als statements naar een externe Learning Record Store te sturen. Dit is vooral waardevol wanneer leerdata uit meerdere systemen moet worden samengebracht. Een xAPI-integratie wordt vaak gebruikt voor: - centrale compliance-audits; - rapportage buiten Moodle; - koppeling met enterprise learning analytics; - opslag van leeractiviteit in een onafhankelijk LRS-platform. Met Moodle's Logstore xAPI-plugin kunnen onder andere cursusvoltooiingen, quizpogingen, activiteitweergaven en aangepaste events worden doorgestuurd. ## Moodle REST API: maatwerkintegraties bouwen Vrijwel elke serieuze Moodle-integratie gebruikt uiteindelijk Moodle's webservicesframework. Daarmee kunnen externe systemen gebruikers, cursussen, cohorten, inschrijvingen en resultaten beheren. Veelgebruikte functies zijn onder andere: - core_user_create_users; - core_user_update_users; - core_cohort_add_cohort_members; - enrol_manual_enrol_users; - core_course_get_courses; - gradereport_user_get_grade_items. Wanneer standaardfuncties niet genoeg zijn, bouwen wij maatwerk via een plugin met eigen externe functies. Daarmee kan bijvoorbeeld één zakelijke API-call worden gemaakt voor een volledige HR-mutatie, inclusief gebruiker bijwerken, cohort wijzigen en auditlogging. ## Middleware of directe Moodle-plugin? Er zijn grofweg twee architectuurkeuzes. Bij een **directe pluginintegratie** communiceert Moodle rechtstreeks met het externe systeem. Dit is geschikt voor relatief eenvoudige integraties, zoals één SSO-provider of één betaalprovider. Bij een **middlewarearchitectuur** staat er een aparte integratielaag tussen Moodle en externe systemen. Die ontvangt events, vertaalt payloads, voert retries uit, logt fouten en roept Moodle's API aan. Dit is robuuster bij meerdere systemen of complexe datastromen. Voor enterprise-omgevingen met drie of meer gekoppelde systemen is middleware meestal de betere langetermijnkeuze. ## Event-driven én geplande synchronisatie Niet elke synchronisatie hoeft realtime te zijn. Voor kritieke processen, zoals onboarding en uitdiensttreding, is event-driven synchronisatie ideaal. Het HR-systeem stuurt dan direct een event naar de middleware, waarna Moodle vrijwel direct wordt bijgewerkt. Voor reconciliatie blijft een geplande taak nuttig. Die controleert periodiek of alle systemen nog consistent zijn en corrigeert eventuele verschillen. In de praktijk combineren wij vaak beide modellen: realtime waar nodig, batchverwerking waar dat efficiënter is. ## Beveiliging: essentieel bij elke integratie Enterprise-integraties verwerken gevoelige gegevens: persoonsgegevens, rollen, leerhistorie, betaalinformatie en authenticatietokens. Daarom zijn beveiligingsmaatregelen geen bijzaak. Belangrijke uitgangspunten zijn: - gebruik aparte serviceaccounts per integratie; - beperk Moodle webservice-tokens tot minimale rechten; - gebruik uitsluitend HTTPS en valideer certificaten; - controleer webhookhandtekeningen; - log synchronisatie-acties en fouten; - stuur alleen data door die het ontvangende systeem nodig heeft; - beperk server-to-server toegang waar mogelijk tot bekende IP-adressen. ## Praktijkscenario: Azure AD, SAP SuccessFactors en Mollie Voor een Nederlandse enterprise-organisatie met ongeveer 2.000 medewerkers bouwden wij een geïntegreerde Moodle-omgeving met drie hoofdkoppelingen: 1. SSO via Microsoft Entra ID; 2. automatische HR-provisioning vanuit SAP SuccessFactors; 3. externe trainingsverkoop via Mollie en iDEAL. Moodle werd als Enterprise Application geregistreerd in Entra ID. Attributen zoals employee ID, afdeling en kostenplaats werden bij login doorgegeven aan Moodle. SAP SuccessFactors leverde HR-events aan een middlewarelaag, die gebruikers aanmaakte, bijwerkte of schorste en cohorten synchroniseerde. Voor externe partners werd een Mollie-integratie gebouwd waarmee zij trainingen konden kopen en na succesvolle betaling automatisch werden ingeschreven. Het resultaat was een LMS dat aansloot op bestaande processen in plaats van daar los naast te staan. Medewerkers logden in met hun Microsoft-account, cursusinschrijvingen volgden automatisch uit HR-data en externe deelnemers konden zichzelf aanmelden via een vertrouwde betaalstroom. ## Conclusie Moodle-integratie is geen technische bijzaak, maar een bepalende factor voor adoptie, beheerbaarheid en compliance. SSO, HR-synchronisatie en betalingen vormen vaak de basis. Daarbovenop komen koppelingen met LTI-tools, xAPI-rapportage, CRM-systemen, dashboards en maatwerkportalen. Organisaties die Moodle behandelen als onderdeel van hun enterprise-architectuur halen meer waarde uit hun LMS: minder handmatig beheer, minder supportvragen, betere datakwaliteit en een soepelere leerervaring voor gebruikers. Bij Ldesign Media helpen wij organisaties met het ontwerpen, bouwen en beheren van Moodle-integraties. Of het nu gaat om één Entra ID-koppeling of een volledige middlewarelaag tussen Moodle, SAP, Salesforce en een betaalplatform: wij zorgen dat Moodle past binnen uw bestaande digitale landschap. --- ## How Custom LMS Development Improves Employee Training and Business Performance (EN) Source: https://ldesignmedia.nl/en/blog/custom-lms-improves-employee-training Published: 2026-05-05 Off-the-shelf learning platforms solve some problems, but they rarely solve your core problems. At [Ldesign Media](https://ldesignmedia.nl/en), we have more than 15 years of experience helping organizations build custom Moodle environments that align with their actual workflows, learners, and business goals. In this guide, we explain why custom LMS development delivers better results than generic platforms, and how this directly translates into better employee training and stronger business outcomes. A custom-built LMS fits your organization's structure, not the other way around. ## 1. What Is Custom LMS Development? A Learning Management System (LMS) is the software that delivers, tracks, and manages employee training. Most organizations start with a commercial, off-the-shelf platform and quickly discover its limitations: stuck workflows, missing integrations, interfaces that frustrate learners, and features they never use but still pay for. **Custom LMS development** means building or thoroughly customizing an LMS – usually Moodle – so that it aligns with your specific processes, branding, user groups, and system environment. This ranges from developing individual plugins that add missing functionality to fully custom-designing a learning environment. Moodle is the world's most widely used open-source learning platform (LMS) and the platform Ldesign Media specializes in. Its modular architecture makes it ideal for customization: you only extend what you need. ### Custom Development vs Standard Configuration Different approaches are possible: - **Standard configuration:** Toggle settings, use built-in themes, select existing plugins — best for simple use cases - **Custom plugin development:** New modules, blocks, or activity types from scratch — best for unique workflows - **LMS customization and theming:** Align UX, navigation, and branding with your organization — best for strong brand requirements - **Integrations and automation:** Connect LMS to HR, SSO, SIS, or other tools via API — best for existing system landscapes - **Technical consulting:** Architecture advice, code review, upgrade planning — best for teams needing expert input ## 2. Five Ways Custom LMS Development Improves Employee Training ### 2.1 Training That Matches Your Actual Work Processes Generic platforms are built around average use cases. Custom development starts with your specific use case. For an airline managing cabin crew, this means a scalable module tailored to duty rosters and certifications. For a chain of dental practices, this means a learning environment that aligns with clinical roles and compliance requirements. Ldesign Media has developed specialized Moodle solutions for clients like KLM and Nedap. ### 2.2 Higher Learner Engagement Through Better UX Completion rates for corporate training average around 30% on generic platforms. The main reason people abandon a course isn't the content – it's a confusing or frustrating interface. A custom-designed learning environment, built with your learners in mind, removes obstacles at every step. Our TabTiles plugin transforms Moodle's standard course view into a visual, tile-based layout with animations and progress feedback. ### 2.3 Automated Enrollment and Administration HR teams lose significant time manually managing course assignments, tracking completions, and sending reminders. With custom automation, that overhead disappears: - Automatic enrollment rules triggered by HR system events - Group assignments upon registration - Automated certificate delivery Our Group Auto-Enrol plugin automatically assigns learners to the right groups as soon as they enroll. ### 2.4 Seamless Integration With Your Existing Systems Training data locked in a standalone LMS is difficult to use. When your LMS is integrated with your HR system, performance management platform, or single sign-on infrastructure, training becomes part of your operational data flow. We develop integrations with SSO providers, HRIS platforms, payment processors (iDEAL, Mollie), postcode APIs, and more. ### 2.5 Reporting That Actually Gives Management Insight Standard LMS reports show who started a course. Custom reporting shows which training predicts performance, where teams have skill gaps, and which modules aren't landing. When reporting is based on your KPIs, L&D becomes a strategic conversation. ## 3. The Business Case for Custom LMS Investment Training is a cost center until it's viewed as a profit driver. ### Faster Time-to-Productivity for New Employees A well-structured onboarding program in a custom LMS can reduce time-to-competency by 40-60%. Structured learning paths, role-based content, and checkpoints give managers confidence. ### Compliance Without Manual Overhead For regulated industries – financial services, healthcare, aviation, construction – compliance training isn't optional. A custom LMS automates the entire cycle: enrollment, deadline reminders, certification, and audit-ready reporting. > Ldesign Media developed a scalable Moodle module for KLM cabin crew training. This module manages certification registration, mandatory training cycles, and role-specific learning paths. ### Lower Costs for Training at Scale Once developed, it costs virtually nothing to re-deliver digital training content. An investment in custom LMS typically pays back within 12 to 18 months. ### Skill Gap Visibility Enables Proactive Development When learning data is structured, linked to competencies, and connected to performance data, skill gaps can be detected before they become business problems. ## 4. Why Moodle Is the Right Foundation for Custom LMS Development Many organizations default to SaaS platforms because they seem quick to implement. But SaaS platforms have hidden limitations: limited customization options, vendor lock-in, per-user pricing that scales poorly. Moodle is different. As an open-source platform, it gives you full control over your environment, your data, and your customizations. Thanks to its plugin architecture, new functionality can be easily added. **Comparison Generic SaaS LMS vs Custom Moodle:** - Customization depth: Limited vs Complete (plugins, UX, workflows, data) - Data ownership: Vendor-controlled vs Fully yours - Per-user pricing: Scales with count vs One-time development - Integration flexibility: Only pre-built connectors vs Any system with API - Vendor dependency: High vs Low We've been working with Moodle since version 1.8 and have developed more than 300 plugins. ## 5. The Custom LMS Development Process Many organizations hesitate to invest in custom development because they expect it to be slow, expensive, or technically risky. With the right partner, none of that has to be the case. 1. **Discovery and scoping** — Map learning objectives, user groups, existing systems, and technical constraints 2. **Architecture and design** — Propose a solution that stays close to Moodle core 3. **Plugin or feature development** — Develop according to Moodle's official coding standards 4. **Integration and testing** — Connect LMS to existing systems and test thoroughly 5. **Deployment and training** — Handle technical deployment and administrator training 6. **Ongoing support and optimization** — Long-term support, upgrades, and performance optimization Short communication lines are a deliberate part of our model. You work directly with senior developers. ## 6. Signs Your Organization Needs a Custom LMS - Your LMS isn't integrated with your HR or SSO system - Learner adoption is low - You're paying for features you never use - Compliance tracking still happens in spreadsheets - Your organization has grown significantly and per-user SaaS is becoming too expensive - You have specific, role-based learning paths ## 7. Frequently Asked Questions ### How long does custom LMS development take? A single custom plugin takes two to six weeks. A complete environment with theme, integrations, and multiple plugins typically takes three to five months. ### Do I need to manage Moodle hosting myself? No. We can advise on hosting configuration or recommend a managed Moodle hosting partner. ### Will custom plugins still work after a Moodle upgrade? We follow Moodle's official coding standards, ensuring customizations remain compatible with future versions. We also support clients through major version upgrades. ### What does custom LMS development cost? A focused plugin starts at a few thousand euros; a complete environment is a larger investment with multi-year returns. ### Is Moodle suitable for corporate training? Absolutely. Moodle is used for corporate training across diverse sectors, including aviation (KLM), manufacturing, healthcare, and financial services. ## Conclusion Custom LMS development isn't a luxury reserved for large enterprises. It's the practical choice for any organization whose training program has outgrown the capabilities of a standard platform. The benefits – completion rates, saved administrative time, compliance certainty, and measurable performance improvement – consistently outweigh the investment. Ldesign Media has been helping organizations get the most out of Moodle for more than 15 years. Ready to build a learning platform that truly fits your organization? [Let's start with a conversation](https://ldesignmedia.nl/en/contact). --- ## How Custom LMS Development Improves Employee Training and Business Performance (NL) Source: https://ldesignmedia.nl/nl/blog/maatwerk-lms-verbetert-medewerkerstraining Published: 2026-05-05 Kant-en-klare leerplatformen lossen sommige problemen op, maar ze lossen zelden de kernproblemen op. Bij [Ldesign Media](https://ldesignmedia.nl/nl) hebben we meer dan 15 jaar ervaring in het helpen van organisaties bij het bouwen van op maat gemaakte Moodle-omgevingen die aansluiten op hun daadwerkelijke workflows, leerlingen en bedrijfsdoelen. In deze handleiding leggen we uit waarom maatwerk-LMS-ontwikkeling betere resultaten oplevert dan generieke platforms, en hoe dit zich direct vertaalt in betere training van medewerkers en sterkere bedrijfsresultaten. Een speciaal ontwikkeld LMS past bij de structuur van je organisatie, en niet andersom. ## 1. Wat is maatwerk LMS-ontwikkeling? Een Learning Management System (LMS) is de software die trainingen voor medewerkers aanbiedt, bijhoudt en beheert. De meeste organisaties beginnen met een commercieel, standaardplatform en ontdekken al snel de beperkingen ervan: vastgelopen workflows, ontbrekende integraties, interfaces die cursisten frustreren en functies die ze nooit gebruiken, maar waar ze wel voor betalen. **Maatwerk LMS-ontwikkeling** houdt in dat een LMS – meestal Moodle – wordt gebouwd of grondig wordt aangepast, zodat het aansluit op je specifieke processen, huisstijl, gebruikersgroepen en systeemomgeving. Dit varieert van het ontwikkelen van individuele plugins die een ontbrekende functie toevoegen tot het volledig op maat ontwerpen van een leeromgeving. Moodle is 's werelds meest gebruikte open-source leerplatform (LMS) en het platform waarin Ldesign Media gespecialiseerd is. De modulaire architectuur maakt het bij uitstek geschikt voor maatwerk: je breidt alleen uit wat je nodig hebt. ### Maatwerkontwikkeling versus standaardconfiguratie Er zijn verschillende benaderingen mogelijk: - **Standaardconfiguratie:** Instellingen in- of uitschakelen, ingebouwde thema's gebruiken, bestaande plug-ins selecteren — best voor eenvoudige gebruiksscenario's - **Ontwikkeling van aangepaste plugins:** Nieuwe modules, blokken of activiteitstypen helemaal vanaf nul — best voor unieke workflows - **LMS-aanpassing en -thema's:** UX, navigatie en branding afstemmen op je organisatie — best voor sterke merkeisen - **Integraties en automatisering:** LMS koppelen aan HR, SSO, SIS of andere tools via API — best voor bestaand systeemlandschap - **Technisch advies:** Architectuuradvies, codebeoordeling, upgradeplanning — best voor teams die expert input nodig hebben ## 2. Vijf manieren waarop maatwerk LMS de training van medewerkers verbetert ### 2.1 Training die aansluit op je daadwerkelijke werkprocessen Generieke platforms zijn gebouwd rond gemiddelde gebruiksscenario's. Maatwerk begint bij jouw specifieke gebruiksscenario. Voor een luchtvaartmaatschappij die cabinepersoneel aanstuurt, betekent dit een schaalbare module die is afgestemd op dienstroosters en certificeringen. Voor een keten van tandartspraktijken betekent dit een leeromgeving die aansluit op klinische rollen en nalevingsvereisten. Ldesign Media heeft gespecialiseerde Moodle-oplossingen ontwikkeld voor klanten zoals KLM en Nedap. ### 2.2 Hogere betrokkenheid van leerlingen door betere UX Het slagingspercentage voor bedrijfstrainingen ligt gemiddeld rond de 30% op generieke platforms. De belangrijkste reden waarom mensen een cursus afbreken, is niet de inhoud, maar een verwarrende of frustrerende interface. Een op maat ontworpen leeromgeving, gebouwd met je cursisten in gedachten, neemt obstakels bij elke stap weg. Onze TabTiles-plugin transformeert de standaard cursusweergave van Moodle in een visuele, op tegels gebaseerde lay-out met animaties en voortgangsfeedback. ### 2.3 Geautomatiseerde inschrijving en administratie HR-teams verliezen aanzienlijk veel tijd aan het handmatig beheren van cursusopdrachten, het bijhouden van voltooiingen en het versturen van herinneringen. Met maatwerkautomatisering verdwijnt die overhead: - Automatische inschrijvingsregels geactiveerd door HR-systeem events - Groepstoewijzingen bij registratie - Geautomatiseerde verzending van certificaten Onze Group Auto-Enrol-plugin wijst cursisten automatisch toe aan de juiste groepen zodra ze zich inschrijven. ### 2.4 Naadloze integratie met je bestaande systemen Trainingsgegevens die opgesloten zitten in een losstaand LMS zijn moeilijk te gebruiken. Wanneer je LMS is geïntegreerd met je HR-systeem, platform voor prestatiebeheer of infrastructuur voor single sign-on, wordt training onderdeel van je operationele gegevensstroom. Wij ontwikkelen integraties met SSO-providers, HRIS-platformen, betalingsverwerkers (iDEAL, Mollie), postcode-API's en meer. ### 2.5 Rapportage die het management daadwerkelijk inzicht geeft Standaard LMS-rapporten laten zien wie een cursus is gestart. Aangepaste rapportages laten zien welke trainingen de prestaties voorspellen, waar teams vaardigheidstekorten hebben en welke modules niet aanslaan. Wanneer rapportages zijn gebaseerd op je KPI's wordt L&D een strategisch gesprek. ## 3. De zakelijke argumenten voor investeringen in maatwerk LMS Training is een kostenpost totdat het als winstmotor wordt beschouwd. ### Snellere productiviteitsopbouw voor nieuwe medewerkers Een goed gestructureerd onboardingprogramma in een op maat gemaakt LMS kan de tijd die nodig is om competent te worden met 40-60% verkorten. Gestructureerde leerpaden, op rollen gebaseerde inhoud en controlepunten geven managers zekerheid. ### Naleving zonder handmatige overhead Voor gereguleerde sectoren – financiële dienstverlening, gezondheidszorg, luchtvaart, bouw – is compliance-training niet optioneel. Een op maat gemaakt LMS automatiseert de volledige cyclus: inschrijving, herinneringen voor deadlines, certificering en rapportage die klaar is voor audits. > Ldesign Media heeft een schaalbare Moodle-module ontwikkeld voor de training van KLM-cabinepersoneel. Deze module beheert certificeringsregistratie, verplichte trainingscycli en functiespecifieke leertrajecten. ### Lagere kosten voor trainingen op grote schaal Eenmaal ontwikkeld, kost het vrijwel niets om digitale trainingscontent opnieuw aan te bieden. Een investering in maatwerk LMS is doorgaans binnen 12 tot 18 maanden terugverdiend. ### Inzicht in de vaardigheidskloof maakt proactieve ontwikkeling mogelijk Wanneer leergegevens gestructureerd zijn, gekoppeld aan competenties en verbonden aan prestatiegegevens, kunnen vaardigheidstekorten worden opgespoord voordat ze zakelijke problemen worden. ## 4. Waarom Moodle de juiste basis is voor maatwerk LMS Veel organisaties kiezen standaard voor SaaS-platformen, omdat deze snel te implementeren lijken. Maar SaaS-platformen kennen verborgen beperkingen: beperkte aanpassingsmogelijkheden, afhankelijkheid van één leverancier, prijsstelling per gebruiker die moeizaam schaalbaar is. Moodle is anders. Als open-sourceplatform geeft het je volledige controle over je omgeving, je gegevens en je aanpassingen. Dankzij de plugin-architectuur kan nieuwe functionaliteit eenvoudig worden toegevoegd. **Vergelijking Generiek SaaS LMS vs Aangepaste Moodle:** - Diepte aanpassing: Beperkt vs Volledig (plugins, UX, workflows, data) - Gegevens-eigendom: Leveranciersgecontroleerd vs Volledig van jou - Prijs per gebruiker: Schaalbaar met aantal vs Eenmalige ontwikkeling - Integratieflexibiliteit: Alleen voorgeprogrammeerde connectoren vs Elk systeem met API - Afhankelijkheid leverancier: Hoog vs Laag We werken al sinds versie 1.8 met Moodle en hebben meer dan 300 plugins ontwikkeld. ## 5. Het ontwikkelingsproces van maatwerk LMS Veel organisaties aarzelen om te investeren in maatwerkontwikkeling omdat ze verwachten dat het traag, duur of technisch riskant zal zijn. Met de juiste partner hoeft dat niet het geval te zijn. 1. **Ontdekking en afbakening** — Leerdoelen, gebruikersgroepen, bestaande systemen en technische beperkingen in kaart brengen 2. **Architectuur en ontwerp** — Oplossing voorstellen die zo dicht mogelijk bij de Moodle-kern blijft 3. **Plugin- of functieontwikkeling** — Ontwikkelen volgens officiële codeerstandaarden van Moodle 4. **Integratie en testen** — LMS koppelen aan bestaande systemen en grondig testen 5. **Implementatie en training** — Technische implementatie en beheerderstraining 6. **Continue ondersteuning en optimalisatie** — Langdurige ondersteuning, upgrades en prestatieoptimalisatie Korte communicatielijnen zijn een bewust onderdeel van ons model. Je werkt rechtstreeks met senior ontwikkelaars. ## 6. Tekenen dat je organisatie maatwerk LMS nodig heeft - Je LMS is niet geïntegreerd met je HR- of SSO-systeem - De acceptatie door cursisten is laag - Je betaalt voor functies die je nooit gebruikt - Compliance-tracking gebeurt nog steeds in spreadsheets - Je organisatie is aanzienlijk gegroeid en SaaS per gebruiker wordt te duur - Je hebt specifieke, op rollen gebaseerde leertrajecten ## 7. Veelgestelde vragen ### Hoe lang duurt de ontwikkeling van maatwerk LMS? Één aangepaste plugin duurt twee tot zes weken. Een complete omgeving met thema, integraties en meerdere plugins duurt doorgaans drie tot vijf maanden. ### Moet ik de Moodle-hosting zelf beheren? Nee. We kunnen adviseren over de hostingconfiguratie of een partner voor beheerde Moodle-hosting aanbevelen. ### Zullen aangepaste plugins werken na een Moodle-upgrade? We volgen de officiële codeerstandaarden van Moodle, waardoor aanpassingen compatibel blijven met toekomstige versies. We ondersteunen klanten ook bij grote versie-upgrades. ### Wat kost de ontwikkeling van maatwerk LMS? Een gerichte plugin begint bij een paar duizend euro; een complete omgeving is een grotere investering met rendement over meerdere jaren. ### Is Moodle geschikt voor bedrijfstrainingen? Absoluut. Moodle wordt gebruikt voor bedrijfstrainingen in diverse sectoren, waaronder luchtvaart (KLM), maakindustrie, gezondheidszorg en financiële dienstverlening. ## Conclusie De ontwikkeling van een LMS op maat is geen luxe voor grote ondernemingen alleen. Het is de praktische keuze voor elke organisatie waarvan het trainingsprogramma de mogelijkheden van een standaardplatform ontgroeid is. De voordelen – slagingspercentages, bespaarde administratieve tijd, compliance-zekerheid en meetbare prestatieverbetering – wegen steevast op tegen de investering. Ldesign Media helpt organisaties al meer dan 15 jaar om het maximale uit Moodle te halen. Ben je klaar om een leerplatform te bouwen dat echt bij je organisatie past? [Laten we beginnen met een gesprek](https://ldesignmedia.nl/nl/contact). --- ## Custom LMS Software Development for Modern Organizations (EN) Source: https://ldesignmedia.nl/en/blog/custom-lms-software-development Published: 2026-05-05 Digital training is no longer an optional extra but a strategic necessity for businesses looking to grow. Organizations need efficient learning solutions that enable them to train employees, measure performance, and centralize knowledge management. [Custom LMS software development](/en/services/lms-development) gives companies full control over their digital learning environment. Instead of working with off-the-shelf solutions that offer limited flexibility, the platform is fully tailored to internal processes, goals, and growth plans. ## Why Standard LMS Solutions Often Fall Short Many companies start with a standard [Learning Management System](/en/services/lms-development) (LMS). While these systems can be deployed quickly, they often have limitations such as: - Fixed functionality - Limited integration options - Less flexibility in reporting - Insufficient scalability For organizations with specific training structures or multiple departments, this can become problematic. Custom development offers a clear solution here. ## What Does Custom LMS Development Actually Involve? With custom development, the LMS is designed from the ground up around the company's needs. This means features, dashboards, and workflows are built according to specific requirements. **Key characteristics of custom development:** - Personalized user roles - Customized learning paths - Integration with HR, CRM, or ERP systems - Advanced data analytics - Alignment with client preferences and workflows Companies seeking a strategic partner for technical implementation can collaborate with Ldesign Media to develop a future-proof solution. ## Key Phases in the Development Process Successful custom LMS software development follows a structured approach. ### 1. Strategic Analysis During this phase, business objectives, user needs, and technical requirements are established. This forms the foundation for the entire project. ### 2. Functional and Technical Design Here, the platform structure is developed. User experience is central, ensuring employees can use the system easily. ### 3. Development and Integration Developers build the system and create connections with existing software. Integration is essential for automatic data synchronization. ### 4. Testing and Optimization Before launch, the LMS is extensively tested for performance, security, and usability. An experienced development partner like Ldesign Media guides organizations through each phase of this process. ## Key Features in Custom LMS When developing custom LMS software, companies can choose specific features that align with their strategy: - Adaptive learning paths - AI-driven recommendations - Automatic certification - Real-time progress reporting - Multilingual support - Gamification for higher engagement These features not only increase efficiency but also improve the learning experience for employees. ## Benefits for Growth and Productivity A custom LMS delivers measurable business benefits: - Faster onboarding of new employees - Lower training costs in the long term - Improved compliance - Better knowledge retention - Higher employee satisfaction By automating internal learning processes, companies save time and resources. Organizations looking to approach this professionally can [contact Ldesign Media](/en/contact) for support in designing and implementing a scalable learning solution. ## Costs and ROI of Custom LMS The investment in custom development depends on several factors: - Complexity of features - Number of users - Integrations with external systems While the initial investment may be higher than with standard software, custom development offers more flexibility and higher ROI in the long term. Companies retain full control over their data and platform development. ## Future-Proof Learning Strategy The future of digital learning environments lies in personalization and automation. Technologies like artificial intelligence, mobile optimization, and data analytics are becoming increasingly important. With a strategic approach and technical guidance from Ldesign Media, organizations can develop an innovative learning environment that grows with their business structure and market dynamics. ## Conclusion: Why Custom Development Is a Smart Choice Custom LMS software development is a sustainable investment for organizations that want full control over their training processes. By choosing custom development, companies gain flexibility, scalability, and better integration capabilities. A well-developed LMS becomes not just a training platform but a strategic tool for growth, efficiency, and knowledge development. ## Frequently Asked Questions About Custom LMS Software Development ### 1. What does custom LMS software development mean? It's the process of designing and building a learning management system entirely according to the specific needs of an organization. ### 2. Why do companies choose custom development over a standard LMS? Because custom development offers more flexibility, better integrations, and scalability. ### 3. How long does a custom LMS project take? Depending on complexity, this can take several months, including analysis, development, and testing. ### 4. What are the main long-term benefits? More control, better performance, higher ROI, and a platform that grows with the organization. --- ## Custom LMS Software Development for Modern Organizations (NL) Source: https://ldesignmedia.nl/nl/blog/ontwikkeling-lms-software-op-maat Published: 2026-05-05 Digitale training is niet langer een extra optie, maar een strategische noodzaak voor bedrijven die willen groeien. Organisaties hebben behoefte aan efficiënte leeroplossingen waarmee ze medewerkers kunnen opleiden, prestaties kunnen meten en kennis centraal kunnen beheren. De [ontwikkeling van LMS-software op maat](/nl/diensten/lms-ontwikkeling) biedt bedrijven volledige controle over hun digitale leeromgeving. In plaats van te werken met standaardoplossingen die beperkte flexibiliteit bieden, wordt het platform volledig afgestemd op interne processen, doelen en groeiplannen. ## Waarom standaard LMS-oplossingen vaak tekortschieten Veel bedrijven starten met een standaard [Learning Management System](/nl/diensten/lms-ontwikkeling) (LMS). Hoewel deze systemen snel inzetbaar zijn, hebben ze vaak beperkingen zoals: - Vaste functionaliteiten - Beperkte integratiemogelijkheden - Minder flexibiliteit in rapportages - Onvoldoende schaalbaarheid Voor organisaties met specifieke trainingsstructuren of meerdere afdelingen kan dit problematisch worden. Hier biedt maatwerk een duidelijke oplossing. ## Wat houdt maatwerk LMS-ontwikkeling precies in? Bij maatwerkontwikkeling wordt het LMS vanaf de basis ontworpen rond de behoeften van het bedrijf. Dit betekent dat functies, dashboards en workflows worden gebouwd volgens specifieke eisen. **Belangrijke kenmerken van maatwerk:** - Gepersonaliseerde gebruikersrollen - Aangepaste leerpaden - Integratie met HR-, CRM- of ERP-systemen - Geavanceerde data-analyse - Aansluiten bij de wensen en werkwijzen van de klant Bedrijven die een strategische partner zoeken voor technische realisatie kunnen samenwerken met Ldesign Media om een toekomstgerichte oplossing te ontwikkelen. ## Belangrijke fases binnen het ontwikkelproces Een succesvolle ontwikkeling van LMS-software op maat verloopt via een gestructureerde aanpak. ### 1. Strategische analyse Tijdens deze fase worden bedrijfsdoelen, gebruikersbehoeften en technische vereisten vastgesteld. Dit vormt de basis voor het gehele project. ### 2. Functioneel en technisch ontwerp Hier wordt de structuur van het platform uitgewerkt. De gebruikerservaring staat centraal, zodat medewerkers het systeem eenvoudig kunnen gebruiken. ### 3. Ontwikkeling en integratie Programmeurs bouwen het systeem en zorgen voor koppelingen met bestaande software. Integratie is essentieel om data automatisch te synchroniseren. ### 4. Testen en optimaliseren Voor de lancering wordt het LMS uitgebreid getest op prestaties, veiligheid en gebruiksvriendelijkheid. Een ervaren ontwikkelpartner zoals Ldesign Media begeleidt organisaties door elke fase van dit traject. ## Belangrijke functionaliteiten binnen maatwerk LMS Bij de ontwikkeling van LMS-software op maat kunnen bedrijven kiezen voor specifieke functies die aansluiten bij hun strategie: - Adaptieve leerpaden - AI-gestuurde aanbevelingen - Automatische certificering - Real-time voortgangsrapportages - Meertalige ondersteuning - Gamification voor hogere betrokkenheid Deze functies verhogen niet alleen de efficiëntie, maar verbeteren ook de leerervaring van medewerkers. ## Voordelen voor groei en productiviteit Een maatwerk LMS levert meetbare bedrijfsvoordelen op: - Snellere onboarding van nieuwe medewerkers - Lagere trainingskosten op lange termijn - Verbeterde compliance - Betere kennisborging - Hogere medewerkerstevredenheid Door interne leerprocessen te automatiseren, besparen bedrijven tijd en middelen. Organisaties die dit professioneel willen aanpakken, kunnen [contact opnemen met Ldesign Media](/nl/contact) voor ondersteuning bij het ontwerpen en implementeren van een schaalbare leeroplossing. ## Kosten en rendement van maatwerk LMS De investering in maatwerk hangt af van verschillende factoren: - Complexiteit van functionaliteiten - Aantal gebruikers - Integraties met externe systemen Hoewel de initiële investering hoger kan zijn dan bij standaardsoftware, biedt maatwerk meer flexibiliteit en een hogere ROI op lange termijn. Bedrijven behouden volledige controle over hun data en platformontwikkeling. ## Toekomstgerichte leerstrategie De toekomst van digitale leeromgevingen ligt in personalisatie en automatisering. Technologieën zoals kunstmatige intelligentie, mobiele optimalisatie en data-analyse worden steeds belangrijker. Met een strategische aanpak en technische begeleiding van Ldesign Media kunnen organisaties een innovatieve leeromgeving ontwikkelen die meegroeit met hun bedrijfsstructuur en marktdynamiek. ## Conclusie: waarom maatwerk een slimme keuze is De ontwikkeling van LMS-software op maat is een duurzame investering voor organisaties die volledige controle willen over hun trainingsprocessen. Door te kiezen voor maatwerk krijgen bedrijven flexibiliteit, schaalbaarheid en betere integratiemogelijkheden. Een goed ontwikkeld LMS wordt niet alleen een trainingsplatform, maar een strategisch hulpmiddel voor groei, efficiëntie en kennisontwikkeling. ## Veelgestelde vragen over de ontwikkeling van maatwerk LMS-software ### 1. Wat betekent ontwikkeling van LMS-software op maat? Het is het proces waarbij een learning managementsysteem volledig wordt ontworpen en gebouwd volgens de specifieke behoeften van een organisatie. ### 2. Waarom kiezen bedrijven voor maatwerk in plaats van een standaard LMS? Omdat maatwerk meer flexibiliteit, betere integraties en schaalbaarheid biedt. ### 3. Hoe lang duurt een maatwerk LMS-project? Afhankelijk van de complexiteit kan dit enkele maanden duren, inclusief analyse, ontwikkeling en testen. ### 4. Wat zijn de belangrijkste voordelen op lange termijn? Meer controle, betere prestaties, hogere ROI en een platform dat meegroeit met de organisatie. --- ## How to Create an Advanced Moodle Course for Better Learning Outcomes (EN) Source: https://ldesignmedia.nl/en/blog/advanced-moodle-course-design Published: 2026-05-05 A well-designed Moodle course is the difference between students who drop out and students who excel. In this comprehensive guide, we show you how to build an advanced Moodle course step by step that demonstrably contributes to better learning outcomes. Whether you're an education professional, an L&D specialist, or an organization looking to optimize the learning environment — this article provides concrete tools and strategies. Need professional support with the technical side? The [Moodle developers at Ldesign Media](https://ldesignmedia.nl/en/services/moodle-developer) have been helping organizations for more than 15 years with custom development and complex integrations. ## What Makes an Advanced Moodle Course Different? Most organizations use Moodle as a digital repository: upload files, maybe add a quiz, and done. That's a missed opportunity. The Moodle platform offers a rich set of features that enable adaptive learning, automatic progress tracking, gamification, and interactive content — provided you know the right settings and think through the architecture. An advanced course distinguishes itself on four points: - **Goal-oriented:** Every activity is deliberately linked to a measurable learning outcome - **Interactive:** Students are actively engaged through H5P, quizzes with immediate feedback, and collaborative assignments - **Adaptive:** Course content adapts based on student progress through conditional activities - **Measurable:** Teachers and administrators have real-time insight into engagement and learning outcomes ## Step 1: Formulate Clear Learning Goals and Outcomes The most common mistake in course design is starting with content instead of goals. First determine: what should a student be able to do after completing the course? Use the SMART model: - **Specific:** 'The student can write an SQL query' is better than 'the student understands databases' - **Measurable:** Link each learning goal to an activity or test in Moodle that demonstrates success - **Achievable:** Goals must be realistic for the target audience and timeline - **Result-oriented:** Formulate in terms of behavior change, not activities ('after this module, the student can…') - **Time-bound:** Determine when a learning goal should be achieved, preferably per section or module ### Linking Learning Goals to Moodle's Completion Criteria Once your learning goals are formulated, translate them into Moodle's built-in completion criteria. Go to Course Settings → Completion Tracking and activate options per activity. You can set an activity as 'completed' when: - The student has viewed the activity (view) - The student has achieved a minimum score (for quizzes) - The teacher has manually marked completion - A combination of the above criteria applies Ldesign Media offers [technical consulting](https://ldesignmedia.nl/en/services/technical-advice) for setting up complex completion structures, such as automatically assigning certificates or activating follow-up modules based on achieved scores. ## Step 2: Set Up Course Structure for Maximum Clarity A course's structure largely determines how students experience the learning journey. A messy structure — many files without logic — increases dropout rates. A clear, modular setup keeps students focused. ### Choosing the Right Course Format Moodle offers two main formats by default: - **Topics format:** Ideal for competency-based courses where sequence is less important - **Weekly format:** Suitable for synchronized classroom courses where students go through material simultaneously For most corporate training and e-learning programs, the topics format is preferred: more flexible, less time-bound, and easier to reuse. ### Organizing Resources and Activities Logically Use a consistent sequence per section: 1. Introduction (text or short video with section learning goal) 2. Core content (learning materials, videos, presentations) 3. Practice (interactive activity or H5P element) 4. Assessment moment (quiz or assignment) 5. Reflection or deepening (forum, peer feedback, or additional resources) ## Step 3: Design Engaging Activities and Assessment The choice and design of activities determines how actively students engage with the material. Moodle offers dozens of activity types. ### Advanced Quiz Settings for Better Assessment The Moodle quiz is much more powerful than most users realize: - **Adaptive mode:** After a wrong answer, students get the opportunity to try again immediately, with a point penalty - **Random question order:** Reduces the chance of cheating and forces genuine knowledge application - **Time limit per attempt:** Creates realistic test conditions and increases engagement - **Immediate feedback with explanation:** Show not just 'wrong' after each question but also why — proven more effective for retention - **Question banks per category:** Create multiple quiz versions from one question bank for differentiation ### Using H5P for Interactive Content H5P (HTML5 Package) is seamlessly integrated in Moodle 4.x: - **Interactive Video:** Add interim questions, hotspots, and explanation pop-ups to existing videos - **Course Presentation:** Slideshows with embedded activities, ideal as replacement for static PowerPoint exports - **Branching Scenario:** Students make choices and see consequences — powerful for soft skills training and compliance - **Drag the Words / Fill in the Blanks:** Quick, gamified exercises that stimulate knowledge processing ## Step 4: Apply Gamification and Badges Gamification — applying game elements in a learning environment — demonstrably increases motivation and completion rates. Moodle supports gamification through badges, progress bars, and conditional content release. ### Setting Up Badges in Moodle Go to Course Settings → Badges → Add Badge. Link badges to completion criteria such as: - Successfully completing a quiz with at least 80% - Completing an entire section - Active participation in a forum discussion (minimum X contributions) - Obtaining a course certificate ### TabTiles: Visual Progress Display For an even richer gamification experience, Ldesign Media has developed the TabTiles plugin — a visual tiles and tabs interface that makes Moodle intuitive and attractive with animations, progress feedback, and clear navigation. ## Step 5: Set Up Conditional Activities and Adaptive Learning Conditional activities are one of the most powerful — and most underused — features of Moodle. They make it possible to release course content only when a student meets certain conditions. ### Types of Conditions in Moodle - **Activity completion:** Activity B is only visible after activity A is completed - **Date:** Content becomes visible on a specific date - **Grade:** Students who score below the threshold automatically receive additional practice material - **Group membership:** Differentiate content based on the group a student is assigned to - **Profile:** Release based on profile data such as department or job title ### Practical Example: Adaptive Learning Path Imagine a compliance training with three levels: 1. Student takes a prior knowledge test 2. Does the student score ≥ 70%? Then the basic module is skipped 3. Does the student score < 50%? Then a remediation module automatically appears 4. After completion, the student receives a badge and certificate ## Step 6: Monitor Progress and Engagement Data is the key to continuous improvement of your course. ### Built-in Moodle Reports - **Activity reports:** See which activities are visited most or least - **Course progress report:** Overview per student of which completion criteria have been achieved - **Logs:** Detailed recording of every interaction — useful for accreditation and compliance - **Statistics:** Insight into login times, peak days, and usage duration per activity ### Advanced Reporting with Custom Plugins Standard Moodle reports are sometimes limited for organizations with complex needs. Ldesign Media develops custom reporting modules that connect to internal BI systems, HR platforms, and external dashboards. > **Best practice:** Evaluate course data at least once per quarter. Look at completion rates per section, average quiz scores per attempt, and drop-off points. ## Step 7: Optimize Accessibility and Mobile Experience A professional Moodle course is accessible to everyone — including students with disabilities and users on mobile devices. Accessibility is a legal requirement in many sectors (WCAG 2.1 AA). ### Applying WCAG Guidelines in Moodle - **Alt texts:** Add descriptive alternative text to every image - **Contrast ratio:** Use sufficient contrast (minimum 4.5:1) for text on background - **Accessible videos:** Add subtitles and transcripts to all video content - **Keyboard navigation:** Ensure all activities can be operated without a mouse - **Heading structure:** Use H1, H2, H3 correctly for screen readers ### Optimizing Moodle for Mobile Moodle 4.x is responsive by design, but a good mobile experience requires extra attention: - Test every activity on smartphone before publication - Limit the use of large PDF files — prefer web page-based content - H5P works excellently on mobile - Use the Moodle app for offline access to course materials ## Common Mistakes in Moodle Course Design - **Not linking learning goals to activities:** Every activity must have a reason - **Too-long text blocks without interaction:** Alternate with H5P, video, or quizzes every 300–500 words - **No test moment before publication:** View the course as a student before going live - **Forgetting to set completion criteria:** Without this, progress tracking doesn't work - **Not performing mobile tests:** More than 40% access Moodle via smartphone - **Installing plugins without technical review:** Not all plugins are well maintained ## Frequently Asked Questions ### How long does it take to build an advanced Moodle course? A simple course of 5 modules can be built in 2–4 weeks. A complex course with conditional activities, custom themes, and external integrations can take 3–6 months. ### Can I import SCORM content into Moodle? Yes. Moodle natively supports SCORM 1.2 and SCORM 2004. Note: SCORM content is static and offers less progress integration than native Moodle activities. ### What's the difference between Topics and Weekly format? The Topics format groups content by theme and is time-independent. The Weekly format displays content per calendar week. ### How do I set up conditional access based on a quiz score? Go to activity settings → Access restrictions → Add restriction → Grade. Choose the quiz activity and set a minimum or maximum score. ### Does Moodle work well on mobile devices? Yes, Moodle 4.x is fully responsive. The official Moodle app offers offline access and push notifications. ### How can I automatically issue certificates? Use the built-in certificate activity or the 'Custom Certificate' plugin. Link the certificate activity as a conditional activity to completion of all required modules. ## Conclusion: From Basic to Advanced Moodle Course Design An advanced Moodle course isn't a stroke of luck — it's the result of thoughtful design, the right technical settings, and continuous optimization based on data. By following the seven steps in this article, you'll build a learning environment that motivates students, makes progress measurable, and actually contributes to the learning outcomes you're pursuing. Looking for an experienced Moodle developer to take your learning environment to the next level? [Ldesign Media](https://ldesignmedia.nl/en) has more than 15 years of experience in Moodle custom development and has built more than 300 plugins. [Contact us](https://ldesignmedia.nl/en/contact) — we're happy to think along about the possibilities for your organization. --- ## How to Create an Advanced Moodle Course for Better Learning Outcomes (NL) Source: https://ldesignmedia.nl/nl/blog/geavanceerde-moodle-cursus-ontwerp Published: 2026-05-05 Een goed opgezette Moodle-cursus is het verschil tussen studenten die afhaken en studenten die excelleren. In deze uitgebreide handleiding laten we zien hoe je, stap voor stap, een geavanceerde Moodle-cursus bouwt die aantoonbaar bijdraagt aan betere leerresultaten. Of je nu een onderwijsprofessional bent, een L&D-specialist, of een organisatie die de leeromgeving wil optimaliseren — dit artikel biedt je concrete tools en strategieën. Wil je professionele ondersteuning bij de technische kant? De [Moodle-developers van Ldesign Media](https://ldesignmedia.nl/nl/diensten/moodle-ontwikkelaar) helpen organisaties al meer dan 15 jaar met maatwerkontwikkeling en complexe integraties. ## Wat maakt een geavanceerde Moodle-cursus anders? De meeste organisaties gebruiken Moodle als een digitale opslagplaats: bestanden uploaden, misschien een quiz toevoegen, en klaar. Dat is een gemiste kans. Het Moodle-platform biedt een rijke set aan functies waarmee je adaptief leren, automatische voortgangsregistratie, gamification en interactieve content kunt inzetten — mits je de juiste instellingen kent en de architectuur doordenkt. Een geavanceerde cursus onderscheidt zich op vier punten: - **Doelgerichtheid:** Elke activiteit is bewust gekoppeld aan een meetbare leeruitkomst - **Interactiviteit:** Studenten zijn actief betrokken via H5P, quizzen met directe feedback, en samenwerkingsopdrachten - **Adaptiviteit:** Cursusinhoud past zich aan op basis van de voortgang van de student via conditionele activiteiten - **Meetbaarheid:** Docenten en beheerders hebben realtime inzicht in betrokkenheid en leerresultaten ## Stap 1: Heldere leerdoelen en leeruitkomsten formuleren De meest gemaakte fout bij cursusontwerp is beginnen met de inhoud in plaats van met de doelen. Bepaal eerst: wat moet een student kunnen na afronding van de cursus? Gebruik hiervoor het SMART-model: - **Specifiek:** 'De student kan een SQL-query schrijven' is beter dan 'de student begrijpt databases' - **Meetbaar:** Koppel elk leerdoel aan een activiteit of toets in Moodle die het succes aantoont - **Acceptabel:** De doelen moeten realistisch zijn voor de doelgroep en het tijdpad - **Resultaatgericht:** Formuleer in gedragsverandering, niet in activiteiten ('na deze module kan de student…') - **Tijdgebonden:** Bepaal wanneer een leerdoel bereikt moet zijn, bij voorkeur per sectie of module ### Leerdoelen koppelen aan Moodle's voltooiingscriteria Zodra je leerdoelen geformuleerd zijn, vertaal je ze naar Moodle's ingebouwde voltooiingscriteria. Ga naar Cursusinstellingen → Voltooiing bijhouden en activeer de opties per activiteit. Je kunt instellen dat een activiteit als 'voltooid' geldt wanneer: - De student de activiteit heeft bekeken (weergave) - De student een minimale score heeft behaald (bij quizzen) - De docent de voltooiing handmatig heeft gemarkeerd - Een combinatie van bovenstaande criteria van toepassing is Ldesign Media biedt [technisch advies](https://ldesignmedia.nl/nl/diensten/technisch-advies) bij het opzetten van complexe voltooiingsstructuren, zoals het automatisch toewijzen van certificaten of het activeren van vervolgmodules op basis van behaalde scores. ## Stap 2: Cursusstructuur opzetten voor maximale helderheid De structuur van een cursus bepaalt grotendeels hoe studenten de leerervaring ervaren. Een rommelige structuur — veel bestanden zonder logica — verhoogt de uitvalkans. Een heldere, modulaire opbouw houdt studenten gefocust. ### Het juiste cursusformaat kiezen Moodle biedt standaard twee hoofdformaten: - **Onderwerpformaat:** Ideaal voor competentiegerichte cursussen waarbij volgorde minder belangrijk is - **Wekelijks formaat:** Geschikt voor gesynchroniseerde klassikale cursussen waarbij studenten tegelijkertijd door de stof gaan Voor de meeste zakelijke trainingen en e-learning trajecten verdient het onderwerpformaat de voorkeur: flexibeler, minder tijdgebonden, en makkelijker te hergebruiken. ### Bronnen en activiteiten logisch organiseren Gebruik per sectie een consistente volgorde: 1. Inleiding (tekst of korte video met leerdoel van de sectie) 2. Kerninhoud (lesmateriaal, video's, presentaties) 3. Oefening (interactieve activiteit of H5P-element) 4. Toetsmoment (quiz of opdracht) 5. Reflectie of verdieping (forum, peerfeedback of aanvullende bronnen) ## Stap 3: Boeiende activiteiten en toetsing ontwerpen De keuze en inrichting van activiteiten bepaalt hoe actief studenten met de stof omgaan. Moodle biedt tientallen activiteitstypes. ### Geavanceerde quiz-instellingen voor betere toetsing De Moodle-quiz is veel krachtiger dan de meeste gebruikers beseffen: - **Adaptieve modus:** Studenten krijgen na een fout antwoord de mogelijkheid om direct opnieuw te proberen, met puntenstraf - **Willekeurige vraagvolgorde:** Vermindert de kans op spieken en forceert echte kennistoepassing - **Tijdslimiet per poging:** Creëert realistische testomstandigheden en verhoogt betrokkenheid - **Directe feedback met uitleg:** Toon na elke vraag niet alleen 'fout' maar ook waarom — bewezen effectiever voor kennisretentie - **Vragenbanken per categorie:** Maak meerdere quizversies uit één vragenbank voor differentiatie ### H5P gebruiken voor interactieve content H5P (HTML5 Package) is naadloos geïntegreerd in Moodle 4.x: - **Interactive Video:** Voeg tussentijdse vragen, hotspots en uitleg pop-ups in aan bestaande video's - **Course Presentation:** Slideshows met embedded activiteiten, ideaal als vervanging van statische PowerPoint-exports - **Branching Scenario:** Studenten maken keuzes en zien de consequenties — krachtig voor soft skills training en compliance - **Drag the Words / Fill in the Blanks:** Snelle, gamified oefeningen die kennisverwerking stimuleren ## Stap 4: Gamification en badges toepassen Gamification — het toepassen van spelelementen in een leeromgeving — verhoogt aantoonbaar de motivatie en voltooiingspercentages. Moodle ondersteunt gamification via badges, voortgangsbalken en conditionele vrijschakeling van content. ### Badges instellen in Moodle Ga naar Cursusinstellingen → Badges → Badge toevoegen. Koppel badges aan voltooiingscriteria zoals: - Het succesvol afronden van een quiz met minimaal 80% - Het voltooien van een volledige sectie - Actieve deelname aan een forumgesprek (minimaal X bijdragen) - Het behalen van een cursuscertificaat ### TabTiles: visuele voortgangsweergave Voor een nog rijkere gamification-ervaring heeft Ldesign Media de TabTiles-plugin ontwikkeld — een visuele tegels- en tabbladen interface die Moodle intuïtief en aantrekkelijk maakt met animaties, voortgangsfeedback en overzichtelijke navigatie. ## Stap 5: Conditionele activiteiten en adaptief leren instellen Conditionele activiteiten zijn een van de krachtigste — en meest ondergebruikte — functies van Moodle. Ze maken het mogelijk om cursusinhoud pas vrij te schakelen wanneer een student aan bepaalde voorwaarden voldoet. ### Typen condities in Moodle - **Activiteitsvoltooiing:** Activiteit B is pas zichtbaar nadat activiteit A is voltooid - **Datum:** Inhoud wordt op een specifieke datum zichtbaar - **Score:** Studenten die onder de drempelwaarde scoren, krijgen automatisch extra oefenmateriaal - **Groepslidmaatschap:** Differentieer inhoud op basis van de groep waarin een student is ingedeeld - **Profiel:** Vrijschakeling op basis van profielgegevens zoals afdeling of functietitel ### Praktijkvoorbeeld: adaptief leerpad Stel je een compliance-training voor met drie niveaus: 1. Student doet een voorkennistoets 2. Scoort de student ≥ 70%? Dan wordt de basismodule overgeslagen 3. Scoort de student < 50%? Dan verschijnt automatisch een remediëringsmodule 4. Na voltooiing ontvangt de student een badge en certificaat ## Stap 6: Voortgang en betrokkenheid monitoren Data is de sleutel tot continue verbetering van je cursus. ### Ingebouwde Moodle-rapporten - **Activiteitsrapporten:** Zie welke activiteiten het meest of minst bezocht worden - **Cursusvoortgangsrapport:** Overzicht per student van welke voltooiingscriteria zijn behaald - **Logboeken:** Gedetailleerde registratie van elke interactie — nuttig voor accreditatie en compliance - **Statistieken:** Inzicht in inlogtijden, piekdagen en gebruiksduur per activiteit ### Geavanceerde rapportage met maatwerk plugins Standaard Moodle-rapportages zijn soms beperkt voor organisaties met complexe behoeften. Ldesign Media ontwikkelt maatwerk rapportagemodules die aansluiten op interne BI-systemen, HR-platforms en externe dashboards. > **Best practice:** Evalueer cursusdata minimaal één keer per kwartaal. Kijk naar voltooiingspercentages per sectie, gemiddelde quizscores per poging, en drop-off punten. ## Stap 7: Toegankelijkheid en mobiele ervaring optimaliseren Een professionele Moodle-cursus is voor iedereen toegankelijk — inclusief studenten met een beperking en gebruikers op mobiele apparaten. Toegankelijkheid is in veel sectoren een wettelijke verplichting (WCAG 2.1 AA). ### WCAG-richtlijnen toepassen in Moodle - **Alt-teksten:** Voeg beschrijvende alternatieve tekst toe aan elke afbeelding - **Contrastverhouding:** Gebruik voldoende contrast (minimaal 4.5:1) voor tekst op achtergrond - **Toegankelijke video's:** Voeg ondertiteling en transcripties toe aan alle videocontent - **Toetsenbordnavigatie:** Zorg dat alle activiteiten ook zonder muis te bedienen zijn - **Koppenstructuur:** Gebruik H1, H2, H3 correct voor schermlezers ### Moodle mobiel optimaliseren Moodle 4.x is responsive by design, maar een goede mobiele ervaring vereist extra aandacht: - Test elke activiteit op smartphone vóór publicatie - Beperk het gebruik van grote PDF-bestanden — gebruik liever webpagina-gebaseerde inhoud - H5P werkt uitstekend op mobiel - Gebruik de Moodle-app voor offline toegang tot cursusmateriaal ## Veelgemaakte fouten bij Moodle-cursusontwerp - **Geen leerdoelen koppelen aan activiteiten:** Elke activiteit moet een reden hebben - **Te lange tekstblokken zonder interactie:** Wissel af met H5P, video of quizzen na elke 300–500 woorden - **Geen testmoment voor publicatie:** Bekijk de cursus als student vóór live gang - **Vergeten om voltooiingscriteria in te stellen:** Zonder dit werkt voortgangsbewaking niet - **Geen mobieltests uitvoeren:** Meer dan 40% benadert Moodle via smartphone - **Plugins installeren zonder technische toetsing:** Niet alle plugins zijn goed onderhouden ## Veelgestelde vragen ### Hoe lang duurt het om een geavanceerde Moodle-cursus te bouwen? Een eenvoudige cursus van 5 modules is in 2–4 weken te bouwen. Een complexe cursus met conditionele activiteiten, maatwerk thema's en externe integraties kan 3–6 maanden vergen. ### Kan ik SCORM-content importeren in Moodle? Ja. Moodle ondersteunt SCORM 1.2 en SCORM 2004 natively. Let op: SCORM-content is statisch en biedt minder voortgangsintegratie dan native Moodle-activiteiten. ### Wat is het verschil tussen Onderwerpen- en Wekelijks formaat? Het Onderwerpformaat groepeert inhoud per thema en is tijdsonafhankelijk. Het Wekelijks formaat toont inhoud per kalenderweek. ### Hoe stel ik conditionele toegang in op basis van quiz score? Ga naar activiteitsinstellingen → Toegangsbeperkingen → Beperking toevoegen → Beoordeling. Kies de quizactiviteit en stel een minimum- of maximumscore in. ### Werkt Moodle goed op mobiele apparaten? Ja, Moodle 4.x is volledig responsive. De officiële Moodle-app biedt offline toegang en pushmeldingen. ### Hoe kan ik certificaten automatisch uitreiken? Gebruik de ingebouwde certificaatactiviteit of de 'Custom Certificate' plugin. Koppel de certificaatactiviteit als conditionele activiteit aan de voltooiing van alle verplichte modules. ## Conclusie: Van basis naar geavanceerd Moodle-cursusontwerp Een geavanceerde Moodle-cursus is geen toevalstreffer — het is het resultaat van doordacht ontwerp, de juiste technische instellingen, en continue optimalisatie op basis van data. Door de zeven stappen in dit artikel te volgen, bouw je een leeromgeving die studenten motiveert, voortgang meetbaar maakt, en daadwerkelijk bijdraagt aan de leeruitkomsten die jij nastreeft. Ben je op zoek naar een ervaren Moodle-developer die jouw leeromgeving naar het volgende niveau tilt? [Ldesign Media](https://ldesignmedia.nl/nl) heeft meer dan 15 jaar ervaring in Moodle-maatwerkontwikkeling en heeft meer dan 300 plugins gebouwd. [Neem vrijblijvend contact op](https://ldesignmedia.nl/nl/contact) — wij denken graag mee over de mogelijkheden voor jouw organisatie. --- ## MoodleMoot DACH 2025: Building a Plugin in 48 Hours at the DevCamp (EN) Source: https://ldesignmedia.nl/en/blog/moodlemoot-dach-2025-devcamp-who-is-who Published: 2025-09-30 Every year the Moodle community gathers across the German-speaking region for MoodleMoot DACH. It is a conference built around the people who actually run, build, and teach with Moodle. In 2025 it was hosted in Lübeck, and three of us made the trip. We came for the talks and the community, but the real highlight turned out to be the DevCamp: two intense days where we built a brand-new Moodle plugin from nothing. (Our colleague Nihaal Shaikh was at the same event too, building the Teacher Tours block in a different team that took 2nd place in the DevCamp.) This is the story of that plugin, the people we built it with, and why we are already booked to do it all again at MoodleMoot DACH 2026 in Zürich at the end of June. ## What MoodleMoot DACH Actually Is MoodleMoot DACH is the annual gathering for the German, Austrian, and Swiss (DACH) Moodle community. It mixes the formal conference format (keynotes, case studies, roadmap sessions) with a much more hands-on, community-driven side. The 2025 edition in Lübeck was a good example of that balance. Alongside the main programme there were: - 22 DevCamp teams building real things; - 35 BarCamp sessions proposed and run by attendees themselves. That mix of structured talks and open, self-organized sessions is exactly why these events matter. You leave with new ideas, new contacts, and usually a few new lines of code. ## The DevCamp: From Idea to Plugin in Two Days The DevCamp is the part we keep coming back for. The format is simple: teams form around a real problem, and over roughly two days you go from a whiteboard sketch to working Moodle code. Our team (registered as Team 30, working out of the Salzspeicher room) came together around a concrete use case brought by Meret Racz of m-modula, for the Liechtensteinische Alters- und Krankenhilfe (LAK). The challenge she pitched was deceptively simple to describe and genuinely tricky to handle in Moodle: - an organization with over 20 different jobs; - around 12 different roles in Moodle; - and employees who often hold more than one role at the same time. When one person is a nurse, a team lead, and a trainer all at once, they end up with multiple roles in the same Moodle context. That is where it gets painful. So that became the project: **Who is Who**, a permission dashboard for Moodle. ## Meet the Team Plugins like this are never a solo effort, and the DevCamp format makes that obvious. Our team for the weekend was: - **Meret Racz**, founder of m-modula, who pitched the use case and drove the requirements; - **Luuk Verhoeven** (Ldesign Media), plugin architecture and Moodle internals; - **Vincent Cornelis** (Ldesign Media), backend and data model; - **Wafaa Mansour**, development and testing. Four people, two days, one shared goal. There is something clarifying about that constraint: no long backlog, no committee, just a real problem and a tight deadline. ## The Real Problem: Overlapping Roles in One Context The use case sounds like a reporting problem, but underneath it is a permissions problem, and a nasty one. In Moodle, when a user holds **more than one role in the same context**, their capabilities overlap. Moodle resolves conflicting capabilities by precedence rules, and the outcome is not always what an administrator expects. The visible symptom is frustrating: **a user can no longer see or use a module they should have access to.** Here is the kind of scenario that triggers it. Take a course called "Communication": - On day one, User 1 is enrolled via a global cohort or profile field, with the `communication` and `role_member` roles. - Ten months later, the same user is enrolled again through a different method, for instance an automated course-completion enrolment, this time with the `teacher` role. Now User 1 carries two role assignments in the same course. The capabilities collide, the wrong precedence wins, and suddenly the user is locked out of activities that worked fine before. Multiply that across 20 jobs, 12 roles, and people who routinely hold several at once, and you have a support nightmare that is almost impossible to debug by hand. ## The Solution: A Permission Dashboard "Who is Who" tackles exactly that. The plugin gives administrators: - a **quick overview of all capability-related issues**. It surfaces the conflicting role and capability assignments instead of leaving you to hunt through the permissions UI context by context; - a **shortcut to fix the issue** directly from the dashboard, either by **changing permissions** or by **changing the role**. Instead of reverse-engineering Moodle's capability precedence by hand, an administrator sees the conflicts laid out and resolves them in a couple of clicks. For an organization like the LAK, where care staff wear multiple hats, that is the difference between a guessing game and a two-minute fix. We shipped it as an admin tool plugin (`tool_whoiswho`) and released a beta on GitHub during the event itself. It is open source, which is exactly how Moodle work should be: built in the open, shared back with the community that made it possible. You can find the plugin here: [github.com/meretracz/moodle-tool_whoiswho](https://github.com/meretracz/moodle-tool_whoiswho). ## The Pitch Deck Here is the deck we presented at the DevCamp: [embed:https://www.canva.com/design/DAGx1nKLmN0/PwK0f6icL26xWOqC5QJBxw/view?embed] If the slides do not load, you can [open the presentation on Canva](https://www.canva.com/design/DAGx1nKLmN0/PwK0f6icL26xWOqC5QJBxw/view). ## Why We Keep Coming Back It would be easy to treat a conference as a few days out of the office. The DevCamp turns it into something more useful. In two days we: - solved a real customer problem for a real organization; - shipped working, open-source code; - and built relationships with developers we will keep working alongside. That last point matters more than it sounds. The Moodle ecosystem runs on people knowing people. When a client hits an unusual problem, knowing who to call across the wider community is part of delivering good service. Events like MoodleMoot DACH are where those connections are made. ## See You in Zürich, June 2026 MoodleMoot DACH 2026 lands in Zürich at the end of June, and we will be there again. And yes, back in the DevCamp. If you are coming, find us. Bring a use case. Two days is enough time to build something real, and the best plugins usually start as a sketch on a whiteboard with a problem that someone genuinely needs solved. At Ldesign Media we build custom Moodle plugins, integrations, and full LMS platforms for organizations across Europe. If you have a Moodle challenge of your own, whether it is a "who is who" problem or something far larger, we would love to hear about it. --- ## MoodleMoot DACH 2025: Building a Plugin in 48 Hours at the DevCamp (NL) Source: https://ldesignmedia.nl/nl/blog/moodlemoot-dach-2025-devcamp-wie-is-wie Published: 2025-09-30 Elk jaar komt de Moodle-community uit de Duitstalige regio samen tijdens de MoodleMoot DACH. Een congres dat draait om de mensen die Moodle daadwerkelijk beheren, bouwen en ermee lesgeven. In 2025 vond het plaats in Lübeck, en met z'n drieën maakten we de reis. We kwamen voor de talks en de community, maar het echte hoogtepunt bleek het DevCamp: twee intensieve dagen waarin we vanaf nul een gloednieuwe Moodle-plugin bouwden. (Onze collega Nihaal Shaikh was er ook bij, maar bouwde in een ander team het Teacher Tours-block, dat de 2e plaats won in het DevCamp.) Dit is het verhaal van die plugin, de mensen met wie we hem bouwden, en waarom we nu al geboekt staan om het allemaal opnieuw te doen op de MoodleMoot DACH 2026 in Zürich, eind juni. ## Wat MoodleMoot DACH precies is MoodleMoot DACH is de jaarlijkse bijeenkomst voor de Duitse, Oostenrijkse en Zwitserse (DACH) Moodle-community. Het combineert het formele congresformat (keynotes, praktijkcases, roadmap-sessies) met een veel praktischer, community-gedreven kant. De editie van 2025 in Lübeck was daar een mooi voorbeeld van. Naast het hoofdprogramma waren er: - 22 DevCamp-teams die echte dingen bouwden; - 35 BarCamp-sessies, voorgesteld en geleid door de deelnemers zelf. Die mix van gestructureerde talks en open, zelf-georganiseerde sessies is precies waarom deze evenementen ertoe doen. Je vertrekt met nieuwe ideeën, nieuwe contacten en meestal ook een paar nieuwe regels code. ## Het DevCamp: van idee naar plugin in twee dagen Het DevCamp is het onderdeel waarvoor we blijven terugkomen. Het format is eenvoudig: teams vormen zich rond een echt probleem, en in ongeveer twee dagen ga je van een schets op het whiteboard naar werkende Moodle-code. Ons team (geregistreerd als Team 30, werkend vanuit de ruimte Salzspeicher) ontstond rond een concrete use case, ingebracht door Meret Racz van m-modula, voor de Liechtensteinische Alters- und Krankenhilfe (LAK). De uitdaging die zij pitchte was bedrieglijk simpel te beschrijven en echt lastig op te lossen in Moodle: - een organisatie met meer dan 20 verschillende functies; - ongeveer 12 verschillende rollen in Moodle; - en medewerkers die vaak meerdere rollen tegelijk vervullen. Wanneer één persoon tegelijk verpleegkundige, teamleider én trainer is, krijgt diegene meerdere rollen binnen dezelfde Moodle-context. En daar wordt het pijnlijk. Zo ontstond het project: **Who is Who**, een permission dashboard voor Moodle. ## Maak kennis met het team Plugins als deze zijn nooit een soloproject, en het DevCamp-format maakt dat meteen duidelijk. Ons team voor dat weekend bestond uit: - **Meret Racz**, oprichter van m-modula, die de use case pitchte en de requirements aanstuurde; - **Luuk Verhoeven** (Ldesign Media), plugin-architectuur en Moodle-internals; - **Vincent Cornelis** (Ldesign Media), backend en datamodel; - **Wafaa Mansour**, ontwikkeling en testen. Vier mensen, twee dagen, één gedeeld doel. Er zit iets verhelderends in die beperking: geen lange backlog, geen commissie, alleen een echt probleem en een strakke deadline. ## Het echte probleem: overlappende rollen in één context De use case klinkt als een rapportagevraagstuk, maar eronder zit een permissieprobleem, en een vervelende. In Moodle overlappen de capabilities zodra een gebruiker **meer dan één rol in dezelfde context** heeft. Moodle lost conflicterende capabilities op via precedentieregels, en de uitkomst is niet altijd wat een beheerder verwacht. Het zichtbare symptoom is frustrerend: **een gebruiker kan een module die hij zou moeten kunnen gebruiken ineens niet meer zien of openen.** Zo'n scenario triggert het. Neem een cursus "Communication": - Op dag één wordt User 1 ingeschreven via een globale cohort of profielveld, met de rollen `communication` en `role_member`. - Tien maanden later wordt dezelfde gebruiker opnieuw ingeschreven via een andere methode, bijvoorbeeld een automatische inschrijving bij cursusafronding, dit keer met de rol `teacher`. Nu draagt User 1 twee rolkoppelingen in dezelfde cursus. De capabilities botsen, de verkeerde precedentie wint, en plots is de gebruiker buitengesloten van activiteiten die eerder prima werkten. Vermenigvuldig dat met 20 functies, 12 rollen en mensen die er routinematig meerdere tegelijk hebben, en je hebt een supportnachtmerrie die met de hand bijna niet te debuggen is. ## De oplossing: een permission dashboard "Who is Who" pakt precies dat aan. De plugin geeft beheerders: - een **snel overzicht van alle capability-gerelateerde problemen**. Het brengt de conflicterende rol- en capabilitytoewijzingen naar boven, in plaats van je context voor context door de permissie-UI te laten zoeken; - een **shortcut om het probleem op te lossen** rechtstreeks vanuit het dashboard, door **permissies aan te passen** of **de rol te wijzigen**. In plaats van Moodle's capability-precedentie met de hand te reverse-engineeren, ziet een beheerder de conflicten uitgelijnd en lost ze in een paar klikken op. Voor een organisatie als de LAK, waar zorgmedewerkers meerdere petten dragen, is dat het verschil tussen een gokspel en een oplossing van twee minuten. We leverden het op als admin-tool-plugin (`tool_whoiswho`) en publiceerden nog tijdens het evenement een bèta op GitHub. Het is open source, precies zoals Moodle-werk hoort te zijn: in de openheid gebouwd en teruggegeven aan de community die het mogelijk maakte. Je vindt de plugin hier: [github.com/meretracz/moodle-tool_whoiswho](https://github.com/meretracz/moodle-tool_whoiswho). ## De pitchdeck Hier is de presentatie die we tijdens het DevCamp gaven: [embed:https://www.canva.com/design/DAGx1nKLmN0/PwK0f6icL26xWOqC5QJBxw/view?embed] Laden de slides niet? Dan kun je [de presentatie openen op Canva](https://www.canva.com/design/DAGx1nKLmN0/PwK0f6icL26xWOqC5QJBxw/view). ## Waarom we blijven terugkomen Het zou makkelijk zijn om een congres te zien als een paar dagen uit het kantoor. Het DevCamp maakt er iets nuttigers van. In twee dagen hebben we: - een echt klantprobleem opgelost voor een echte organisatie; - werkende, open-source code opgeleverd; - en relaties opgebouwd met ontwikkelaars met wie we blijven samenwerken. Dat laatste punt telt zwaarder dan het klinkt. Het Moodle-ecosysteem draait erop dat mensen elkaar kennen. Als een klant tegen een ongewoon probleem aanloopt, is weten wie je moet bellen in de bredere community onderdeel van goede dienstverlening. Evenementen als MoodleMoot DACH zijn de plek waar die verbindingen ontstaan. ## Tot ziens in Zürich, juni 2026 MoodleMoot DACH 2026 strijkt eind juni neer in Zürich, en we zijn er opnieuw bij. En ja, weer in het DevCamp. Kom je ook? Zoek ons op. Neem een use case mee. Twee dagen is genoeg tijd om iets echts te bouwen, en de beste plugins beginnen meestal als een schets op een whiteboard, met een probleem dat iemand écht opgelost wil zien. Bij Ldesign Media bouwen we maatwerk Moodle-plugins, integraties en complete LMS-platformen voor organisaties door heel Europa. Heb je zelf een Moodle-uitdaging, of het nu een "who is who"-vraagstuk is of iets veel groters, dan horen we daar graag over.