Please forgive me if I have missed converting any output statements. If you do find an output statement that is not formatting correctly please refere to the table I added to this bug in regards to how it should be formatted.
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.)
This is not as ambitious as the abortive FakeDBUnitTests scheme, but this one works for simple cases.
There is a new test case class UnitTestCaseUsingDatabase to inherit from. I hope it is sufficiently well documented in its PHPdocs.
* It users $CFG->unittestprefix.
* You can access that database using $this->testdb.
* That database is empty by default, you have to call create_test_table to create the ones you want, and drop_test_table to clean them up in the end. The table definitions are read from the XMLDB file.
* When you are ready to call real Moodle code that users $DB, call switch_to_test_db and then revert_to_real_db when you are done.
* If you forget to call drop_test_table or switch_to_test_db, the class will attempt to clean up after you, but will also print rude developer debug messages telling you not to be stupid.
* There is also a load_test_data method for populating a table from an array.
The is an example of its use in lib/simpletest/testunittestusingdb.php.
