Now that your Moodle system is up and running, we will look at the components that make up the learning platform. Think of these as the foundation on which Moodle is built.

In this chapter, you will learn about the architecture of Moodle, what the main components of Moodle are, and where its data is stored. Moodle has a modern and intuitive user interface that takes a little bit of time to get used to. You will learn about its main navigation and where to find help if required. Dealing with files in web-based applications is not always straightforward. Therefore, you will learn how Moodle’s file management works and how to configure the recycle bin.

In this chapter, we will cover the following topics:

• Understanding the Moodle architecture
• Navigating Moodle as an administrator
• File management in Moodle
• Recycle bin

By the end of this chapter, you will know more about how Moodle is structured internally, how to work with it as an admin, and how files are managed.

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.

In this section, you will learn how to work with Moodle, which covers the horizontal navigation of the site administration section and handy tools such as admin search, bookmarks, and access to various help and support sites and channels.

The essential navigational items for administrators are as follows:

• Site menu: The main menu across all pages; the Site administration item opens up the admin menu.
• Admin menu: Access to all admin sections and subsections. As an administrator, you will be performing most tasks from here. We will cover all aspects of these menus and sub-menus throughout the remainder of this book.
• User menu: Access to personal settings, such as the user profile, preferences, or the selected language.
• Admin search: Search facility, which we will cover later.
• Edit mode toggle: Switch between editing mode and non-editing mode.
• Block drawer: Moodle blocks are placed here; edit mode must be activated to make changes to the block drawer.

These navigation elements have been highlighted in the following screenshot:

Figure 2.6 – Moodle navigation

The items displayed in the preceding screenshot might be different on your system. Depending on which features have been activated, the theme used, and your screen size, some admin menu items might move to the More dropdown, or the Language setting might appear in the user menu.

Moodle’s user interface has been built from the ground up in version 4 – gone is the breadcrumb trail, and previously omnipresent blocks have been downgraded to the block drawer. This redevelopment also impacts the navigational admin facilities, which we will cover next.

Administrator search facility

A search facility is provided to help you identify any setting in the administration section, which is located above the Site administration menu (encircled in the previous screenshot).

Moodle displays the results in an expanded form when searching for any term that allows you to change settings immediately. For example, when searching for “calendar,” numerous sections appear as a result, which can be changed in each section straight away, rather than having to navigate to each separate section to make changes.

The search facility is also highly beneficial when upgrading from older versions of Moodle, where configuration settings have been reorganized, and their location is sometimes difficult to trace.

Next up are admin bookmarks, which can potentially reduce the usage of the admin search facility.

Admin bookmarks

Bookmarks are shown in the Admin bookmarks block, which can be added by turning on Edit mode, opening the block drawer, and selecting the block from the Add a block list. They allow you to bookmark any admin menu to access regularly required pages easily. Select Bookmark this page to add a bookmark and Unbookmark this page to delete it. Moodle automatically displays the latter option when you are on a bookmarked page:

Figure 2.7 – Admin bookmarks

In the preceding screenshot, two pages have already been bookmarked (Browse list of users and Custom reports), and the mentioned link is provided to unbookmark the current marker.

Admin search and bookmarks are useful when you know what you are looking for. Next up is Moodle Docs, which assists you when you are stuck with a feature or require further support.

Moodle Docs and help

The entire Moodle documentation is online at docs.moodle.org. If you wish to provide your own documentation, modify the Moodle Docs document root setting by going to Site administration | Appearance | Moodle Docs. You can also select the Language for docs used option in links for the documentation pages and enable the Open in new window option on this screen.

At the bottom of each page, you will see a Support icon. Once selected, it will display the following help-related links:

• Help and documentation: Reference to the relevant page in Moodle Docs.
• Services and support: Link to moodle.com/help, where professional services from Moodle Certified Service Providers are offered.
• Contact site support: The standard email client will be opened, and the recipient of the support contact will be filled in. You can change the support email address by going to Site administration | Server | Support contact. This feature is more relevant to your users rather than to you as an administrator.

