For years, installing and maintaining a Moodle platform has been a relatively straightforward process: download the code, add the necessary plugins and update the system whenever a new version was released.
But the Moodle ecosystem is evolving. And we’re not just talking about new features or visual improvements. Moodle is undergoing a fundamental transformation of its architecture to make it more modular, scalable and future-proof.
This was precisely the topic of the presentation given by Antoni Bertran, CTO of 3ipunt, at MoodleMoot Spain 2026, where he explained why Composer will be a key component in the management of future versions of Moodle and what this change means for developers and platform administrators.
Moodle is evolving very quickly
The latest versions of Moodle do not just incorporate new features. They are also laying the foundations for a new technological architecture.
The aim is to move away from a monolithic model and evolve towards a system made up of independent components that can be developed, updated and maintained autonomously. This transformation is being driven by the Technical Transformation Team (PAG) and forms part of Moodle’s public roadmap.
The main objectives include:
- Break the system down into smaller components.
- Allow updates independent of the core.
- To facilitate the adoption of new technologies, beyond PHP.
- To improve the scalability and maintenance of the ecosystem.
In other words, Moodle is paving the way to become a much more flexible platform that is easier to develop further.
A more modern style of architecture
This change is not simply a matter of reorganising the code. It involves adopting a set of architectural principles that are already commonplace in modern applications.
These include:
- Completely separate the user interface from the business logic.
- Access the information via APIs only.
- To create standalone components capable of providing full functionality.
- Maintain and deploy each component independently.
- Encourage the use of containers and automated deployment processes.
- To allow for a gradual transition, in which the traditional model and the new one coexist for a while.
This approach will enable Moodle to evolve much more flexibly without relying on major core updates.
What is Composer?
It is against this backdrop that Composer, the standard dependency manager for the PHP ecosystem, comes into its own.
If you’ve never used it before, you can think of it as a tool that automates the installation and updating of libraries and components, ensuring that all versions are compatible with one another.
This avoids many of the common problems that arise when a platform uses multiple dependencies or when several plugins require different versions of the same library.
Far from being a tool exclusively for developers, Composer is becoming an essential tool for maintaining complex projects in a more secure and organised manner.
Why is Moodle opting for Composer now?
The answer is simple: the ecosystem has grown, and it is no longer sustainable to manage all the dependencies manually.
During the presentation, several reasons were put forward to explain this change:
- Moodle 5.1 now requires Composer to manage certain PHP dependencies.
- There are an increasing number of external libraries and dependencies between components.
- Resolving version conflicts manually is no longer a viable option.
- Modern tools such as OpenTelemetry require features specific to Composer.
- The community is calling for development processes that are more standardised and integrated with DevOps practices.
It’s not about introducing a new tool just for the sake of it, but about adapting to the needs of a project that continues to grow year on year.
The three pillars of Composer in Moodle
One of the most interesting aspects of the presentation was learning how Moodle has organised the integration of Composer through three main packages.
moodle/seed
This is the template used to create a new Moodle project based on Composer.
Its function is to automatically connect the other components required to set up a modern Moodle installation.
moodle-composer-scaffold
This package sets up the entire project structure. Among other tasks:
- generates the configuration file;
- configure the autoloading system;
- organises the directories;
- makes the initial installation of Moodle easier.
moodle-composer-installer
Its aim is to simplify the installation of plugins. It automatically detects the type of plugin (activity, block, local, etc.) and installs it in the relevant folder without the need to do this manually.
What are the benefits of Composer?
Beyond the technical changes, the introduction of Composer brings very practical benefits for those who manage Moodle platforms.
These include:
- installing plugins with a single command;
- automatic dependency resolution;
- consistent version management;
- seamless integration with continuous integration and continuous deployment (CI/CD) processes;
- reducing conflicts between plugins and the Moodle core.
In projects involving multiple developers or complex installations, these improvements can lead to fewer incidents and much more efficient maintenance.
Do I need to start using Composer straight away?
This was probably one of the most frequently asked questions during the session. The answer is: it depends, but it’s a good idea to start getting to know it.
Currently:
- In Moodle 5.2 and 5.3, Composer is now mandatory for certain PHP dependencies.
- The full installation of Moodle via Composer remains optional.
- Looking ahead to Moodle 6.0, Composer will continue to take centre stage, although it has not yet been decided whether it will also be mandatory for installing Moodle from scratch.
In any case, the direction the project is taking makes it clear that Composer will be a standard tool in the Moodle ecosystem in the coming years.
It’s not all good news
As with any technological change, the transition also presents certain challenges.
Many organisations maintain dozens or even hundreds of their own plugins. Every new version of PHP involves checking compatibility, fixing obsolete code and updating automated tests.
Furthermore, the pace of adoption of new technologies also depends on external dependencies and plugins developed by third parties. For this reason, Moodle has opted for a gradual evolution, whereby the traditional model will coexist with this new architecture for a while.
Composer isn’t the future. It’s the present.
Although it is not yet compulsory for all installations, Composer is already part of the direction Moodle is taking.
Understanding how it works and what benefits it offers will enable you to approach future versions of the platform with greater confidence and adopt much more modern development practices.
At 3ipunt, we closely monitor developments in the Moodle ecosystem to help our clients get the most out of each new version. If you’d like to find out how to prepare your platform for this new phase, or if you need support with managing and developing your Moodle, we’d be delighted to help.
