Plugin validation

Before a plugin can be made available via the Modules and plugins database it has to pass both an automatic and a manual validation process. The automatic checks are repeated for each new version of the plugin that is added, however the manual checks are only done for the initial release.

Automatic validation

General rules for all plugin types

• Plugin name with frankenstyle prefix must be unique in moodle.org/plugins. If there is another plugin with the same name you must either add new versions to this plugin (if it is yours) or rename your plugin if the names are accidentally the same. First in first served.
• The plugin must be uploaded as a single zip file
• The zip file must contain a single subfolder, named after your plugin (although the validator can also automatically rename subfolders generated by repos such as GitHub, which appear in the form 'username-moodle-pluginname-branchname')
• The subfolder must be laid out in such a way that the uploaded file could be unzipped directly into the top-level folder for that plugin type (e.g. an activity plugin called 'myplugin' should install correctly when unzipped in the Moodle /mod folder, creating a subfolder /mod/myplugin with all the standard files within it).
• The subfolder must contain a file called version.php (follow the link for more details about what should be contained within that file). See exceptions below.
• Language file must be present in lang/en/FULLNAME.php (for Moodle 2.0+) or lang/en_utf8/FULLNAME.php (for Moodle 1.9). FULLNAME is the plugin name with frankenstyle prefix. See exceptions below.
• Language file must declare either $string['modulename'] (for activity modules) or $string['filtername'] (for Filters) or $string['pluginname'] (for all other plugin types). Same exceptions as for language file presence.
• The names of all database tables should start with the full 'frankenstyle' plugin name. For example block_myblock, or auth_paypal. See exceptions below.
• (Recommended) the subfolder should contain a file called README.txt (the validator can automatically rename other extensions to .txt) with details about the current release of the plugin.

Exceptions

• version.php is NOT required (but it is always recommended) for the following plugin types:
  • Themes
  • Course formats
  • Blocks for Moodle 1.9
  • Auth for Moodle 1.9
• language file is not required for plugins for Moodle 1.9 that are not activity modules
• database tables are allowed to skip mod_ prefix for activity modules
• database tables are allowed to have question_ prefix instead of qtype_ for Question types. This is for historical reasons, all newly developed plugins are encouraged to have qtype_ prefix.

Additional checks for activity modules

• $module->version defined in version.php
• $module->requires defined in version.php
• file lib.php exists
• file lib.php contains “function xxxx_add_instance”
• file lib.php contains “function xxxx_update_instance”
• file view.php exists
• file index.php exists
• db/install.xml exists
• db/upgrade.php exists
• db/access.php exists

Checks for particular plugin types

• Themes: file config.php exists
• Blocks: file block_xxxx.php exists
• Auth: file auth.php exists
• Course formats: file format.php exists

Manual checks

Before the plugin is publicly viewable a trusted reviewer will look through the code to make sure it is a valid plugin. These checks include:

• The plugin installs cleanly
• It does not contain any obviously harmful code
• It is not a spam entry
• It is not a duplicate of an already uploaded plugin

Frequently asked questions

Q: My code contains several components, why can't I distribute it as a single package?

A: Moodle architecture supposes that plugins are installed independently. However you can contact the plugins database moderator and ask to add your plugins to the SET. For Moodle 2.2 and above you can also specify in your version.php that one plugin depends on another.