-
☆ A M B ☆
- 24,524 Posts
Well, it’s working now; I don’t want to mess around with it any more as long as it is working! The saving issue went away as soon as the line got added to the my.cnf file. That is the best solution for me, as I want all of my databases to be utf-8 anyway.
-
☆ A M B ☆
- 24,524 Posts
Yes, it matches. Everything is set to utf8_unicode_ci, database, tables, fields.
@Jason
My config was: 0.9.6.1p2 with config.inc.php/$database_connection_charset = ’utf8’;, manager: utf-8, tinyMCE entity encoding: raw, webpage-encoding: utf-8, database-server, database, tables: utf-8 (both, character set and collation). Worked like a charm as long as I used standard european languages. 2 days ago a collegue from bulgaria has edited some pages in her language (with or without RTE), and these pages messed up with lot of question marks.
When I was editing "modx_site_content" directly via phpMyAdmin, all bulgarian pages where displayed fine.
Inserting my changes (see post above) fixed these problems.
After that I installed a fresh MODx for use as my personal playground. All settings where utf-8, really. Then I grabbed some greek phrases from wikipedia and pushed them into MODx. Same issue, lot of question marks. Setting NAMES in manager/index.php and voilá...
For each project I usually write down fixes like that for remember them, when it comes to update.
-
☆ A M B ☆
- 24,524 Posts
Well, for me it turned out the the server itself had to be set to utf8 as well, or incoming values (from MODx, at any rate) would be saved to the database as ??. The utf-8 Unicode character set is rather odd, since each character can take up to three bytes (which is why varchar is better than char field definitions, since if it’s char it reserves three bytes for each char specified in the length, while varchar only uses what is actually used). So all the characters that can be shoehorned into the first byte (most of the common Western European characters) are fine. It’s when you get into the two- and three-byte characters that you run into trouble. I still don’t completely understand how it works, but I’ve managed to get this much of an idea.
Collation is not the same as the storage method; collation has to do with sorting and ordering, and while they are related having a given collation does not mean you’ve got the same storage type or that you’re connection with a client using the same type. It gets kind of complicated at that point.
Aside from the langauge-specific collations, there’s utf8-bin, utf8-general, and ut88-unicode, all of which behave differently when sorting and ordering.
-
MODX Staff
- 10,725 Posts
PHP, and thus MODx, does not support Unicode. MySQL does. I think you can easily see the problem there.
And according to the documentation for MySQL, SET CHARACTER SET is the same as SET NAMES except it sets the collation_connection to match that of the database container.
-
☆ A M B ☆
- 24,524 Posts
Quote from: yoomai at Mar 13, 2008, 01:24 PM
Susan, this is what I did in 0.9.6p2 to have full utf-8 support:
1. New variable in manager/includes/config.inc.php:
after line 9
$database_connection_charset = 'utf8';
insert:
$database_collation_connection = 'utf8_general_ci';
2. this variable goes into in manager/index.php:
after line 141
@mysql_query("SET CHARACTER SET {$database_connection_charset}");
insert:
@mysql_query("SET SESSION collation_connection = '{$database_collation_connection}';",$modxDBConn);
Actually I have no character set problem at this time, because my private small addition to the manager/index.php works a charm for me. Nevertheless, thank you for the advice.