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)'.
I did not fix all the DB problems in search, there are too many there for me to be prepared to clean up other people's mess.
(For once, it was not me making this mistake ;-))
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.
Allow question types to be displayed in order that is better than random or alphabetical. Since we don't know all the qtypes there may be:
1. Store the order in the DB (config plugins).
2. Set up a good default order for the standard types. (Unknown types go at the end by default.)
3. Allow admins to edit the order on the qtype admin screen.
