This mostly works now, but ...
* The UI needs further work. In particular we need a non-advanced mode.
* This only works for blocks that use a new edit_form.php to replace config_instance.html.
* .. and so far I have only implemented edit_form.php for the HTML block so far.
* Needs to be enabled (with no block-specific config) for blocks without instance config, so you can control their positioning.
This is part of http://docs.moodle.org/en/Development:Theme_engines_for_Moodle%3F
$THEME is now initialised at the same time as $OUTPUT. Old functions like
theme_setup are deprecated in favour of methods on $PAGE. There is a new
theme_config class in outputlib.php that deals with loading the theme config.php file.
CSS used to be served by themes styles.php files calling a function in weblib.php.
Now it works by each theme's styles.php file doing
$themename = basename(dirname(__FILE__));
require_once(dirname(__FILE__) . '/../../theme/styles.php');
which is less code to be copied into each theme. (Old-style styles.php files still
work thanks to some code in deprecatedlib.php.)
Admin UI for choosing a theme cleaned up.
A couple of theme-specific hard-coded hacks like $THEME->cssconstants and
$THEME->CSSEdit have been replaced by a more generic $THEME->customcssoutputfunction
hook. See examples at the end of outputlib.php
Also:
* Fix setting the theme in the URL, which seems to have been broken since 1.9.
* Fix up errors on a few pages caused by the new initialisation order.
* MDL-19097 moodle_page::set_course should not set $COURSE unless it is $PAGE.
* httpsrequired() from moodlelib.php moved to $PAGE->https_required().
* Move has_started() method to the renderer base class.
* Further fixes to display of early errors.
* Remove print_header/footer_old from weblib. I did not mean to commit them before.
New option on Administration -> Server -> Debugging called
'Show origin of languages strings' ($CFG->debugstringids).
If this is set, get_string will add the name of the lang file and the id of the string
to each string it gets, so instead of returning 'No', it will return '{No admin/checkboxno}'.
This new class does the work that require_js used to do, and more.
It can track a number of different things that may be required to
be output somewhere on the page, including:
* Links to JS files
* Links to CSS files
* Links to YUI libraries (this class knows about the dependancies between the different libs).
* Skip links that go from the top of <body> to various places in the content.
* Calls to JavaScript functions (for example to initialise things)
* Bits of data from PHP that need to be available to JavaScript
* As a special case of that, an easy way to pass language strings to JS.
The new API looks like
$PAGE->requires->css('mod/mymod/styles.css');
$PAGE->requires->js('mod/mymod/script.js');
$PAGE->requires->js('mod/mymod/small_but_urgent.js')->in_head();
$PAGE->requires->js_function_call('init_mymod', array($data))->on_dom_ready();
$PAGE->requires is the canonical instances of this new class.
The commit also includes unit tests, and hopefully the PHP doc comments are
clear enough that it is easy to understand.
