47 docs tagged with "API"

There are changes to the completion API introduced in Moodle 3.11 to be incorporated to this page. Please refer to Student activity completion for details.

Activity modules are a fundamental course feature and are usually the primary delivery method for learning content in Moodle.

Adhoc tasks are typically used when you need to queue something to run in the background either immediately, where they would be executed as soon as possible, or as a one-off task at some future point in time.

The Analytics API allows managers to use predictions to detect trends and predict student behaviour

The Backup API provides a way to include your plugin's in the course backup. See Restore API for the part that takes care of restoring data.

This document provides an in-depth overview of the Cache API, also known as MUC (Moodle Universal Cache), a fundamental caching system within Moodle.

A Check is a runtime test to make sure that something is working well. You can think of Checks as similar and complimentary to the PHPUnit and Acceptance testing but the next layer around them, and performed at run time rather than development, or build time.

This page describes the common files which may be present in any Moodle subsystem or plugin type. Some of these files are mandatory and must exist within a component, whilst others are optional.

Moodle provides a series of Core APIs which can be used by any part of Moodle.

In this page you'll access to the available functions under Moodle to be able to handle DB structures (tables, fields, indexes...).

This page describes the functions available to access data in the Moodle database. You should exclusively use these functions in order to retrieve or modify database content because these functions provide a high level of abstraction and guarantee that your database manipulation will work against different RDBMSes.

A number of native drivers are included with Moodle, including those with support for:

The DML API uses a selection of exceptions to indicate errors.

Moodle has a full-featured Web Service framework, allowing you to use and create web services for use in external systems.

Overview

File converters are an important tool to support other plugins with file conversion supported between a wide range of file formats. File converters are accessed using the File conversion API and are typically consumed by other plugins rather than by the user directly.

Users are able to submit a wide range of files, and it is a common requirement to convert these to alternative formats.

Moodle's Form API is an extension of the Pear HTMLQuickForm API, which is no longer supported. Some documentation for the upstream library is available in the PEAR package page, including a short tutorial. A longer tutorial is also available, courtesy of the Internet Archive.

Form are created using the Form API. The Form API supports most standard HTML elements, including checkboxes, radio buttons, text boxes, and so on, adding additional accessibility and security features to them.

Before they can be used, all functions must be declared to Moodle, and their inputs and outputs must be defined.

An External function definition is the class, and collection of functions, used to define:

Moodle Groups are a way of expressing collections of users within a course. They may be defined by the teacher in the course participants page, or created automatically during a bulk user upload (for example, from a text file).

This page describes the Hooks API which is a replacement for some of the lib.php based one-to-many

Moodle has a class called HTML writer which allows you to output basic HTML tags. This is typically used within renderer functions, for example question/type/pluginname/renderer.php.

Locking is required whenever you need to prevent two, or more, processes accessing the same resource at the same time. The prime candidate for locking in Moodle is cron. Locking allows multiple cron processes to work on different parts of cron at the same time with no risk that they will conflict (work on the same job at the same time).

Machine learning backends process the datasets generated from the indicators and targets calculated by the Analytics API. They are used for machine learning training, prediction and models evaluation.

What is this document?

Summary

The Navigation API allows for the manipulation of the navigation system used in Moodle.

The Output API is responsible for visual aspects of Moodle content. This page explains how renderers, renderables, themes and templates all work together.

Overview

Moodle is a powerful, and very extensible, Learning Management System. One of its core tenets is its extensibility, and this is primarily achieved through the development of plugins.

The Upgrade API is a core API which allows your plugin to manage features of its own installation, and upgrade. Every plugin includes a version which allows the Upgrade API to apply only the required changes.

The Preference API is used for the storage and retrieval of user preferences. These preferences are stored in the database for users with an account, however for guests or users who are not currently logged in the preferences are stored in the Session.

The General Data Protection Regulation (GDPR) is an EU directive that provides users with more control over their data and how it is processed. This regulation came into effect on 25th of May 2018 and covers any citizen or permanent resident of the European Union. The directive is respected by a number of other countries outside of the European Union.

The question subsystem in Moodle manages the creation, editing and management of interactive questions, and then enables those questions to be presented to users so they can be attempted. It is useful to consider these as separate subcomponents.

The Restore API provides a way to restore your plugin's data from a backup file created in Moodle 2.0 or later. For the information on how backup files are created, see Backup API. For the information on how to support restoring data from backup files created in Moodle 1.x, see Backup conversion API.

Scheduled tasks are tasks that will run on a regular schedule. A default schedule can be set, but administrators have the ability to change the default schedule if required.

Before operating on any data in an external function, you must ensure that the user:

Moodle comes with two built-in services that your functions can be attached to.

The Tag API allows you to assign labels to information in Moodle. This makes finding this information easier and also facilitates the grouping of similar information. The Tag API allows you to create, modify, delete and search tags in the Moodle system. The main tag related functions can be found in the tag/classes/tag.php file. For a thorough overview of all of the functions available for working with Tags please see methods in coretagtag, coretagcollection and coretagarea classes, however, the following examples should give you a general understanding of how to get started with tags.

A description of the library tag.php file, describing what plugins have tags where their callbacks are located.

The Moodle Tasks API is a comprehensive API to support the scheduling and running of tasks. Tasks are individual activities which are to be performed, and come in two primary forms:

Internally Moodle always stores all times in unixtime format (number of seconds since epoch) which is independent of timezones.

Moodle allows data manipulation to take place within a database transaction, known as a Delegated transaction. This allows you to perform CRUD operations, and roll them back if a failure takes place.

Unit tests are the best way of checking the behaviour of your external services and can help you to:

Overview