Architecture & Core

1. config.php: The entry point loads the database configuration.

2. setup.php: Initializes the $CFG, $DB, $SESSION, $USER, $PAGE, and $OUTPUT globals.

3. Script Execution: The specific script (e.g., course/view.php) runs, checks permissions, and prepares data.

4. Output: The script calls $OUTPUT->header(), content, and $OUTPUT->footer() to render the page using the active theme.

The $PAGE global (instance of moodle_page) holds the state of the page being generated. It manages:

• The URL and Context.
• The Title and Heading.
• Required JavaScript and CSS (Requirements Manager).
• Navigation and Breadcrumbs.

Contexts define the "scope" where a user has a specific role or capability. They are hierarchical:

System > Category > Course > Module > Block

Permissions are checked against a specific context instance using has_capability() or require_capability().

• $CFG: Holds global configuration variables loaded from the database and config.php. It is available in all scripts.
• $SESSION: Stores session data for the current user's browsing session. It persists across page loads.
• $USER: Represents the currently logged-in user object, containing their ID, username, and other profile fields.

The /lib directory contains the core libraries and APIs that power Moodle. It includes database abstraction (DML/DDL), file handling, output rendering, and other essential services used by plugins and core code alike.

Renderers are responsible for generating HTML output. Moodle uses a renderer factory to create instances of renderers. Themes can override these renderers to customize the HTML structure without modifying core code, adhering to the separation of logic and presentation.

Moodle uses the File API to manage files securely. Files are not stored directly in the web root but in a separate moodledata directory. The database stores metadata (references) to these files, and access is controlled via the pluginfile.php script which checks permissions before serving content.

The cron process is the heartbeat of Moodle, handling background tasks such as sending forum notifications, processing assignment submissions, and cleaning up temporary data. It runs scheduled tasks defined by core components and plugins.

Moodle's Event system allows plugins to subscribe to actions occurring within the system (e.g., 'user_created', 'course_viewed'). It follows the Observer pattern. Events are defined in classes/event and can be triggered to log actions or execute custom logic via observers.

The MUC is Moodle's caching system that allows administrators to configure how data is cached. It supports multiple backends (stores) like Redis, Memcached, or the file system. Developers use the Cache API to store and retrieve data, while the MUC handles the underlying storage mechanism.

isloggedin() returns a boolean indicating if a user is authenticated. It does not stop script execution.

require_login() checks if the user is logged in and has access to the specified course or module. If not, it redirects them to the login page or displays an error. It is a security gatekeeper.

Moodle uses Mustache for templating to separate logic (PHP) from presentation (HTML). Templates are stored in the templates folder of a plugin. Data is passed to the template via a context array, and renderers render them using $OUTPUT->render_from_template().

Function: The String Manager handles internationalization (i18n). It retrieves localized strings from language packs.

Usage: get_string('identifier', 'component', $a).

Importance: Hardcoding text in Moodle is strictly forbidden. Using the String Manager ensures the interface can be translated into any language supported by Moodle.

• DDL (Data Definition Language): Managed by $manager = $DB->get_manager();. Used for creating/modifying tables and fields (e.g., during installation or upgrade).
• DML (Data Manipulation Language): Managed by the global $DB object. Used for querying, inserting, updating, and deleting records (e.g., $DB->get_record()).

Mustache is a logic-less template engine used by Moodle for rendering the UI. Templates are stored in the templates folder of a plugin or theme. They allow for a clear separation between PHP logic and HTML structure, facilitating easier theming and JavaScript interaction.

Moodle uses AMD (Asynchronous Module Definition) modules via RequireJS. JavaScript files are placed in the amd/src directory and compiled (transpiled/minified) into amd/build. They are loaded in PHP using $PAGE->requires->js_call_amd().

The /admin directory contains the code for the Site Administration interface. It handles configuration settings, user management, plugin management, and system reports. It is the control center for Moodle administrators.

A course format determines the layout of a course page (e.g., Weekly, Topics, Social). It controls how sections and activities are displayed. Developers can create custom course formats to change the learning experience structure.

Filters are plugins that process text before it is output to the browser. They can auto-link words, embed multimedia, or convert mathematical notation (e.g., TeX) into images. They operate on content output by other plugins.

The Backup and Restore API allows courses, activities, and user data to be exported to .mbz files and imported back. It uses a step-based architecture to traverse the course structure and serialize data into XML, handling dependencies and file references.

The Web Services API allows external systems (like the Moodle Mobile App or HR systems) to interact with Moodle. It supports protocols like REST, SOAP, and XML-RPC. Functions are defined in db/services.php and enforce permission checks.

upgrade.php (in db/ folder of a plugin) contains the code to migrate the database schema and data from an older version of a plugin to a newer one. It is executed automatically when the admin visits the Notifications page after updating the plugin code.

The Navigation API builds the navigation block and the navigation bar (breadcrumbs). Plugins can extend the navigation by creating a lib.php function named {pluginname}_extend_navigation() or {pluginname}_extend_settings_navigation().

YUI (Yahoo User Interface) was the primary JavaScript library in older Moodle versions. While still present for backward compatibility, modern Moodle development prefers jQuery and ES6 modules (AMD). New development should avoid YUI.

Debugging is enabled in config.php by setting $CFG->debug and $CFG->debugdisplay. Developers use debugging() calls to log messages. The 'Developer' debugging level shows all PHP notices and warnings.

The String Manager handles localization. It retrieves strings from language packs using get_string(). It supports string overriding and customization without changing the core language files.

A capability is a specific permission (e.g., mod/forum:replypost). Capabilities are grouped into Roles (e.g., Student, Teacher). The combination of Role assignments in a Context determines a user's actual permissions.

The Form API (moodleform) is a wrapper around the PEAR HTML_QuickForm library. It provides a standardized way to create secure forms with validation, file uploads, and consistent styling. Forms are defined as classes extending moodleform.

Purging caches clears all Moodle caches (MUC, theme, javascript, language). It is necessary when making changes to db/ files, language strings, or theme CSS/JS to ensure the changes are reflected immediately.

The Task API manages scheduled tasks (cron) and ad-hoc tasks (background processing). It allows tasks to be scheduled, run in parallel, and managed via the admin interface. It replaces the legacy cron.php function approach.

Behat is a Behavior Driven Development (BDD) framework used for acceptance testing in Moodle. It allows developers to write human-readable scenarios (Gherkin syntax) that simulate user interactions with the browser to verify features work as expected.