|
I'm not at all familiar with the migration process
I'm guessing that some sort of procedure was used directly on the useranswer field for the LESSON_ESSAY question type before unserializing it. This would then break the serialized string if any of the values changed in length. More info: The useranswer field for LESSON_ESSAY is a serialized object with the following set: sent = 1 or 0 I looked in the migrate2utf8 scripts in mod/lesson/db and found the only reference to useranswer was in migrate2utf8.xml at line 8, but I have no clue what it is doing If someone could point me to where I would need to modify the migration2utf8 script to fix this problem, I'll be happy to tackle it. But right now I feel like I would have to dig around for hours just to figure out how it works. Cheers, Added Eloy as a Watcher so hopefully he will be emailed. Sorry Eloy if you do not handle utf8 migration bugs, but I'm sure you will know who would.
I think the problem with this one lies in the migrate2utf8.xml file near the top. It needs to call a php function for lesson_attempts table, but I have no clue how to do this. We need this function because the useranswer field for essay questions has a serialized object and needs to be unserialized, converted and then serialized for storage. Least this is what I think is going wrong Thanks for any help in resolving this issue. Added Petr as a watcher. Just trying to get some help
Aha!
1- So, the lesson_attempts->useranswer CAN contain:
2- Oki. And when it contains one serialised object the structure of such object is ALWAYS:
3- And the answer is written by the student. 4- And the response is writen by the teacher. 5- And this is the only one field in the lesson module using serialised storage. Please, check and conffirm/fix all the statements above. Thats really important in order to be able to follow the behaviour below. The basic idea is that we have to change current lesson_attempts->useranswer conversion from the current simple SQL definition (done, because we assumed it was always a simple text field) to one spesialised function to be stored in mod/lesson/migrate2utf8.php called migrate2utf8_lesson_attempts_useranswer() This function should:
(I've added Yu here too) Ciao Hi Eloy,
Thanks for your comment! All 1 through 4 are correct. As for other serialized objects, there is one in the lesson and lesson_default tables. The field in both tables is called conditions. Its object contains three settings: timespent, completed, and gradebetterthan. All three are number values. Everything in your post sounds great as well. Let me know if I can help further. Hi,
I made some changes in 1.6 and HEAD regarding this issue. Basically checking if unserialization succeeds or not, and perform the right action accordingly. Please let me know if there are still problems with this, as I do not have a large number of data to play with. Are the other serialized objects giving you problems? Yu Just testing
Processsing db table lesson_branch... Success Success Success Parse error: syntax error, unexpected T_OBJECT_OPERATOR in /mod/lesson/db/migrate2utf8.php on line 44 So, perhaps, it's broken now...reopening... resolving it again. It was one simple typo, preventing migration to continue.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
That specific issue/error is from https://moodle.tpu.fi/mod/lesson/view.php?id=21198&action=essaygrade&attemptid=83
, a page which doesn't have a name, but is the "single essay view", accessible from Grade Essays tab (https://moodle.tpu.fi/mod/lesson/view.php?id=21198&action=essayview
). Every essay is unserialized when viewing the Grade Essays tab itself and a couple of dozen error messages are show like this:
Notice: unserialize(): Error at offset 769 of 832 bytes in /var/www/moodle/mod/lesson/view.php on line 1603
In moodle/mod/lesson/view.php both the line 1603 and the line 1672 are:
$essayinfo = unserialize($essay->useranswer);
Default charset for db and table mdl_lesson_attempt is utf8.