customscripts
From MoodleDocs
| Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable. |
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)
