The problem was with the non-UTF-8-safe way that a question name
was being constructed from the question text.
I have done a proper fix with methods in the base class to
carefully construct a question name that is reasonable, and
which will fit in the database column. Then I have changed all
importers to use the new methods.
I also remembered not to break the lesson in the process.
Sadly, this involves a small API change, but I don't believe anyone was
using the argument I had to remove (because we were sometimes passing a
wrong value, and there is not way to compute the right value at that
point in the code.)
Also sadly, the code to compute the context we are importing into is now
rather spaghetti-like, but it works.
This applies to:
1. Upgrade from 1.9,
2. Import of questions exported from 1.9, and
3. Restore of courses backed-up from 1.9.
It also applies to the calculated question type.
The new logic is that the questiontext defaults to HTML if the format is
not specified, then all other fields default to the same format of the
question text.
However, good practice is that the XML file should specify the format
for each bit of text content.
This code is not 100% backwards-compatible, since some methods have new
arguments, however for question types that have not been updated, it
will just generate a PHP Warning, which is, I think, and OK way to let
qtype developers know that they need to update their question types.
This commit also includes a lot of useful tidying up of some of the unit
test helper code. I turned out that I could not use all the helper code
in my new tests, but despite that it will be useful in the future, so I
am committing it here.
Editing of some qtypes was broken since a previous commit by me earlier in the week.
Import of XML and GIFT should now work, but could use some more testing.
The solution is to not tidy the XML. The XML generated is already quite well laid out, and if we want it better, we should fix that, rather than trying to load the whole file into memory to reformat it.
Also, while investigating this, I found that we were not handling the mime-type of the exported file very elegantly, so I added a new mime_type method (defaults to getting the mime type of the file extension).