Revision as of 18:28, 19 May 2010

Local customisations
Project state	In progress
Tracker issue	MDL-17376, MDL-16438
Discussion	http://moodle.org/mod/forum/discuss.php?d=126017
Assignee	Petr Škoda (škoďák), original proposal and implementation in 1.9 by Penny Leach

Moodle 2.0

/local/ plugins

Standard plugin features:

db/version.php - version of script (must be incremented after changes)
db/install.xml - executed during install (new version.php found)
db/install.php - executed right after install.xml
db/upgrade.php - executed after version.php change
db/access.php - definition of capabilities
db/events.php - event handlers and subscripts
db/messages.php - messaging registration
db/external.php - web services and external functions descriptions
lang/en/local_pluginname.php - language file
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 get_plugin_types()
are expected to use event handlers - events are intended for communication core-->plugins only, local plugins the best candidates for event handlers
can add admin settings to any page - loaded last when constructing admin tree
do not need to have any UI - all other plugins are visible somewhere
some extra hooks (not implemented yet)

Migration from old local/*:

local/* needs to be copied to new directory
local/xxxx/db/install.php is 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

Other /local/ customisation files

Customised site defaults

2.0 pre-upgrade script

Customisations outside of /local/ directory

Forced settings

Local language customisations

Custom script injection

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()

@@ Line 10: / Line 10: @@
 =/local/ plugins=
-Benefits compared to previous 1.9:
+Standard plugin features:
-* local plugins are less hacky
+* db/version.php - version of script (must be incremented after changes)
-* no cost of ''local'' maintenance in core - it is just another general plugin
+* db/install.xml - executed during install (new version.php found)
-* easier to implement
+* db/install.php - executed right after install.xml
-* concurrent plugin modifications possible, not just one huge local hack
+* db/upgrade.php - executed after version.php change
+* db/access.php - definition of capabilities
+* db/events.php - event handlers and subscripts
+* db/messages.php - messaging registration
+* db/external.php - web services and external functions descriptions
+* lang/en/local_pluginname.php - language file
+* plugins of the same type are installed/upgraded in alphabetical order
-Migration from old local/*
-* <code>local/*</code> needs to be copied to new directory
-* <code>local/xxxx/db/install.php</code> is 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
 List of differences from normal plugins:
 * always executed last during install/upgrade - guaranteed by order of plugins in <code>get_plugin_types()</code>
-* are expected to use event handlers - event are intended for communication core-->plugins only, local plugins the best candidates for event handlers
+* are expected to use event handlers - events are intended for communication core-->plugins only, local plugins the best candidates for event handlers
 * can add admin settings to any page - loaded last when constructing admin tree
-* in exceptional cases modify other db tables - not supported officially, do it at your own risk only
 * do not need to have any UI - all other plugins are visible somewhere
-* Local user profile view hook (not part of  MDL-16438)
+* some extra hooks (not implemented yet)
-* ''My Moodle'' hooks (not part of  MDL-16438)
-List of normal plugin features:
+Migration from old local/*:
-* db/version.php - version of script
+* <code>local/*</code> needs to be copied to new directory
-* db/install.xml - executed during install (new version.php found)
+* <code>local/xxxx/db/install.php</code> is intended for first installation, originally everything was in upgrade.php
-* db/install.php - executed right after install.xml
+* events are used instead of hooks
-* db/upgrade.php - executed after version.php change
+* 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
-* db/access.php - capabilities
-* db/events.php - event handlers
-* db/messages.php - messaging info
-* db/external.php - web services api, not finished yet
-* lang/en/local_pluginname.php - localization string files
-* plugins of the same type are installed/upgraded in alphabetical order
 =Other /local/ customisation files=

Documentation

Local plugins: Difference between revisions