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. That is, its goal is to give teachers and students the tools they need to teach and learn. Although it comes from a background of Social Constructionist pedagogy, 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 funcitonality. Instead it focusses on the LMS area of functionality as well as possible, and then interoperates 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 you 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, and authentication plugin and an activity module will communicate with Moodle core using very different APIs each specifically tailored to the type of functionality the plugin will provide. 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. Moodle core
An overview of Moodle core
Apologies, this section is not complete yet. If you have the knowledge and time, please add to it.--Tim
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 course, which is a sequence of activities organised into sections. Courses are organised into a hierarchical set of categories within a Moodle site.
Users
Users, profile, my moodle ... (sorry, can't be bothered to explain all this now, will just make notes.)
Groups and cohorts
Enrolments and access control
Contexts, roles, capabilities, and permissions, ...
Activity and course completion
Forms library
Installation, upgrade
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.
Logs, reporting, 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, quiz, .... 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.
Blocks
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, allowing that information to be displayed on the course page, for example. Blocks live in the blocks folder.
Themes
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, and you can get language packs for many languages. Language packs are normally installed via the Moodle administration screens, but can also be downloaded manually from http://download.moodle.org/langpack/2.0/. 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
Controls 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
Controls 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
Controls 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.
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.
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 follows mostly a transaction script approach. That is, suppose you are looking a a Forum. The URL will be .../mod/forum/view.php, and that is the PHP script that will be in overall control of the display of that page. One could argue that transaction script is not an appropriate design for an application as complex as Moodle. However, it fits very naturally with how PHP works, and Moodle is an aggregate of many different plugins, rather than a single complex application.
However, 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.)
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.
