This helps synchronise time on the client side with time on the server.
If you wait until a js_init_call runs, you might have had to wait an
unknown number of seconds while all the JS loads. Therefore, we capture
the current time as soon as possible in <head>.
This is a bit like adding .jsenabled to <body> as soon as possible, to
reduce visual flicker.
During installation, jsrev is unset so unavailable for the cache checks.
The installation sets the initial jsrev value and this is updated
periodically, unless it is set to -1 for JS developer.
During installation, we shouldn't really use any caches so if jsrev is
unset, then we should act as though it is set to developer.
It was going to cause some continuous logging in the console
annoying developers on 2.5 all the time. It may be reintroduced
once filepickers are converted to proper YUI modules.
A warning is shown in the browser console if debugging is set, but it is
not possible to return from the configFn and stop the module load attempt
from continuing.
The error is caught and an additional error is shown by yui_combo.php
This is a bit of a grey area. This function does not get and return a value
to the caller, and does not set a value taken from the caller. Instead it
gets a value from get_moodle_metadata and adds it to the current instance
of YUI_config. This rename will hopefully improve clarity here.
Since moving to SimpleYUI, the order of inclusion for the YUI_config
variable is more important.
Simple YUI defines a global instance of YUI so that it can be used without
specifying the full YUI().use() syntax. As a result, any configuration
applied when that global instance is setup must exist already.
This issue also corrects the way in which Y.one is called. Previously it
was called as constructor rather than as a static method so it always
returned a Y.Node, regardless of whether a node was found.
Additionally, this adds a config setting to the YUI configuration such that
debug messages are not shown in the JS console when debugging is disabled.
The central "content" region on My Home / user profile pages also needs to
be initialised in lib/ajax/blocks.php in order to allow blocks to be
dropped into that region successfully. Some tweaks were also necessary in
order to correct the "content" region's structure in order for drag-drop
to function on this region on these pages.
Non-standard block regions (including the central "content" region
used by My Home and user profile pages) were causing the temporary empty
block region used as a drop target to sometimes appear in the wrong place.
The call to init_requirements_data (which includes the block drag-drop JS)
happens at a late enough stage in page generation that we can simply
pass the context ID through to the JS, so that it can be sent as part of
the AJAX request. This prevents lib/ajax/blocks.php from having to try
to guess the context from the other bits of information it receives, so
block drag-drop should now work everywhere without issues.
Other than shifting the initialisation from course/lib.php to
lib/outputrequirementslib.php, some workarounds/tweaks were required
in order to make it work correctly on admin pages and My Home.
The problem was that the root was breaking internal group handling in YUI loader for some reason. Without the root pattern property everything seems to work fine again.
