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}'.
Also, part of the change from weblib.php functions to $OUTPUT-> methods.
This is part of http://docs.moodle.org/en/Development:Theme_engines_for_Moodle%3F
This is a big change, and the result is not perfect yet. Expect some debugging output
on some pages.
The main part of these changes are that $OUTPUT->header now looks for a file
in the theme called layout.php, rather than header.html and footer.html. Also
you can have special templates for certain pages like layout-home.php. There is
fallback code for Moodle 1.9 themes, so they still work.
A few of the old arguments to print_header are no longer supported. (You get an
exception if you try to use them.) Sam H will be cleaning those up.
All the weblib functions that have been replaced with $OUTPUT-> have version in
deprecatedlib, so existing code will go on working for the foreseeable future.
There is a new implementation of require_js in lib/deprecatedlib.php,
based on $PAGE->requires.
There were a few other recently introduced functions in lib/weblib.php,
namely print_js_call, print_delayed_js_call, print_js_config and
standard_js_config. These have been removed, since they were never in
a stable branch, and all the places that used them have been changed
to use the newer $PAGE->requires->... methods.
get_require_js_code is also gone, and the evil places that were calling
it, even though it is an internal function, have been fixed.
Also, I made some minor improvements to the code I committed yesterday
for MDL-16695.
All that remains is to update all the places in core code that are
still using require_js.
(This commit also fixes the problem where the admin tree would not
start with the right categories expanded.)
* has course and status fields
* $PAGE->status updated by print_header and footer
* $PAGE->set_course now replace course_setup function
* global $PAGE created in setup.php
* unit tests for functionality so far
* Moodle still seems to work after this commit!
* Rename filter base class from filter_base to moodle_text_filter
* Remove unnecessary explicit constructors in moodle_text_filter
subclasses
* New filter_manager class, rather than static methods in filter_base
* Move some logic out of weblib, and into filter_manager
* Count filtering ops when $CFG->perfdebug on, via
performance_measuring_filter_manager
* Kill unused filter_string function. Petr said it should have been
private to weblib
If Google can do something like http://translate.google.com/, surely we
can do something just as good in Moodle. Here is a first attempt. It is
a bit rough around the edges, and only a couple of target lananguages
have been implemented so far. (More and better attempts welcome!)
In order to ensure that this gets adequate testing, I have made sure that
it gets turn on by default. However, if you really don't like it, you can
turn it off under Administration > Development -> Experimental settings.
This makes filters more plugginable, becuase with this lang file name, get_string will look for the filter name in filter/myfilter/lang/en_utf8/filter_myfilter.php.
To do this, there is a new function filter_get_name in filterlib that contains the logic.
Also, a new function filter_get_all_installed to replace the logic for getting all filters that was duplicated in three places.
filter_get_name no longer does such a nice fall-back if the name is missing, to encourage people to supply the right string. The fallback now looks like '[[filtername]] (filter/tidy)'.
MDL-18669 get_string refactored to elimiate duplicate code and make it easier to understand.
MDL-17763 parent language not processed correctly when getting a plugin string.
MDL-16181 more intelligent caching to avoid repeated file_exists checks.
MDL-12434 move values to array keys to improve lookup times.
The main part of the refactoring is to create a singleton string_manager class to encapsulate the cached data and the processing, while breaking the code up into more smaller methods.
Other performance improvements include:
* Cache results of plugin name -> locations to search array.
* Cache parent lang lookup.
* Skip eval if the string does not contain $ \ or %.
* Remove the unnecessary sprintf from the eval.
There is a performance testing script in lib/simpletest/getstringperformancetester.php. For now this script has the old get_string implementation copied and pasted to the end, and renamed to old_get_string to allow for comparitive timings.
There are now some unit tests for get_string in lib/simpletest/teststringmanager.php. I think I have managed to cover most of the tricky cases.