In addition to the online documentation, some features provide inline help, indicated by a question mark symbol. When clicked, a help window will appear to provide assistance that’s relevant to the respective topic or setting:

Figure 2.8 – Moodle help

For instance, when clicking on the Help and documentation link in the Upload users section, the following article will be opened: docs.moodle.org/400/en/Upload_users. For each version of Moodle, separate Moodle Docs are published. The preceding link is from version 4.0, where documentation for most pages exists in different languages.

When you access certain pages for the first time, Moodle will display a so-called user tour. For example, when you navigate to My courses, the following popup will be displayed:

Figure 2.9 – User tour

We will cover user tours in detail in Chapter 7, Enhancing Moodle’s Look and Feel.

The Moodle community is growing continuously and, at the time of writing, has well over 1 million registered users (yes, that’s 1 million!), of which over 5% are active. If you cannot find a solution to your Moodle problems in Moodle Docs, use the Search functionality at the top of the screen at moodle.org. In order of priority, the search brings forth the already mentioned Moodle Docs, the most active user forums, and the Moodle Tracker, which keeps track of all issues and feature requests (tracker.moodle.org). A search in Moodle forums can often result in a large number of links. Use the Advanced search area in the Search forums block to narrow the search space. If you still cannot find the solution to your problem, which is relatively rare, post a question on the relevant forum; somebody is likely to assist you further.

A popular site that might also be of interest is Moodle Academy (moodle.academy), which includes an administrator learning pathway covering short, self-paced courses on basic Moodle administration.

This concludes this section on navigating Moodle, which introduced you to the site administration menu and various helpful tools such as admin search, admin bookmarks, and Moodle Docs.

This section is all about files: how to access them, how they are organized in folders, how to upload them, how to configure private files, the difference between copying and linking, file types, increasing the upload file limit, and how to deal with deleted files via the recycle bin. This is a lot to take in, so let’s get started.

Dealing with files in web-based applications is not always straightforward. While Moodle provides a user interface to perform this task, it is sometimes necessary that, as the administrator, you will have to bypass this mechanism and use other means. First, let’s look at the built-in file handling that students and teachers also use.

Moodle file management interface

Moodle offers a basic file management interface that lets you upload, move, delete, and rename files and directories. It is also possible to copy or link to files from third-party services such as Dropbox; on the same note, Moodle isn’t a content management system.

We have already talked about how Moodle stores files at the system level—the ones we shouldn’t touch! At the application level, it arranges files according to Moodle’s structure:

Important note

In Moodle, a file is always connected to the particular bit of Moodle that uses it.

Figure 2.10 – Moodle files

Files are organized in a tree-like structure, which has three types of main branches:

• Categories/Courses/Activities and Resources
• Users (private files and personal backups)
• Site home (Moodle’s front page)

We will be dealing with all those concepts at later stages, so, for now, let’s just take them for granted. Courses are arranged in categories (and subcategories) and consist of activities and resources, and there are usually further subdirectories inside activities and resources.

There are multiple users on your system, each with a dedicated file area that can be accessed from anywhere in Moodle, but there is only a single Site Home. Remember, a file is always connected to the particular bit of Moodle content that uses it, reflected by the directory-like structure:

Figure 2.11 – Moodle folders

Now that we know how files and folders are organized, let’s look at how to upload data and create directories.

Uploading files

Uploading files usually takes place via drag and drop. While this feature is vital for learners and trainers, as an administrator, you will also have to upload files from time to time, for instance, uploading users in batch mode via a CSV file.

Adding single or multiple files is straightforward: simply select the files in your Explorer (Windows) or Finder (Mac) and drag them onto the provided area inside the dotted lines shown in the following screenshot:

Figure 2.12 – Moodle files and folders

