Moodle architecture

We will first look at the overall architecture on which Moodle is based, before we cover the internal components of the VLE application layer.

The LAMP architecture

Moodle has been developed on the open source LAMP framework consisting of Linux (operating system), Apache (web server), MySQL (database), and PHP (programming language). While Moodle runs on other technology stacks, we will focus on LAMP since it has proven to be the most popular setup among Moodle administrators. Due to the portability of these components and the modularity of Moodle itself (that's what the M stands for), it can support a wide range of operating systems, database systems, and web servers. The following diagram shows a simple overview of the overall architecture:

The lowest level is the operating system. While Linux is the preferred platform, other Unix derivatives such as Solaris and AIX are supported, along with Windows and Mac OS X (preferably the server variants for production sites). Certain libraries will have to be installed; refer to Chapter 1, Moodle Installation.

PHP is the programming language in which Moodle is written (accompanied by HTML, JavaScript, and CSS files). It is the only component that cannot be replaced with any other counterpart.

MySQL is the database of choice for most open source applications, but other database systems such as Microsoft SQL Server, Oracle, PostgreSQL, and MongoDB are fully supported. Some details have been provided in the previous chapter but, as mentioned before, the focus in this book will be on MySQL.

Apache has become the de facto standard for large-scale web applications, closely followed by Microsoft IIS. Both web servers are supported like any others offering PHP support. In this book, we will focus on Apache as it is the most popular option for Moodle setups.

The following diagram shows the interaction of the elements in the Moodle architecture:

The user makes requests via the web browser interface or a mobile Moodle application (for example, to display a learning resource). The web browser passes the request on to the web server(s), which calls the PHP module that is responsible for the call. The PHP module calls the database with an action (query, update, insert, or delete operation) that returns the requested data. Based on this information, the PHP module returns data (usually in the form of HTML or JavaScript code) to the web server(s), which passes the information to be displayed back to the user's browser or application.

The Moodle layer

Now, let's look at the Moodle layer in more detail. Moodle's main building blocks are shown in the following diagram:

Moodle distinguishes between code (mostly written in PHP, HTML, and CSS) and data (mostly value added via the Moodle interface).

Moodle libraries, modules (such as resources and activities), blocks, plugins, and other entities are represented in code. It is always stored in the file system in a Moodle directory referred to as dirroot, which has been specified during the installation process in the previous chapter. The code includes all the elements that deal with the backend (server) and frontend (user interface) operations.

Moodle courses, users, roles, groups, grades, and other data such as learning resources added by teachers, forum posts added by students, and system settings added by the administrator are mostly stored in the Moodle database. However, files such as user pictures or uploaded assignments are stored in another Moodle directory, known as moodledata, which is located in a directory called dataroot. Information about files (metadata such as the name, location, last modification, license, and size) is stored in the database, which references the respective files.

Tip

Moodle manages its files internally, and it is important to stress that interfering with any files in moodledata will break the application.

Even copying a file from one folder to another or adding a file manually will break the consistency of your system and further behavior cannot be predicted. Internally, Moodle uses a mechanism called SHA1 hashing. Moodle fully supports Unicode file names and also avoids redundant storage when the same file is used twice (even by different users). Again, you must not modify any Moodle files at system level!

Now let's have a closer look how the Moodle files area—the directory structure—is organized.

Code and data locations

Though Moodle takes care of the organization, of its code and data, it is usually good to know where a file is located in your learning system, for example, when installing add-ons or applying patches.

System files—files that are required to run Moodle—are located in a number of directories under dirroot (the root directory of your Moodle installation):

The moodledata directory (dataroot) is organized as follows:

If problems occur before carrying out an update, it is sometimes necessary to delete caching data and any temporary information Moodle has created. This data is located in the respective directories in the structure shown in the preceding table. In other words, once everybody has logged out, you can safely delete any files in the directories named cache, filter, localcache, lock, muc, sessions, temp, and trashdir. This can either be done manually or, better, via Development | Purge all caches in the Moodle interface, which we will cover next.