Revision as of 09:09, 4 November 2011 by Michael de Raadt (talk | contribs) (Adding to a top level category)

Jump to: navigation, search

Sub plugins allow activity modules to be extended without having to change the module's code.

Each activity module can define a set of subplugin types in db/subplugins.php. The file must contain an array called $subplugins, with the plugin type as the key for the directory containing the plugins. For example, from mod/workshop/db/subplugins.php:

$subplugins = array(
    'workshopform'       => 'mod/workshop/form',
    'workshopallocation' => 'mod/workshop/allocation',
    'workshopeval'       => 'mod/workshop/eval',

This defines 3 plugin types, workshopform, workshopallocation, and workshopeval. The plugins themselves can be found in mod/workshop/form, mod/workshop/allocation and mod/workshop/eval, respectively. Each of these directories can contain a number of plugins, each within it's own subdirectory.

Writing a sub-plugin

A lot of the basic structure of a sub-plugin is the same as any other plugin. It can have a version.php, a lang directory, and can have a db directory with install.xml and all the others files can can go in there.

However the details of what APIs the sub-plugin has to provide depends on the type of sub-plugin it is. For example, and quiz report has to follow the rules for quiz reports that the quiz module sets, and a workshop allocation has to follow the rules set by the workshop module. When you create a new type of sub-plugin, you should document the expected API.