Understanding the Moodle architecture

First, we will look at the overall architecture on which Moodle is based before we cover the internal components of the LMS’s application layer.

We will take a top-down approach and look at the overall architecture first before zooming into how Moodle Core is structured. We will conclude at the lowest level, where we will be dealing with files and the management thereof.

The LAMP architecture

Moodle has been developed on the open-source LAMP framework, which consists of Linux (operating system), Apache (web server), MySQL (database), and PHP (programming language). Due to the portability of these components and the modularity of Moodle itself (that’s what the “M” stands for), a wide range of operating systems, database systems, and web servers are supported. However, while Moodle runs on other technology stacks, we will focus on LAMP since it has proven the most popular setup among Moodle administrators.

The following diagram shows a simple overview of the overall architecture:

Figure 2.1 – Moodle’s overall architecture

Let’s have a closer look at the components of Moodle’s overall architecture:

• Moodle Core is what is often referred to when people talk about Moodle. This is also what we installed in the previous chapter and will be covered in this book.
• Moodle plugins: While Moodle Core is a powerful and comprehensive LMS, few sites solely rely on the base system. Instead, add-on modules supplement the feature set of standard Moodle to customize the platform to individual requirements. These add-ons are called Moodle plugins and are mostly community-contributed additions to standard Moodle, extending its functionality for a specific use case. At the time of writing, there are almost 2,000 (!) entries in the official Moodle plugins database at moodle.org/plugins.

Important note

Moodle LMS is effectively standard Moodle plus – optionally – one or many Moodle plugins.

An exciting set of plugins has been made available by Moodle HQ. Moodle Workplace is a commercial offering designed for corporate and organizational training, resulting in a powerful and flexible platform for workplace learning. More information on Moodle Workplace can be found at moodle.com/workplace or in the title Corporate Learning with Moodle Workplace, by Packt Publishing.

• 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. Specific PHP libraries must be installed – see Chapter 1, Installing Moodle.
• MySQL is the database of choice for most opensource applications, but other systems, such as Microsoft SQL Server, Oracle, and PostgreSQL, are fully supported. MariaDB, a MySQL fork, has become very popular among Moodle administrators after Oracle acquired 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 other that supports PHP, such as nginx. This book will focus on Apache, the most popular option for Moodle setups.
• Operating system: The lowest level is the operating system. While Linux is the preferred platform – since this is where all code is developed and tested –other operating systems are also supported, such as Windows, Mac OS X, and various Unix derivatives.

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

Figure 2.2 – Moodle’s interaction among underlying components

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

The component of most interest to us is Moodle Core, which we will dive into in more detail next.

Moodle Core

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

Figure 2.3 – Moodle’s building blocks

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

Moodle libraries, modules (such as resources and activities), blocks, plugins, admin tools, and other entities are represented in code. It is always stored in the filesystem in a Moodle directory referred to as dirroot, which was 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, competencies, learning plans, grades, and other data, such as learning resources added by educators, forum posts added by learners, 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, 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, referencing the respective files.

Important note

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, which means that further behavior cannot be predicted. Internally, Moodle uses a mechanism called SHA1 hashing. Moodle fully supports Unicode filenames and avoids redundant storage when the same file is used twice (even by different users). Again, you must not modify any Moodle files at the system level!

Now, let’s have a closer look at how the Moodle files area – the directory structure – is organized.

Code and data locations

Though Moodle takes care of organizing 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 manually applying patches.

System files – files required to run Moodle – are located in several directories under dirroot (the root directory of your Moodle installation). The following table shows the folder name, a brief description, and the chapter in which the topic is covered in this book:

Figure 2.4 – Code and data locations

The moodledata directory (dataroot) is organized as follows:

Figure 2.5 – moodledata directories

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, models, muc, sessions, temp, and trashdir. Purging can either be done manually or, better, via Site administration | Development | Purge caches | Purge all caches in the Moodle interface.

This concludes this section on the Moodle architecture, which dealt with the LAMP framework and Moodle’s main components before we drilled down to Moodle Core and the location of code and data files.