Development:Local customisation: Difference between revisions
Penny Leach (talk | contribs) No edit summary |
Penny Leach (talk | contribs) |
||
Line 14: | Line 14: | ||
=== Local database changes and version === | === Local database changes and version === | ||
If you need to make local database customisations that are not easily encapsulated by a block or module, Moodle does support the use of a local db upgrade script, and local version number. | |||
This is almost exactly the same as every other db/upgrade.php and version.php except for the following points: | |||
==== local/version.php ==== | |||
local/version.php must look like: | |||
<code php> | |||
$local_version = 2008121700; | |||
</code> | |||
==== local/db/install.xml ==== | |||
Local/ has no install.xml - only an upgrade.php. This is because often the changes that you want to make are not full tables, but just extra columns, and a local install.xml makes less sense than just upgrade.php. | |||
==== local/db/upgrade.php ==== | |||
local/db/upgrade.php must look like: | |||
<code php> | |||
function xmldb_local_upgrade($oldversion) { | |||
global $CFG, $db; | |||
$result = true; | |||
if ($result && $result < 2008121700) { | |||
$result = $result && create_table($table); | |||
} | |||
return $result; | |||
} | |||
</code> | |||
=== Local post-installation data insertion === | === Local post-installation data insertion === |
Revision as of 16:46, 17 December 2008
General customisations
Moodle has been designed with extensibility in mind. There are many plug-in points available though out Moodle to allow developers add new functionality to Moodle without modifying core code.
See the make a new plugin section of the Developer documentation page for the different plugin types available, and documentation on how to develop for them.
local/ folder for 'hacky' customisations
Sometimes it is not possible to use the available plug-in points to make your change. In situations like this then the local folder is for you. The idea is that instead of scattering your changes throughout the code base, you put them all in a folder called 'local'. Using this folder means you won't have to deal with merging problems when you upgrade the rest of your Moodle installation.
The local folder has some of the plug-in points available which are available to other modules. Perhaps most useful the local/db/ folder can be used to make database schema changes and custom role permissions.
However, using the local folder should be absolutely the last resort. Long term, you will almost certainly find it easier to maintain your changes if you can package them up as one of the standard types of plugins.
Local database changes and version
If you need to make local database customisations that are not easily encapsulated by a block or module, Moodle does support the use of a local db upgrade script, and local version number.
This is almost exactly the same as every other db/upgrade.php and version.php except for the following points:
local/version.php
local/version.php must look like:
$local_version = 2008121700;
local/db/install.xml
Local/ has no install.xml - only an upgrade.php. This is because often the changes that you want to make are not full tables, but just extra columns, and a local install.xml makes less sense than just upgrade.php.
local/db/upgrade.php
local/db/upgrade.php must look like:
function xmldb_local_upgrade($oldversion) {
global $CFG, $db;
$result = true;
if ($result && $result < 2008121700) {
$result = $result && create_table($table);
}
return $result;
}
Local post-installation data insertion
Local capabilities
Local event subscriptions
Local backup and restore hooks
Local course deletion hook
Local my moodle overrides
Local stickyblocks targets
Local user profile view hook
Local language strings
See also
- CVS:moodle/lib/locallib.php
- Using Moodle Local Customisations forum discussion