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.