customscripts: Difference between revisions
From MoodleDocs
(spelling fix) |
(Typos and updating links) |
||
| Line 1: | Line 1: | ||
==Custom Scripts Mechanism== | ==Custom Scripts Mechanism== | ||
Any scripts that are called directly via a url (eg index.php, user/view.php) | Any scripts that are called directly via a url (eg index.php, user/view.php) can now be customised | ||
by placing a file with the same name (including directories) in my_moodle_data_dir/customscripts | |||
For example: | For example: | ||
my_moodle_data_dir/customscripts/index.php; my_moodle_data_dir/customscripts/user/view.php | my_moodle_data_dir/customscripts/index.php; my_moodle_data_dir/customscripts/user/view.php | ||
| Line 10: | Line 9: | ||
** need to check relative links ; for example: never require ../config.php | ** need to check relative links ; for example: never require ../config.php | ||
** cannot add new files to customscripts folder because they are not accessible directly via web. | ** cannot add new files to customscripts folder because they are not accessible directly via web. | ||
** better to use cvs or cogito for long term management of customisations to | ** better to use cvs or cogito for long term management of customisations to Moodle code | ||
* it seems to have been used extensively only by the [[ | * it seems to have been used extensively only by the [[Moodle 2 for mobile|Moodle for Mobiles]] project | ||
* to enable Custom Scripts, add $CFG->customscripts=path/to/customscript/folder (see [[Configuration_file]]) | * to enable Custom Scripts, add $CFG->customscripts=path/to/customscript/folder (see [[:en:Configuration_file|Configuration file]]) | ||
==Things to keep in mind when using customscripts== | ==Things to keep in mind when using customscripts== | ||
| Line 20: | Line 19: | ||
* customscripts hook the derivated script from the near end of the setup.php script. This means that the config.php file has already been included by the caller and should | * customscripts hook the derivated script from the near end of the setup.php script. This means that the config.php file has already been included by the caller and should | ||
not be called again. | not be called again. | ||
* You cannot override an internal script (MOODLE_INTERNAL) of | * You cannot override an internal script (MOODLE_INTERNAL) of Moodle, you can only customscript an 'entry' page. If the change you need is deeper in an internal library, you need to override the entry page, and probably all the required path from the entry point down to the function you want to change the behaviour. | ||
* The original script might have pre-required some | * The original script might have pre-required some libraries, or defined some early function or defines that are active before the hooks is invoked, such definitions should not be required or defined again in the customscript. | ||
* When a customscript | * When a customscript returns, it gives control back to the setup.php script that will continue executing the original php page.Thus if a customscript replaces the original script, it should end with an exit statement. | ||
exit statement. | |||
==Caveat of customscripting== | ==Caveat of customscripting== | ||
Customscripting is efficient to locally hack a behaviour that is not easy to override using class factories provided by the core architecture or renderer overloading, but your site will run using a | Customscripting is efficient to locally hack a behaviour that is not easy to override using class factories provided by the core architecture or renderer overloading, but your site will run using a | ||
copy of the core code that WILL NOT integrate the code updates when you upgrade Moodle to a higher version. So customscripting might be your last choice to get a feature change in | copy of the core code that WILL NOT integrate the code updates when you upgrade Moodle to a higher version. So customscripting might be your last choice to get a feature change in Moodle after all | ||
other techniques have been examinated : | other techniques have been examinated : | ||
Revision as of 09:56, 13 March 2019
Custom Scripts Mechanism
Any scripts that are called directly via a url (eg index.php, user/view.php) can now be customised by placing a file with the same name (including directories) in my_moodle_data_dir/customscripts For example: my_moodle_data_dir/customscripts/index.php; my_moodle_data_dir/customscripts/user/view.php
- this is for people making short term changes to VISIBLE web pages in the moodle source code
- need to check relative links ; for example: never require ../config.php
- cannot add new files to customscripts folder because they are not accessible directly via web.
- better to use cvs or cogito for long term management of customisations to Moodle code
- it seems to have been used extensively only by the Moodle for Mobiles project
- to enable Custom Scripts, add $CFG->customscripts=path/to/customscript/folder (see Configuration file)
Things to keep in mind when using customscripts
- customscripts hook the derivated script from the near end of the setup.php script. This means that the config.php file has already been included by the caller and should
not be called again.
- You cannot override an internal script (MOODLE_INTERNAL) of Moodle, you can only customscript an 'entry' page. If the change you need is deeper in an internal library, you need to override the entry page, and probably all the required path from the entry point down to the function you want to change the behaviour.
- The original script might have pre-required some libraries, or defined some early function or defines that are active before the hooks is invoked, such definitions should not be required or defined again in the customscript.
- When a customscript returns, it gives control back to the setup.php script that will continue executing the original php page.Thus if a customscript replaces the original script, it should end with an exit statement.
Caveat of customscripting
Customscripting is efficient to locally hack a behaviour that is not easy to override using class factories provided by the core architecture or renderer overloading, but your site will run using a copy of the core code that WILL NOT integrate the code updates when you upgrade Moodle to a higher version. So customscripting might be your last choice to get a feature change in Moodle after all other techniques have been examinated :
- relocate the feature in a plugin
- override core code with proposed factories and overloading mechanisms
- finding a way to get the feature in another way (using other plugins, other method)
