|
Reading the docs and our code I also think we are not setting 'character_set_database' variable at all, we just require moodle database to be using unicode encoding. The easies solution is to drop and recreate the database with utf8 as default charset.
The problem with shared hosting is that everybody is disabling/limiting different "features" in PHP, MySQL or Apache. Majority of testing is done with default settings and default installations. PS,
There is already code in Moodle to perform the "easiest solution" of recreating the db as utf8; it reportedly doesn't work. EL, See Anthony Borrow's recent comments on RLE This is closed as duplicate of
Ciao |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Improvement
Closed
Minor
Character Set misreported on shared hosting
 |
|
All content on this web site is made available under the GNU General Public License, unless otherwise stated.
I don't understand the GLOBAL / LOCAL (SESSION) distinction for the "character_set_database" setting.
Such setting isn't client/server dependent AFAIK, but the default encoding of the database where Moodle connects to. So, if one DB has 'utf8' as default encoding, the "character_set_database" should return 'utf8', no matter if asked GLOBALLY or LOCALLY.
Or, were am I wrong? How can we have different "character_set_database" settings depending of the GLOBAL/LOCAL thing?
Ciao