When you click on a file once it has been uploaded, you have the option to Download or Delete the file. If the selected file is a compressed archive, you have the option to Unzip it. Additionally, meta-information about the file (name, author, license, path, icon, last modified, created, and size) is displayed at the bottom of the window, as shown in the following screenshot:

Figure 2.13 – Moodle file details

For some file operations, it is necessary to use the File picker, a tool utilized whenever files have to be added to a particular object in Moodle. A user can choose from multiple file sources, known as repositories. The File picker can be accessed using the Add… button at the top left of the files area. We will be dealing with repositories in Chapter 10, Configuring Technical Features.

Closely related to uploading files is configuring the upload limit.

Upload limit

Your site has a file upload limit set to 2 MB by default. If you need to support files larger than the 2 MB threshold, you will have to increase the limit.

In your php.ini file (find its location using the php -i command and locate the Loaded Configuration File entry), modify the following two lines; <value> represents the maximum limit (multiple input formats are supported, for example, 20M or 20971520):

• upload_max_filesize = <value>
• post_max_size = <value>

If you don’t have access to the php.ini file, create a .htaccess file in your main Moodle directory and add the following two lines:

• php_value upload_max_filesize = <value>
• php_value post_max_size = <value>

You will also have to increase the LimitRequestBody parameter on some systems, usually found in the Apache httpd.conf configuration file. You may also need to modify your database configuration, such as the max_allowed_packet size:

Figure 2.14 – Moodle upload limit

Once these changes have been applied, ensure the Maximum upload file size parameter under Site administration | Security | Site security settings has been set to Site upload limit. You can also change the user quota for private files via the Private file space parameter. When changing these two values, bear in mind that they will potentially impact the bandwidth and disk space, respectively.

For very large files such as high-quality learning resources, it would be helpful to be able to upload the content via (secure) FTP and then use the built-in unzip functionality in the File picker. However, it is not possible to upload files directly via FTP. Instead, you have to make use of the filesystem repository, which will be discussed in detail in Chapter 10, Configuring Technical Features.

Now that you are familiar with uploading files, let’s deal with personal files that belong to individual users.

Private files

Every user has an area where personal files can be stored and managed. These are only visible to the user to whom the private files belong. Any item stored in this protected area can be used throughout the site. Private files can be accessed via the File picker, the Private files block, or directly via the Private files link in the user menu:

Figure 2.15 – Moodle File picker

Handling files and directories is identical to handling other files. However, you might have spotted the Link icon in the PDF file in the preceding screenshot, which leads us nicely to the following subsection.

To link or to copy?

By default, files in Moodle are copied. When you add a file from a source (for instance, your computer or your private files), it will be copied, which means that the source and the resulting file will be logically separated. For example, if you have stored an image in your private files and you use this in three different courses, there are three logical copies. The three images will not be affected if you change the source in your private files.

Moodle also supports linking files, also known as file aliases. Let’s stick to the same example, but this time round, the three images are linked. If the source is changed, the three files in the courses will also have changed. Beware that there are some access restrictions with linked files; for example, instructor A might not be able to link to instructor B’s file.

When you select a file from a source (repository) that supports linking, an option is provided to Link to the file:

Figure 2.16 – Moodle files – copy and link

Moodle keeps track of linked files and guarantees that inconsistencies cannot occur:

• When deleting a linked file, copies of the file will be created for each link
• When a linked file is overwritten, all links are updated
• When a file overwrites a link, the files are “separated”

Linking and copying are about how files are being dealt with internally; next up are file types, which dictate how they are dealt with when users download them.

File types

Moodle does not restrict which types of files users can upload, for instance, an assignment in a course. Moodle comes with predefined values for the most popular file types in terms of the icon displayed and the program that will be opened, for example, PDF files or PowerPoint documents. However, as depicted in the following screenshot, you can add new file types and view, modify, and delete existing file types by going to Site administration | Server | File types:

Figure 2.17 – Moodle file types

