UTF-8 problems

Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.

Problems (and solutions!)

Password field(s) can be encoded in anything, and it is encrypted using a one way md5 hash. This means that we can not reverse the md5, thus if a string was encoded in an arbitrary language, we can not do the proper DB migration for that. Possible solutions:
- auto generate new password and send to all users?
- add to passwords one more field - like "original password encoding", fill it while upgrading, and then at user loging in, before compare with hash make translation of entered password to login's original password encoding (by engine like iconv). Upgrade system may time to time perform check, and when all "original encoding" become to UTF-8 - can remove this column and related code. This will be long but soft convertation life...--Ne Nashev 07:41, 26 March 2006 (WST)
Exercise - password - md5
Lesson, lesson_default - password - md5
Workshop - password - md5
Quiz module, the use of field "uniqueid" in attempts - uniqueid is used to link to quiz_states table which is in turn linked to many quiz tables. dev - linked using uniqueid? stable - linked using id??
Locales: What happens with locales once we have converted lang packs. Currently the process is adding the .UTF-8 suffix to them, but is this the best solution. Would be better to add support for one windows locale and other unix locale? Solved. See Table of locales.
Upgrade not succesful: this SQL restarts the unicode db update "UPDATE `mdl_config` SET `value` = '0' WHERE `name` ='unicodedb'"