Two issues when upgrading to 0.9.6.1

Quote from: mmjaeger at Dec 10, 2007, 05:31 PM

is there an easy way to change all the table to utf8_unicode_ci using phpmyadmin

Not really, no. And that would not convert the data already stored in the other collation, I do not believe anyway. This is why I suggest changing the database collation to utf8_general_ci instead.

Quote from: OpenGeek at Dec 10, 2007, 05:51 PM

Quote from: mmjaeger at Dec 10, 2007, 05:31 PM

is there an easy way to change all the table to utf8_unicode_ci using phpmyadmin

Not really, no. And that would not convert the data already stored in the other collation, I do not believe anyway. This is why I suggest changing the database collation to utf8_general_ci instead.

well, utf8_general_ci is what I already have - I’m currently going through the content in phpmyadmin and change those weird characters - maybe it has something to do with tinymce - I don’t know.

thanks again for your help.

I’m confused; you told me the database had a collation of utf8_unicode_ci and the tables had utf8_general_ci. Is this or is this not the case?

Quote from: OpenGeek at Dec 10, 2007, 09:09 PM

I’m confused; you told me the database had a collation of utf8_unicode_ci and the tables had utf8_general_ci. Is this or is this not the case?

just checked again - utf/utf8_general_ci

do you think it could have something to do with tinymce - I’m using raw entity encoding - is that o.k.

Once again, thank you for your help.

There are two layers of settings involved here, the database container itself (which contains the tables). It has one charset and collation setting. Each table then has columns, and each text column also has a collation settings, which should match the collation of the database container. Do they match, or are they different?

I think they match but I’m not really sure what and where to check

In phpMyAdmin you can see the main database collation (on the main page if you have access privileges), then on each individual table when in structure view there is a column with the collation info, then, to top it off there is a collation on each text (varchar, text, ..) field within each table. All of these can be edited and set individually.


http://dev.mysql.com/doc/refman/5.0/en/charset-syntax.html

I was under the impression that the charset is what defined the character encoding and that the collation defined the interaction between the characters (hierarchy, sorting etc...). Does the collation also affect the encoding?

I’m currently going through the content in phpmyadmin and change those weird characters

I would also go back and edit in MODx to make sure that it will not get messed up the next time you update a page.

o.k.
these are my main settings:
Server version: 5.0.37-community-nt
Protocol version: 10
Server: localhost via TCP/IP
User: admin@localhost
MySQL charset: UTF-8 Unicode (utf8)
MySQL connection collation: utf8_general_ci

the modx database collation is set to utf8)general_ci as well as all the tables in the database

The collation is a subset of the charset. The first part of the collation will always match the charset.

I was trying to make sure the server, database, and actual table settings were consistent to rule out any internal issues in the MySQL server. MODx will always use the actual collation and charset of the database it is connecting to (see SET CHARACTER SET vs. SET NAMES), regardless if you have specified the connection charset value properly, so make sure the database matches.

As for your problem mmjaeger, I’m not sure, but sounds like you may have migrated this data using a non-utf8 format or done some other operation which prevented the data from being stored into the database properly. If everything checks out regarding your charset/collation settings, only thing left to do is fix the data.

Quote from: OpenGeek at Dec 11, 2007, 04:11 PM

The collation is a subset of the charset. The first part of the collation will always match the charset.

I was trying to make sure the server, database, and actual table settings were consistent to rule out any internal issues in the MySQL server. MODx will always use the actual collation and charset of the database it is connecting to (see SET CHARACTER SET vs. SET NAMES), regardless if you have specified the connection charset value properly, so make sure the database matches.

As for your problem mmjaeger, I’m not sure, but sounds like you may have migrated this data using a non-utf8 format or done some other operation which prevented the data from being stored into the database properly. If everything checks out regarding your charset/collation settings, only thing left to do is fix the data.

...fix the data, that’s what I’m currently working on.

Thank you for your help - really appreciate it.