When you add a new file type via the button at the bottom of the screen, you must provide the file’s Extension and its MIME type. Furthermore, you have the option to select File icon, Type groups (such as image or document), Description type, Custom description (if Description type is Custom description specified in this form), Alternative language string (if selected in Description type) and Default icon for MIME type.

So far, we have covered how files are stored, organized, and added to Moodle. Now, let’s look at what happens when files are deleted (by accident).

As an administrator, we have all been there: a user has deleted a file, an assignment with all its submissions, or even an entire course – all by accident, of course, and usually very close to an urgent deadline. Recovering the lost data is, as always, the highest priority, and you will spend the next hour or so trawling through last night’s backup to help out your panicking colleague.

To avoid scenarios like the ones described, Moodle provides a recycle bin, allowing users to retrieve course elements and courses that were mistakenly deleted. The feature is turned on by default, but you have a range of options to configure the tool’s behavior as an administrator.

To access the Recycle bin configuration, navigate to Site administration | Plugins | Admin tools | Recycle bin, where you will see three groups of settings:

Figure 2.18 – Moodle’s Recycle bin settings

The Recycle bin options are as follows:

• The Enable course recycle bin option collects any deleted resources and activities inside a course. The items will be kept for the period set in the Item lifetime parameter.
• The Enable category recycle bin option collects any deleted courses inside a category. The courses will be kept for the period set in the Course lifetime parameter.
• When the Auto hide checkbox is selected, the corresponding menu item will only be shown if the user’s bin contains any elements; otherwise, it will be hidden from the More menu in the course or category.

Items and courses will be purged permanently from the recycle bin when the respective lifetime expiry dates have passed. The life cycle of a deleted course item or a course category is depicted in the following diagram:

Figure 2.19 – Moodle Recycle bin

Initially, the recycle bin is empty or may already contain removed items or courses (in our example, two). When an element is deleted, it is moved to the user’s recycle bin, which can either be restored or purged permanently. Suppose, in the meantime, the specified lifetime of the element has expired. In that case, the file or course will be deleted permanently, alongside any other elements where the expiry date has also been reached.

As mentioned previously, the recycle bin works out of the box; if yours doesn’t function as expected, double-check the following three configurations:

• Most processes of the recycle bin are kicked off by the cron process, for example, the regular purging mechanism we just mentioned. Therefore, it is crucial that the cron process is set up correctly and runs every minute (see the dedicated Setting up the cron process section in Chapter 1, Installing Moodle).
• Internally, the recycle bin uses Moodle’s backup and restore functionality. In particular, the following two settings have to be enabled on the Automated backup setup page: Include activities and resources (backup_auto_activities) and Automated backup setup (backup_auto_users). Additionally, General restore defaults (restore_general_users) must be ticked on the General restore defaults page. You can find more detailed information on these settings in Chapter 16, Avoiding Sleepless Nights – Moodle Backup and Restore.
• If your users experience difficulties working with the recycle bin, ensure none of the required capabilities have been revoked from their roles. These are tool/recyclebin:viewitems, tool/recyclebin:restoreitems, and tool/recyclebin:deleteitems. More on roles and capabilities will be provided in Chapter 6, Managing Permissions, Roles, and Capabilities.

Learning how to use the recycle bin concludes this section on files and the management thereof.

In this chapter, we learned what the building blocks of Moodle Core look like and where they are located. Furthermore, we looked at the new intuitive user interface in an administrator’s context. Lastly, we dealt with files, folders, and the recycle bin.

As we learned in the previous chapter, Moodle can be installed on multiple operating systems, supports a wide range of databases, and can be used with different web servers. Due to the openness of Moodle, all its components can be accessed without any restrictions. Similarly, any type of file can be handled in Moodle, regardless of its type or size. An intuitive and modern user interface accompanies this setup for learners, educators, and administrators.

Now that your system is up and running and you know what its insides look like, it’s time to deal with courses, users, and roles in the next chapter.