Documentation Moodle ActiveProLearn

Outils pour utilisateurs

Outils du site

Vous êtes ici : Hi ! Welcome on this documentation volume intended to provide moodle community with english documentation version of the most populars plugins developed and maintained by APL » Hi ! Welcome on this documentation volume intended to provide moodle community with english documentation version of the most populars plugins developed and maintained by APL » Overriding core limitations : how to handle it the right way
Piste :
start:overrides

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
start:overrides [2026/02/08 19:20] – [Core patchs] adminstart:overrides [2026/02/08 21:23] (Version actuelle) – [Customcripts] admin
Ligne 16: Ligne 16:
  
 <html><center style="font-size:170%">$Imp = \frac{Nop * Xop * Of}{Aut}$</center></html> <html><center style="font-size:170%">$Imp = \frac{Nop * Xop * Of}{Aut}$</center></html>
 +
 +The impact unit should be not far from some Energy measurement.
    
 It can be modelized roughly as a function of increasing factors: Number of maintenance operations - Nop, complexitxy of operations - Xop, and probably an organisational factor that increases when both number and complexity grows. Organisational factor can include f.e. an increasing of the number of actors in the operations and the loss in coordination. It can be modelized roughly as a function of increasing factors: Number of maintenance operations - Nop, complexitxy of operations - Xop, and probably an organisational factor that increases when both number and complexity grows. Organisational factor can include f.e. an increasing of the number of actors in the operations and the loss in coordination.
Ligne 27: Ligne 29:
  
 ====Customcripts==== ====Customcripts====
 +
 +Customscripts are a "soft" way to get over the moodle core limitations. Customscripting is a standard mechanism to get core code replaced by a customized version, WITHOUT interfering with core code from the official Git or distribution.
 +
 +By defining a directory (often ''/customscripts'') at moodle code's root (or outside) and adding a key:
 +
 +   $CFG->customscripts = '<moodlepath>/customscripts';
 +
 +In your config file, then any request to a php script say: ''https:<nowiki>//</nowiki><mymoodle>/a/b/c.php'' that encounters an existing file named ''/customscripts/a/b/c.php'' will be derouted at end of the ''setup.php'' initialisation to that file, includes the file, then continue normal processing.
 +
 +Customscripts MUST NOT include ''config.php'', because it has already be done before routing to customscript.
 +
 +By ending the customscript by a ''die()'' or ''exit()'', the customscripted script REPLACES the standard behaviour.
 +
 +Customscripts MUST NOT redefine classes, functions or any "compilation time definitions", as the standard version has already be loaded into memory.
 +
 +===Good cases===
 +
 +Customscripts work fine when the change is very superficial, and resides in the moodle page itself (vs. a deeper library).
 +
 +===Less good cases===
 +
 +When the change is deeper, customscripting will force you to deroute deeper calls to derouted APIs, so the code path may need a lot of work to reach the changing point.  
 +
 +Too complicated derouting will lead to replacing a LOT of standard code. As the standard code is occulted in your Moodle, it will not reveal upgrades or bugfixes, so your replaced code will diverge slowly from moodle standard state of the art. this can be problematic.
  
 ====Core patchs==== ====Core patchs====
start/overrides.1770578419.txt.gz · Dernière modification : de admin
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki