Understanding the Moodle architecture
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.
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.
- 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 component of most interest to us is Moodle Core, which we will dive into in more detail next.
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.
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
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
trashdir. Purging can either be done manually or, better, via Site administration | Development | Purge caches | Purge all caches in the Moodle interface.