Moodle architecture: Difference between revisions

Revision as of 18:08, 8 December 2010

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

Navigation, settings and configuration

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.

@@ Line 1: / Line 1: @@
-From a system administrator's perspective, Moodle has been designed according to the following criteria:
+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 [[Development:Developer_documentation|developer documentation]].
-== Moodle should run on the widest variety of platforms ==
-The web application platform that runs on most platforms is PHP combined with MySQL, and this is the environment that Moodle has been developed in (on Linux, Windows, and Mac OS X). Moodle also uses the ADOdb library for database abstraction, which means Moodle can use more than ten different brands of database (unfortunately, though, it can not yet set up tables in all these databases - more on this later).
+==What is Moodle?==
-== Moodle should be easy to install, learn and modify ==
+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.
-Early prototypes of Moodle (1999) were built using Zope - an advanced object-oriented web application server. Unfortunately I found that although the technology was pretty cool, it had a very steep learning curve and was not very flexible in terms of system administration. The PHP scripting language, on the other hand, is very easy to get into (especially if you've done any programming using any other scripting language). Early on I made the decision to avoid using a class-oriented design - again, to keep it simple to understand for novices. Code reuse is instead achieved by libraries of clearly-named functions and consistent layout of script files. PHP is also easy to install (binaries are available for every platform) and is widely available to the point that most web hosting services provide it as standard.
+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.
-== It should be easy to upgrade from one version to the next ==
+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.
-Moodle knows what version it is (as well as the versions of all plug-in modules) and a mechanism has been built-in so that Moodle can properly upgrade itself to new versions (for example it can rename database tables or add new fields). If using CVS in Unix for example, one can just do a "cvs update -d" and then visit the site home page to complete an upgrade.
-== It should be modular to allow for growth ==
+==Overview of a Moodle installation==
-Moodle has a number of features that are modular, including themes, activities, interface languages, database schemas and course formats. This allows anyone to add features to the main codebase or to even distribute them separately. More on this below in the next section.
+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).
-== It should be able to be used in conjunction with other systems ==
+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===
+===Navigation, settings and configuration===
+===Forms library===
+===Installation, upgrade===
+===JavaScript library===
+Moodle has adopted the [http://developer.yahoo.com/yui/3/ 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 [http://moodle.org/mod/data/view.php?id=6009 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 <tt>mod</tt> 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 <tt>blocks</tt> 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 <tt>theme</tt> folder. Themes are listed in the [http://moodle.org/mod/data/view.php?id=6552 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 <tt>course/format</tt> 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 <tt>auth</tt> 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 <tt>enrol</tt> 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 [[Development:Developer_documentation#Make_a_new_plugin|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 <tt>get_plugin_types()</tt> function, which is defined in <tt>lib/moodlelib.php</tt>.
+==How Moodle code is organised==
+Moodle follows mostly a [http://martinfowler.com/eaaCatalog/transactionScript.html 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 <tt>lib</tt> folder). This provides elements of a [http://martinfowler.com/eaaCatalog/domainModel.html 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 [[Development:Database_schema_introduction|Database schema introduction]] for more information.
+The Moodle database structure is defined in <tt>install.xml</tt> files inside the <tt>db</tt> folder in each plugin. For example <tt>mod/forum/db/install.xml</tt> contains the database definition for the forum module. <tt>lib/db/install.xml</tt> defines the tables used by Moodle core. The <tt>install.xml</tt> 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==
+* [[Administrator documentation]]
+* [[Development:Developer_documentation|Developer documentation]]
+* [[Development:Database_schema_introduction|Database schema introduction]]
+* [http://moodle.org/mod/data/view.php?id=6009 Modules and plugins] and [http://moodle.org/mod/data/view.php?id=6552 themes] databases
+* [http://moodle.org/mod/forum/discuss.php?d=64465 Forum thread with a vigorous argument about whether an architecture document is a good idea, which eventually lead to this page being rewritten]
-One thing Moodle does is keep all files for one course within a single, normal directory on the server. This would allow a system administrator to provide seamless forms of file-level access for each teacher, such as Appletalk, SMB, NFS, FTP, WebDAV and so on. The authentication modules allow Moodle to use LDAP, IMAP, POP3, NNTP and other databases as sources for user information. Otherwise, there is work yet to do. Features planned for Moodle in future versions include: import and export of Moodle data using XML-based formats (including IMS and SCORM); and increased use of style sheets for interface formatting (so that it can be integrated visually into other web sites).
 [[Category:Coding guidelines]]

Documentation