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 than 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 en:Installing Moodle). Similarly, Moodle can always self-upgrade from one version to the next (see en:Upgrading).

Moodle as a modular system

Like many successful open source systems, Moodle is structured as an application core, surrounded by numerous plugins to provide specific functionality. Moodle is designed to be highly extensible and customizable without modifying the core libraries, as doing so would create problems when upgrading Moodle to a newer version. So when customizing or extending your own Moodle install, always do so through the plugin architecture.

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 add-ons or removing standard plugins. Most add-ons that have been shared publicly are listed in the Moodle Plugins Directory.

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

Moodle core provides all the infrastructure necessary to build a Learning Management System. 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 and resources grouped into sections. Courses themselves are organized into a hierarchical set of categories within a Moodle site.

Users: In moodle, users are anyone who uses the moodle system. In order to participate in course users need to be enrolled into course with a given role, such as:

   Students
   Teachers

User functionality in moodle:

   User roles in moodle: A role is an identifier of the user's status in some context. For example: Teacher, Student and Forum moderator are examples of roles.

   User's capabilities in moodle: A capability is a description of some particular Moodle feature. Capabilities are associated with roles. For example,
mod/forum:replypost is a capability.

   Context: A context is a "space" in the Moodle, such as courses, activity modules, blocks etc.

   Permissions: A permission is some value that is assigned for a capability for a particular role. For example, allow or prevent.

Added facilities provided by moodle: Added facilities provided by moodle:

   Creation and editing of user profiles: In moodle, the moment an user creates his account, a profile is created for that user. The user needs to fill in his initial details for completing his profile. The user generally always have the permission to edit his own profile anytime on moodle.

   Groups and cohorts: Cohorts, or site-wide groups, enable all members of a cohort to be enrolled in a course in one action, either manually or synchronised automatically.

   Enrolments and access control: Users are generally enrolled into some courses and according to their permission settings and the groups to which they belong, they have limited access on moodle.

A bit more about moodle:

   Activity and course completion:
   The activity completion system allows activities such as Quizzes, SCORM modules, etc. to be marked complete when specified conditions are met.

   Navigation, settings and configuration:
   The Navigation block provide easy access to view various sections of the Moodle site and includes:

       My home - a personalised home page displaying links to the courses a user is associated with and activity information (such as unread forum posts and upcoming assignments)
       Site pages - links to site pages and resources from the front page of Moodle
       My profile - quick links allowing a user to view their profile, forums posts, blogs and messages as well as manage their private files
       My courses - lists (by course shortname) and links to courses the user is associated with. Click the course's shortname to view the front page of the course or use the arrows to navigate quickly to a specific section, resource or activity.

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.

Upgradation of moodle: Moodle can be upgraded in four simple steps:

   Make sure that your server can run the lates Moodle version
   You should always be prepared to "roll back" if there's an issue with your data or some custom code you've added. So before comitting, create a test install and always make backups.
   At this stage you can replace the Moodle code on your server with the version you downloaded and check for the plugins.
   Perform the upgrade by triggering the upgrade from the admin page.
   (More information abour upgradation can be found here : https://docs.moodle.org/23/en/Upgrade_overview)

Logs and statistics in moodle:

   Statistics in moodle: The statistics graphs and tables show how many hits there have been on various parts of your site during various time frames. They do not show how many distinct users there have been. They are processed daily at a time you specify. You must enable statistics before you will see anything.

   Log in moodle: Logs in Moodle are activity reports. Logs are available at site level and course level.

Forms library

The most important plugin types

Activities and resources

Activities and resources are the most basic individual components that make up a course and are the main tools for teaching and learning. Some examples of resources are: pages, links and IMS content packages. Examples of activities include: forums, wikis, quizzes, and assignments.

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. Both activities and resources are installed in the mod folder.

Blocks

Blocks are small bits of interface functionality that can be added to (normally the sides of) pages. Many blocks provide additional views of data stored and modified elsewhere. Blocks live in the blocks folder.

Themes

The overall visual style of a Moodle site, a particular course, or all courses in a category, can be changed by selecting a different theme at these different levels. Themes are the standard way of making aesthetic changes to your Moodle application, decoupling presentation from content and functionality.

Themes live in the theme folder, and published 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 Moodle.org: language packs.

Administrators can also manually 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.

Others

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 in 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.

Documentation