Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Plugin files

From MoodleDocs
Revision as of 09:46, 30 April 2015 by David Mudrak (talk | contribs)


There are some files that work the same in all plugin types (if they are present).

version.php

Meta-data about the plugin (like the version number, dependencies or the maturity level) are defined here.

  • version.php page provides detailed description of the file contents

lang/en/plugintype_pluginname.php

English strings for the plugin are defined here. At least $string['pluginname'] must be present. There is an exception for the Activity modules, their expected file name is just pluginname.php (without the mod_ prefix).

  • String API provides information about the string files

lib.php

The interface between the Moodle core and the plugin is defined here for the most plugin types. The expected contents of the file depends on the particular plugin type.

Moodle core often (but not always) loads all the lib.php files of the given plugin types. For the performance reasons, it is strongly recommended to keep this file as small as possible and have just required code implemented in it. All the plugin's internal logic should be implemented in the auto-loaded classes or in the locallib.php file.

db/install.xml

The plugin's database scheme (tables, fields, indexes and keys) are defined here. You should always use the in-built XMLDB editor to generate this file.

db/upgrade.php

Upgrade steps (such as database scheme changes and other things that must happen when the plugin is being upgraded) are defined here. The in-built XMLDB editor can be used to generate the code to change the database scheme.

db/access.php

Plugin capabilities are defined here.

db/install.php

Allows you to execute a PHP code right after the plugin's database scheme has been installed.

db/uninstall.php

Allows you to execute a PHP code before the plugin's database tables and data are dropped during the plugin uninstallation.

db/events.php

Event handlers (subscriptions) are defined here. It lists all the events that your plugin want to observe and be notified about.

db/messages.php

Allow to declare your plugin as the messaging provider.

db/services.php

External functions and web services provided by your plugin are described here.

classes

settings.php

Describes the administration configuration for your plugin.

The setting names are supposed to be plugintype_pluginname/settingname (note the slash) and not plugintype_pluginname_settingname or even just settingname. This makes them to be stored in the config_plugins table without polluting the global $CFG object.

pix/icon.svg

The plugin's icon. Activity modules should provide 24 x 24 px colour icons. All other plugin files should be represented by 16 x 16 px monochrome icon. There should be a fallback pix/icon.png version of the icon for legacy browsers.

thirdpartylibs.xml

The file should list all 3rd party libraries bundled with a plugin.

<?xml version="1.0"?> <libraries>

   <library>
       <location>javascript/html5shiv.js</location>
       <name>Html5Shiv</name>
       <version>3.6.2</version>
       <license>Apache</license>
       <licenseversion>2.0</licenseversion>
   </library>
   <library>
       <location>vendor/guzzle/guzzle/</location>
       <name>guzzle</name>
       <version>v3.9.3</version>
       <license>MIT</license>
       <licenseversion></licenseversion>
   </library>

</libraries>

The location is a path to the library directory or file, relative to the plugin's root directory. Please note that license must be always compatible with the GNU GPLv3.

Locations defined in this file are excluded from the coding style prechecks that are executed during the Plugin validation.


README

The file README.md or README.txt should contain useful information about the plugin. Ideally, it should act as an offline version of all the informations that are available at the plugin's page in the Plugins directory.