MDL-17376 more plugin info
[moodle.git] / local / readme.txt
1 // This file is part of Moodle - http://moodle.org/
2 //
3 // Moodle is free software: you can redistribute it and/or modify
4 // it under the terms of the GNU General Public License as published by
5 // the Free Software Foundation, either version 3 of the License, or
6 // (at your option) any later version.
7 //
8 // Moodle is distributed in the hope that it will be useful,
9 // but WITHOUT ANY WARRANTY; without even the implied warranty of
10 // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
11 // GNU General Public License for more details.
12 //
13 // You should have received a copy of the GNU General Public License
14 // along with Moodle.  If not, see <http://www.gnu.org/licenses/>.
16 /**
17  * Readme file for local customisations
18  *
19  * @package    local
20  * @copyright  2009 Petr Skoda (http://skodak.org)
21  * @license    http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later
22  */
24 Local customisations directory
25 ==============================
26 This directory is the recommended place for local customisations.
27 Wherever possible, customisations should be written using one
28 of the standard plug-in points like modules, blocks, auth plugins, themes, etc.
30 See also http://docs.moodle.org/en/Development:Local_customisation for more
31 information.
34 Directory structure
35 -------------------
36 This directory has standard plugin structure. All standard plugin features
37 are supported. There may be some extra files with special meaning in /local/.
39 Sample /local/ directory listing:
40 /local/nicehack/         - first customisation plugin
41 /local/otherhack/        - other customisation plugin
42 /local/upgrade_pre20.php - one time upgrade and migration script which is
43                            executed before main 2.0 upgrade starts
44 /local/defaults.php      - custom admin setting defaults
48 Local plugins
49 =============
50 Local plugins are used in cases when no standard plugin fits, examples are:
51 * event consumers communicating with external systems
52 * custom definitions of web services and external functions
53 * applications that extend moodle at the system level (hub server, amos server, etc.)
54 * new database tables used in core hacks (discouraged)
55 * new capability definitions used in core hacks
56 * custom admin settings
58 Standard plugin features:
59 * /local/xxx/db/version.php - version of script (must be incremented after changes)
60 * /local/xxx/db/install.xml - executed during install (new version.php found)
61 * /local/xxx/db/install.php - executed right after install.xml
62 * /local/xxx/db/uninstall.php - executed during uninstallation
63 * /local/xxx/db/upgrade.php - executed after version.php change
64 * /local/xxx/db/access.php - definition of capabilities
65 * /local/xxx/db/events.php - event handlers and subscripts
66 * /local/xxx/db/messages.php - messaging registration
67 * /local/xxx/db/external.php - web services and external functions descriptions
68 * /local/xxx/lang/en/local_pluginname.php - language file
71 Local plugin version specification
72 ----------------------------------
73 version.php is mandatory for most of the standard plugin infrastructure.
74 The version number must be incremented most plugin changes, the changed
75 version tells Moodle to invalidate all caches, do db upgrades if necessary,
76 install new capabilities, register event handlers, etc.
78 Example:
79 /local/nicehack/version.php
80 <?php
81 $plugin->version  = 2010022400;   // The (date) version of this plugin
82 $plugin->requires = 2010021900;   // Requires this Moodle version
85 Local plugin capabilities
86 -------------------------
87 Each local plugin may define own capabilities. It is not recommended to define
88 capabilities belonging to other plugins here, but it should work too.
90 /local/nicehack/access.php content
91 <?php
92 $local_nicehack_capabilities = array(
93     'local/nicehack:nicecapability' => array(
94         'captype' => 'read',
95         'contextlevel' => CONTEXT_SYSTEM,
96     ),
97 );
100 Local plugin language strings
101 -----------------------------
102 If customisation needs new strings it is recommended to use normal plugin
103 strings.
105 sample language file /local/nicehack/lang/en/local_nicehack.php
106 <?php
107 $string['hello'] = 'Hi {$a}';
108 $string['nicehack:nicecapability'] = 'Some capability';
111 use of the new string in code:
112 echo get_string('hello', 'local_nicehack', 'petr');
115 Local plugin admin menu items
116 -----------------------------
117 It is possible to add new items and categories to the admin_tree block.
118 I you need to define new admin setting classes put them into separate
119 file and require_once() from settings.php
121 For example if you want to add new external page use following
122 /local/nicehack/settings.php
123 <?php
124 $ADMIN->add('root', new admin_category('tweaks', 'Custom tweaks'));
125 $ADMIN->add('tweaks', new admin_externalpage('nicehackery', 'Tweak something',
126             $CFG->wwwroot.'/local/nicehack/setuppage.php'));
129 Local plugin event handlers
130 ---------------------------
131 Events are intended primarily for communication "core --> plugins".
132 (It should not be use in opposite direction!)
133 In theory it could be also used for "plugin --> plugin" communication too.
134 The list of core events is documented in lib/db/events.php
136 sample files
137 /local/nicehack/db/events.php
138 $handlers = array (
139     'user_deleted' => array (
140          'handlerfile'      => '/local/nicehack/lib.php',
141          'handlerfunction'  => 'nicehack_userdeleted_handler',
142          'schedule'         => 'instant'
143      ),
144 );
146 NOTE: events are not yet fully implemented in current Moodle 2.0dev.
149 Local plugin database tables
150 ----------------------------
151 XMLDB editors is the recommended tool. Please note that modification
152 of core table structure is highly discouraged.
154 If you really really really need to modify core tables you might want to do
155 that in install.php and later upgrade.php
157 Note: it is forbidden to manually modify the DB structure, without corresponding
158       changes in install.xml files.
160 List of upgrade related files:
161 /local/nicehack/db/install.xml - contains XML definition of new tables
162 /local/nicehack/db/install.php - executed after db creation, may be also used
163                                  for general install code
164 /local/nicehack/db/upgrade.php - executed when version changes
168 Other local customisation files
169 ===============================
171 Customised site defaults
172 ------------------------
173 Different default site settings can be stored in file /local/defaults.php.
174 These new defaults are used during installation, upgrade and later are
175 displayed as default values in admin settings. This means that the content
176 of the defaults files is usually updated BEFORE installation or upgrade.
178 These customised defaults are useful especially when using CLI tools
179 for installation and upgrade.
181 Sample /local/defaults.php file content:
182 <?php
183 $defaults['moodle']['forcelogin'] = 1;  // new default for $CFG->forcelogin
184 $defaults['scorm']['maxgrade'] = 20;    // default for get_config('scorm', 'maxgrade')
185 $defaults['moodlecourse']['numsections'] = 11;
186 $defaults['moodle']['hiddenuserfields'] = array('city', 'country');
188 First bracket contains string from column plugin of config_plugins table.
189 Second bracket is the name of setting. In the admin settings UI the plugin and
190 name of setting is separated by "|".
192 The values usually correspond to the raw string in config table, with the exception
193 of comma separated lists that are usually entered as real arrays.
195 Please note that not all settings are converted to admin_tree,
196 they are mostly intended to be set directly in config.php.
199 2.0 pre-upgrade script
200 ----------------------
201 You an use /local/upgrade_pre20.php script for any code that needs to
202 be executed before the main upgrade to 2.0. Most probably this will
203 be used for undoing of old hacks that would otherwise break normal
204 2.0 upgrade.
206 This file is just included directly, there does not need to be any
207 function inside. If the execution stops the script is executed again
208 during the next upgrade. The first execution of lib/db/upgrade.php
209 increments the version number and the pre upgrade script is not
210 executed any more.
214 1.9.x upgrade notes
215 ===================
216 1.9.x contains basic support for local hacks placed directly into
217 /local/ directory. This old local API was completely removed and can
218 not be used any more in 2.0. All old customisations need to be
219 migrated to new local plugins before running of the 2.0 upgrade script.
223 Other site customisation outside of "/local/" directory
224 =======================================================
226 Local language pack modifications
227 ---------------------------------
228 Moodle supports other type of local customisation of standard language
229 packs. If you want to create your own language pack based on another
230 language create new dataroot directory with "_local" suffix, for example
231 following file with content changes string "Login" to "Sign in":
232 moodledata/lang/en_local
233 <?php
234   $string['login'] = 'Sign in';
236 See also http://docs.moodle.org/en/Language_editing
239 Custom script injection
240 -----------------------
241 Very old customisation option that allows you to modify scripts by injecting
242 code right after the require 'config.php' call.
244 This setting is enabled by manually setting $CFG->customscripts variable
245 in config.php script. The value is expected to be full path to directory
246 with the same structure as dirroot. Please note this hack only affects
247 files that actually include the config.php!
249 Examples:
250 * disable one specific moodle page without code modification
251 * alter page parameters on the fly