If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.


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