Issue if MOD'x encoding is set to UTF-8, and WLPE database is set to latin?

I noticed that MODx is set to Unicode UTF-8, while the collation in the web-user related tables is to latin1_swedish_ci.

Could that be causing my recent WLPE issues (as well as WebSignup saying I didn’t enter in a username when one already existed)?

Make sure your connection charset in config.inc.php matches the actual database character set (latin1). Whether that will solve your problem though I don’t know.

Quote from: Soshite at Feb 14, 2008, 04:25 PM

WebSignup saying I didn’t enter in a username when one already existed)?

That only makes matter only if you have the double-characterized user name or password whilst you have the db as of latin_swedish(mostly) .

Quote from: MotSmart at Feb 14, 2008, 10:15 PM

Quote from: Soshite at Feb 14, 2008, 04:25 PM

WebSignup saying I didn’t enter in a username when one already existed)?

That only makes matter only if you have the double-characterized user name or password whilst you have the db as of latin_swedish(mostly) .

Double characterized? You mean some sort of special character?

Example: Suppose that column1 is defined as CHAR(5) CHARACTER SET latin2. If you do not say SET NAMES or SET CHARACTER SET, then for SELECT column1 FROM t, the server sends back all the values for column1 using the character set that the client specified when it connected. On the other hand, if you say SET NAMES ’latin1’ or SET CHARACTER SET latin1 before issuing the SELECT statement, the server converts the latin2 values to latin1 just before sending results back. Conversion may be lossy if there are characters that are not in both character sets.

So if the character sets don’t match, mysql may trash your data.

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

The user comments are worth reading.

So if config.inc.php says...



And in *blahblahblah*_cms (blah standing in for my the prefix for my database) is collated to latin1, I assume there’s an issue?

So I should change things over to UTF-8? Would it be better for me to do this manually, or tell my host (Gamespy) to convert things over?

Converting an existing database to a different charset will most likely break your content.

You can probably reset the database via the phpMyAdmin collation setting, but you’d best make sure you know what is going to happen before you do.

http://dev.mysql.com/doc/refman/4.1/en/charset.html
http://yoonkit.blogspot.com/2006/03/mysql-charset-from-latin1-to-utf8.html

Quote from: Soshite at Feb 15, 2008, 01:33 PM

Double characterized? You mean some sort of special character?

lol i meant double byte! how could i say that

Quote from: sottwell at Feb 16, 2008, 03:20 AM

You can probably reset the database via the phpMyAdmin collation setting, but you’d best make sure you know what is going to happen before you do.

Yes! but BACKUP first, check the table’s collation afterwards if you change manually.

I pointed this thread out to my host, so they should know what to do with it. I have a site in the works that’s using MODx and having the same issues as my main site, so I’m having them use that as a "test subject", since I can easily revert any changes made there w/ minimal issues.

Big thanks to everyone who’s helped me out so far.

I’ve attached an image of the charset information from the phpMyAdmin page for the database at the "testing" website, which has the same issues as Symphonic Heaven. All of the tables are set to latin1_swedish_ci, btw. As of right now on that testing website, MODx is set to UTF-8.

I assume by changing the latin1 -> utf8, this would fix my issue, correct? Now, two things. I can easily change over the charset collation option on the "homepage" for phpMyAdmin, but what SQL command should I use to change the Collation option under Table options? And I see a bunch of options --- should I use utf8_swedish_ci, or utf8_unicode_ci?

I’ll need to do this myself, since the database person at Gamespy is *very* overworked ATM. And since this is a "testing" site, I can easily scrap and try something else if this doesn’t work.