Callbacks

Moodle does not have well-defined Hooks API but still allows plugins to hook into different processes by implementing callbacks.

Some old APIs that were created before object-oriented programming use only callbacks. One of them is [Activity modules].

Types of callbacks in Moodle

Callback functions one-to-many

Core or specific plugin has a "hook point" where it allows plugins to execute some code, modify variables or return a result. Sometimes only plugins of a specific plugin type are allowed. If plugins want to implement the function for this callback they normally must place it in lib.php with the name pluginfullname_callbackname(). Here pluginname should be a full plugin name with a prefix, however activity modules can often omit the "mod_" prefix for historical reasons. Implementing this type of callback is optional and the "hook point" does not care how many and which plugins implement callback. Also "hook point" does not check if the plugin is enabled on this site, inside the calback plugins must check it themselves if it is important. Methods get_plugin_list_with_function() and get_plugins_with_function() are normally used in the "hook points" to find all plugins implementing a callback.

This document aims to cover ALL callbacks of this type that are present in Moodle core APIs or in standard Moodle plugins.

Callback functions one-to-one

Core API (or plugins such as blocks or reports) looks for and executes a method from the plugin/component that "owns" some entity, usually for checking permissions, pre-processing or providing the human-readable representation of this entity. Similar to one-to-many callbacks, the component/plugin must define a function with the name pluginfullname_callbackname() in lib.php . In some cases the function must be present or otherwise an exception is thrown or debugging message is displayed. Methods component_callback() and component_callback_exists() are normally used to find an implementation of a callback. Unlike one-to-many callbacks the implementing functions can exist not only in plugins but also in core components.

Files in the specific location

Core APIs may look for plugins that have a file with a specific file name, for example version.php, settings.php, styles.css, module.js, files in db/ folder, etc. In some situations core reads all files with a specific name at once, for example, when theme cache is being built, all styles.css and styles_themename.css files are read, merged together and placed in cache. In some situations files are processed one by one, for example during plugin installation or upgrade files in db/ folder are processed.

Other

• Event observers. Each plugin can implement event observers that execute code when event is triggered. See [Event_2#Event_dispatching_and_observers|Events API] about how to listen to events. Event observers can not always substitute callbacks because they do not return any value and can only happen in case of event. Many "hook points" are necessary before something has happened or when nothing is happening at all, for example a report/summary is gathered. However if it is possible to achieve the desired outcome with event observer, Moodle will not accept requests for adding a "hook point".
• Callbacks that are specified in the db/* file, for example in db/service.php developers must specify callback responsible for implementing web service, in db/tags.php developers specify callback for finding tagged items, etc. These types of callbacks are not covered on this page, information about them can be found in the respective APIs.

List of Moodle callbacks

List of one-to-many callbacks

Callback	Plugin type	Version	Comments
Navigation, see Navigation API
extend_navigation_course	any	3.0+	before Moodle 3.0 was only supported by report and tool plugin types
extend_settings_navigation	local, booktool		Note, modules have a one-to-one callback with the same name, see below
extend_navigation	local		Note, modules have a one-to-one callback with the same name, see below
extend_navigation_user_settings	any	3.0+	before Moodle 3.0 was only supported by tool plugin types
extend_navigation_category_settings	any	3.0+
extend_navigation_frontpage	any	3.1+
extend_navigation_user	any	3.1+
Deprecated
print_overview	mod	up to 3.2	Used in block_course_overview on the dashboard. Deprecated in 3.3 and will be removed in 3.7

Notes:

if Moodle version is not specified, this means that callback existed for a long time and can be found in all currently supported Moodle versions