How It Started: Moodle 1.8 and a Platform Still Finding Itself
When Ldesign Media 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 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, 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.
