Moodle architecture

Jump to: navigation, search

Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Moodle architecture.

The aim of this document is to quickly give an overview of how the Moodle works at a technical level. Hopefully this will be helpful to Administrators and Developers. However, to actually do Moodle development you will have to study the code in much more detail that is provided here. See the developer documentation.

What is Moodle?

Moodle is a Learning Management System, Course Management System, or Virtual Learning Environment, depending on which term you prefer. Its goal is to give teachers and students the tools they need to teach and learn. Moodle comes from a background of Social Constructionist pedagogy, however, it can be used to support any style of teaching and learning.

There are other types of software systems that are important for educational institutions, for example ePortfolios, Student Information Systems and Content repositories. Generally, Moodle does not try to re-invent these areas of functionality. Instead, tries to be the best LMS possible, and then interoperate gracefully with other systems that provide the other areas of functionality. It is, however, perfectly possible to use Moodle as a stand-alone system, without integrating it with anything else.

Moodle is a web application written in PHP. Moodle is open source. Copyright is owned by individual contributors, not assigned to a single entity, although the company Moodle Pty Ltd in Perth Australia, owned by Moodle's founder Martin Dougiamas, manages the project.

Overview of a Moodle installation

A Moodle installation comprises the Moodle code executing in a PHP-capable web server; a database managed by MySQL, PostgreSQL, Microsoft SQL Server, or Oracle; and a file store for uploaded and generated files (the moodledata folder).

All three parts can run on a single server; or they can be separated with many load-balanced web-servers, a database cluster, and a file-server; or anywhere between those extremes.

Moodle is designed to be simple to install on any server that meets these basic requirements. Moodle self-installs once the code has been copied to the web server and a blank database created (see Installing Moodle). Similarly, Moodle can always self-upgrade from one version to the next (see Upgrading).

Moodle as a modular system

Like many successful open source systems, the moodle structured as a core system, surrounded by numerous plugins to provide specific functionality.

Plugins in Moodle are of specific types. That is, an authentication plugin and an activity module will communicate with Moodle core using different APIs, tailored to the type of functionality the plugin provides. Functionality common to all plugins (installation, upgrade, permissions, configuration, ...) are, however, handled consistently across all plugin types.

The standard Moodle distribution includes Moodle core and a number of plugins of each type, so that a new Moodle installation can immediately be used to start teaching and learning. After installation a Moodle site can be adapted for a particular purpose by changing the default configuration option, and by installing and removing plugins.

Physically, a Moodle plugin is just a folder of PHP scripts (and CSS, JavaScript, etc. if necessary). Moodle core communicates with the plugin by looking for particular entry points, often defined in the file lib.php within the plugin.

An overview of Moodle core

Apologies, this section is not complete yet. If you have the knowledge and time, please add to it.--Tim Hunt 18:28, 8 December 2010 (UTC)

Moodle core provides all the infrastructure necessary to build an LMS. It implements the key concepts that all the different plugins will need to work with. These include

Courses and activities

A Moodle course is a sequence of activities grouped into sections.

Courses are organised into a hierarchical set of categories within a Moodle site.


Users, profile, my moodle ...

Groups and cohorts

Enrolments and access control

Contexts, roles, capabilities, and permissions, ...

Activity and course completion

Navigation, settings and configuration

Forms library

JavaScript library

Moodle has adopted the Yahoo User Interface library. There is also a nice system for loading the additional JavaScript files required by each page.

Installation and upgrade

Logs and statistics

The most important plugin types

Most plugins that have been shared publicly are listed in the Modules and plugins database.

Activities and resources

The individual items that make up a course. The main tools for teaching and learning. For example forum, wiki and quiz, and page, url and IMS content package. Activities are by far the largest type of plugin in terms of amount of code. A forum or wiki system could be a software project in its own right. Activities and resources are installed in the mod folder.


Small bits of functionality that can be added to the sides (normally) of other pages. Many blocks provide views of data that is available elsewhere. Blocks live in the blocks folder.


The overall visual style of a Moodle site, or of a particular course, or all courses in a category, can be changed by selecting a different theme. Themes live in the theme folder. Themes are listed in the Themes database.

Language packs

Moodle is internationalised. That is, you can get language packs for many different languages. Language packs are normally downloaded and installed via the Moodle administration screens, but they can also be downloaded manually from Administrators can also change any of the standard user-interface strings, if the terms used in the installed language pack are not appropriate.

Course formats

control how the structure of the course, a sequence of activities grouped into sections, is presented to the users. Course formats live in the course/format folder.

Authentication plugins

control how users log in. Moodle can manage usernames and passwords itself, or use those stored in LDAP or another database. Alternatively, Moodle can use a number of single-sign-on schemes. Authentication plugins live in the auth folder.

Enrolment plugins

control which users are enrolled in which courses. Again this can be by synchronising with another system, perhaps a student information system, or it can be tracked internally by Moodle. Enrolment plugins live in the enrol folder. (Moodle was created by an Australian, so enrol is the correct spelling ;-).)

Repository plugins

Ways for users to get content (files) into Moodle, either by uploading from their hard drive, or by getting the file from another location on the Internet, perhaps Drop Box, Google Docs, or Flickr. Repository plugins live in the repository folder.


There are many more types of plugins (more than 30 at the last count). These include text filters, question types, gradebook reports, admin reports, course reports, plagiarism detection services and web service protocols.

For a definitive, up-to-date list, look at the value returned by the get_plugin_types() function, which is defined in lib/moodlelib.php.

How Moodle code is organised

Moodle mostly follows a transaction script approach. That is, suppose you are looking a Forum. The URL will be .../mod/forum/view.php?id=1234. and mod/forum/view.php the PHP script that generates that page. One could argue that transaction script is not an appropriate pattern for an application as complex as Moodle. However, it is a very natural architecture for a PHP application, and Moodle is an aggregate of many different plugins, rather than a single complex application.

Behind that basic transaction script approach, a lot of the core functionality has be refactored out into libraries (mostly in the lib folder). This provides elements of a domain model. The Moodle project started before PHP could handle object-oriented code, however, so don't expect an object-oriented domain model, except is some of the more recent parts of the Moodle code.

There are two layers used to separate presentation from the business logic. The outer layer is the theme (see above) which controls the more visual aspects of the Moodle interface. Then there are renderer classes which generate the HTML to be output from the data supplied by the transaction scripts and the domain model. Unfortunately, neither PHP, nor the Moodle architecture, enforces a clear separation of the UI layer. It is possible for sloppy developers to make a mess, and this has happened in the past. The code in the standard Moodle distribution is gradually being cleaned up.

The Moodle database

The Moodle database comprises many tables (more than 250) because the whole database is an aggregate of the core tables and the tables belonging to each plugin. Fortunately, this large structure is understandable, because the tables for one particular plugin typically only link to each other and a few core tables. See Database schema introduction for more information.

The Moodle database structure is defined in install.xml files inside the db folder in each plugin. For example mod/forum/db/install.xml contains the database definition for the forum module. lib/db/install.xml defines the tables used by Moodle core. The install.xml files contain comments that should explain the purpose of each table and column. These comments can be turned into human-readable documentation by going to Site administration -> Development -> XMLDB editor in your Moodle installation, and clicking on the [Doc] link.

See also