customscripts - Revision history

Andrewnicols: Note about plan not to migrate this page to the new developer resources. See template for more info.

2022-06-24T13:48:24Z

Note about plan not to migrate this page to the new developer resources. See template for more info.

← Older revision		Revision as of 13:48, 24 June 2022
Line 1:		Line 1:
			{{Template:WillNotMigrate}}
	==Custom Scripts Mechanism==		==Custom Scripts Mechanism==

Fox: Typos and updating links

2019-03-13T09:56:05Z

Typos and updating links

Cwnz: spelling fix

2016-11-15T15:50:41Z

spelling fix

← Older revision		Revision as of 15:50, 15 November 2016
Line 25:		Line 25:
	exit statement.		exit statement.

	==~~Caveheat~~ 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

Valeryf at 18:33, 4 November 2016

2016-11-04T18:33:32Z

@@ Line 15: / Line 15: @@
 * to enable Custom Scripts, add $CFG->customscripts=path/to/customscript/folder (see [[Configuration_file]])
 ==References==
 * http://moodle.org/mod/forum/discuss.php?d=31895
 * https://tracker.moodle.org/issues/?jql=text%20~%20%22customscripts%22

Rexlorenzo: /* References */

2014-03-04T20:56:04Z

References

← Older revision		Revision as of 20:56, 4 March 2014
Line 18:		Line 18:
	==References==		==References==
	* http://moodle.org/mod/forum/discuss.php?d=31895		* http://moodle.org/mod/forum/discuss.php?d=31895
	* ~~http~~://tracker.moodle.org/~~secure~~/~~QuickSearch.jspa and type "customscripts"~~		* https://tracker.moodle.org/issues/?jql=text%20~%20%22customscripts%22

Daniure at 10:18, 6 July 2011

2011-07-06T10:18:15Z

← Older revision		Revision as of 10:18, 6 July 2011
Line 14:		Line 14:
	* it seems to have been used extensively only by the [[Moodle_for_Mobiles]] project		* it seems to have been used extensively only by the [[Moodle_for_Mobiles]] project

	* to enable Custom Scripts, add $CFG->~~customscript~~=path/to/customscript/folder (see [[Configuration_file]])		* to enable Custom Scripts, add $CFG->customscripts=path/to/customscript/folder (see [[Configuration_file]])

	==References==		==References==
	* http://moodle.org/mod/forum/discuss.php?d=31895		* http://moodle.org/mod/forum/discuss.php?d=31895
	* http://tracker.moodle.org/secure/QuickSearch.jspa and type "customscripts"		* http://tracker.moodle.org/secure/QuickSearch.jspa and type "customscripts"

Deraadt: Created page with "==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 (includin..."

2011-06-22T05:55:07Z

Created page with "==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 (includin..."

New page

==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->customscript=path/to/customscript/folder (see [[Configuration_file]])

==References==
* http://moodle.org/mod/forum/discuss.php?d=31895
* http://tracker.moodle.org/secure/QuickSearch.jspa and type "customscripts"

← Older revision		Revision as of 09:56, 13 March 2019
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
	can now be customised by placing a file with the same name (including directories) in		by placing a file with the same name (including directories) in my_moodle_data_dir/customscripts
	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 ~~moodle~~ code		** 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		* 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 ~~moodle~~, you can only customscript an 'entry' page. If the ~~chage~~ 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.		* 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 ~~libraires~~, 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.		* 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 ~~retiurns~~, 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		* 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 ~~moodle~~ after all		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 :