|Tracker issue||MDL-17376, MDL-16438|
|Assignee||Petr Škoda (škoďák), some parts were originally proposed and implemented in 1.9 by Penny Leach|
The recommended way to add new functionality to Moodle is to create a new standard plugin (module, block, auth, enrol, etc.).The /local/ plugins are mostly suitable for things that do not fit standard plugins.
- 1 Custom /local/ plugins
- 2 /local/xxx/db/messages.php
- 3 Other /local/ customisation files
- 4 Customisations outside of /local/ directory
- 5 Local customisations in previous versions
- 6 See also
Custom /local/ plugins
Local plugins are used in cases when no standard plugin fits, examples are:
- event consumers communicating with external systems
- custom definitions of web services and external functions
- applications that extend moodle at the system level (hub server, amos server, etc.)
- new database tables used in core hacks (discouraged)
- new capability definitions used in core hacks
- custom admin settings
- extending the navigation block with custom menus 
Standard plugin features:
- /local/xxx/version.php - version of script (must be incremented after changes)
- /local/xxx/db/install.xml - executed during install (new version.php found)
- /local/xxx/db/install.php - executed right after install.xml
- /local/xxx/db/uninstall.php - executed during uninstallation
- /local/xxx/db/upgrade.php - executed after version.php change
- /local/xxx/db/access.php - definition of capabilities
- /local/xxx/db/events.php - event handlers and subscripts
- /local/xxx/db/messages.php - messaging registration
- /local/xxx/db/external.php - web services and external functions descriptions
- /local/xxx/lang/en/local_pluginname.php - language file
- /local/xxx/lib.php - function library, automatically included with by config.php
- /local/xxx/cron.php - cron job, run at the interval defined in version.php. Alternatively, you can define local_xxx_cron() in lib.php
The xxx is used instead of your local plugin name, plugins of the same type are installed/upgraded in alphabetical order.
List of differences from normal plugins:
- always executed last during install/upgrade - guaranteed by order of plugins in
- are expected to use event handlers - events are intended for communication core-->plugins only, local plugins are the best candidates for event handlers
- can add admin settings to any settings page - loaded last when constructing admin tree
- do not need to have any UI - other plugins are usually visible somewhere
- some extra hooks (not implemented yet)
Example File Structure:
<?php /** * Defines message providers (types of messages being sent) * * @package mod-forum * @copyright 1999 onwards Martin Dougiamas http://moodle.com * @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later */ $messageproviders = array ( /// Ordinary single forum posts 'posts' => array ( ) );
Other /local/ customisation files
Customised site defaults
Different default site settings can be stored in file /local/defaults.php. These new defaults are used during installation, upgrade and later are displayed as default values in admin settings. This means that the content of the defaults files is usually updated BEFORE installation or upgrade.
These customised defaults are useful especially when using CLI tools for installation and upgrade.
Sample /local/defaults.php file content:
<?php $defaults['moodle']['forcelogin'] = 1; // new default for $CFG->forcelogin $defaults['scorm']['maxgrade'] = 20; // default for get_config('scorm', 'maxgrade') $defaults['moodlecourse']['numsections'] = 11; $defaults['moodle']['hiddenuserfields'] = array('city', 'country');
First bracket contains string from column plugin of config_plugins table. Second bracket is the name of setting. In the admin settings UI the plugin and name of setting is separated by "|".
The values usually correspond to the raw string in config table, with the exception of comma separated lists that are usually entered as real arrays.
Please note that not all settings are converted to admin_tree, they are mostly intended to be set directly in config.php.
2.0 pre-upgrade script
You can use /local/upgrade_pre20.php script for any code that needs to be executed before the main upgrade to 2.0. Most probably this will be used for undoing of old hacks that would otherwise break normal 2.0 upgrade.
This file is just included directly, there does not need to be any function inside. If the execution stops the script is executed again during the next upgrade. The first execution of lib/db/upgrade.php increments the version number and the pre upgrade script is not executed any more.
Customisations outside of /local/ directory
Sometimes it is useful to force some settings and prevent any changes of these settings via the standard admin UI. It is possible to hardcode these settings in config.php.
In case of course settings it is very simply, the values are assigned directly to $CFG properties. In case of plugins the values are specified in a multidimensional array in $CFG->force_plugin_settings.
Sample code in config.php
$CFG->allowobjectembed = 0; $CFG->forced_plugin_settings = array('page'=>array('displayoptions'=>5, 'requiremodintro'=>1), 'folder'=>'requiremodintro'=>1);
Local language customisations
Moodle supports other type of local customisation of standard language packs. If you want to create your own language pack based on another language create new dataroot directory with "_local" suffix, for example following file with content changes string "Login" to "Sign in": moodledata/lang/en_local
<?php $string['login'] = 'Sign in';
Custom script injection
Very old customisation option that allows you to modify scripts by injecting code right after the require 'config.php' call.
This setting is enabled by manually setting $CFG->customscripts variable in config.php script. The value is expected to be full path to directory with the same structure as dirroot. Please note this hack only affects files that actually include the config.php!
- disable one specific moodle page without code modification
- alter page parameters on the fly
Direct code modifications
This is usually the last resort, if possible do not do it. And if you still do it use some version control system (preferably git).
Direct database modifications
Very strongly discouraged! Sometimes field lengths may be modified without side effects. Adding or removing of db fields will most probably cause major problems during future upgrades. New database tables should be added only from plugins.
Local customisations in previous versions
Previous versions include only partial support for customisations in /local/ directory.
List of local customisations in 1.9.x:
- /local/cron.php - custom cron jobs
- /local/settings.php - custom admin settings
- /local/db/upgrade.php - general modifications
- /local/lang/* - custom strings
- /local/lib.php - local_delete_course()
Migration from old 1.9.x /local/:
local/*needs to be copied to new directory
local/xxxx/db/install.phpis intended for first installation, originally everything was in upgrade.php
- events are used instead of hooks
- upgrade code needs to migrate old settings, events, etc. directly in core db tables - such as change component strings and capability names from db/install.php or manually before/after upgrade