1. We need this so that, for example, when previewing a question from
the quiz editing page, the preview uses the filter settings, theme and
language set for that quiz and course.
Probably easiest to explain by example: If the right answer is 1.23 m with alternate
unit 100 cm = 1m then the completely right answers are 1.23 m and 123 cm.
Right answer, wrong unit responses include 1.23, 1.23 frogs and 1.23 cm.
123 m is not considered to have the correct numerical value.
We may well re-consider the way this works in a future version of Moodle.
Unit grading was not implemented before Moodle 2.0. In Moodle 2.0, the unit grading
was more permissive than here, for example 123 m would have been graded correctly in
2.0. However, I'm not sure I follow the rationale for that.
It seems that people want to be able to use <sup> and <sub> here, which
makes sense, so we need to keep radio buttons for questions upgraded
from 2.0. The dropdown menu, however, is also nice, so keep that option
too for new questions.
There were two main problems:
1. The unit tests for upgrading adaptive quiz attempts had slighly the
wrong $expectedqa, and so matching that the upgrade was doing the wrong
thing in certain situations. The main issue was that it was setting
-_try = 1 on the first step, which broke the penalty calculation when
the quiz was regraded. There were also some other subtleties with
incrementing -_try that were not right before.
2. It was possible in 2.0 and earlier for two question_states to get the
same seq_number, and restoring 2.0 backups was rashly assuming that that
was unique.
The most significant issue is that the HTML editor alwasy wraps <p> tags round the input, but that is not appropriate for the choices. It is especially not appropriate because we want to display the choices in a <lable> for accessibility and usability reasons. In valid HTML label can only contain inline elemnts. Therefore, I introduced a make_html_inline method, with a minimal implementation. (It could be improved in future.)
Long term, I think the best option would be a new form field type, editorinline, or something like that. That would be a smaller version of TinyMCE that only lets you enter inline elements.
While doing this, I found various bugs in the manages question types admin page, and so fixed them, and updated the code
there to use $OUTPUT and html_writer.
AMOS BEGIN
MOV [cannotdeletemissingqtype,admin],[cannotdeletemissingqtype,question]
MOV [cannotdeleteqtypeinuse,admin],[cannotdeleteqtypeinuse,question]
MOV [cannotdeleteqtypeneeded,admin],[cannotdeleteqtypeneeded,question]
MOV [deleteqtypeareyousure,admin],[deleteqtypeareyousure,question]
MOV [deleteqtypeareyousuremessage,admin],[deleteqtypeareyousuremessage,question]
MOV [deletingqtype,admin],[deletingqtype,question]
MOV [numquestions,admin],[numquestions,question]
MOV [numquestionsandhidden,admin],[numquestionsandhidden,question]
MOV [qtypedeletefiles,admin],[qtypedeletefiles,question]
MOV [uninstallqtype,admin],[uninstallqtype,question]
AMOS END
